Safeguard
Application Security•

CWE-538 Sensitive Data in Externally Accessible Files

Secrets written into files or directories that other people can read. How CWE-538 happens, including a real build log example, and how to fix it.

Safeguard Security Team
2 min read

CWE-538, Insertion of Sensitive Information into Externally-Accessible File or Directory, has a precise definition from MITRE. The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.

The wording matters. The reader here is not a stranger who broke in. It is someone with legitimate access to a folder, a share or an artifact, who was never meant to see the secret inside it.

How it happens

A build writes a password to its output. A script drops a credentials file into a shared directory. An export lands in a folder that a whole team can open. The file permissions are correct for the folder, and wrong for what the file contains.

MITRE gives one observed example: CVE-2018-1999036, where an SSH password for a private key was stored in a build log (Gold entry). Anyone allowed to view build logs could read it.

What an attacker gains

MITRE lists a confidentiality impact: reading files or directories. Whoever opens the file gets the secret and can use it with the permissions it carries.

How to find it

  • Inventory where your systems write files: logs, build output, temp directories, export folders, shared drives.
  • Check who can read each location, then check what is inside.
  • Scan files and build output for credentials.
  • MITRE notes static analysis can find some instances of this weakness.

How to fix it

MITRE's guidance is to avoid exposing file and directory information to the user, through design, operation and system configuration. In practice:

  1. Do not write secrets to files in the first place. Pass them through a secrets manager or environment at run time.
  2. Mask secrets in build output.
  3. Give each directory the narrowest audience that needs it, and keep sensitive files in a restricted location.
  4. Review access to shared locations regularly.

Quick check

How is this different from a public exposure?

The readers are authorized for the file or folder but not for the secret inside. Tightening the folder is not enough; the secret should not be there.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.