CWE-313 is the file-level form of cleartext storage: the product stores sensitive information in cleartext in a file, or on disk. It is a narrower case of the broader CWE-312.
Anyone who ships software with config files, local caches, temp files or exports can run into it.
How it happens
The sensitive value lands in a file in readable form. Configuration files holding database passwords are the textbook case. Others are cache files that keep credentials, logs that print tokens, and temporary files that hold a decrypted copy of protected data.
MITRE says the information could be read by attackers with access to the file, or with physical or administrator access to the raw disk. Encoding does not change that, since techniques exist to identify the encoding and decode it.
Observed examples from the record:
- CVE-2001-1481: cleartext credentials in a world-readable file.
- CVE-2005-1828 and CVE-2005-2209: a password in cleartext in a config file.
- CVE-2002-1696: a decrypted copy of a message written to disk, given a combination of options, when the user replies to an encrypted message.
The last one is subtle. The product encrypted the message, then wrote a plain copy as a side effect of another feature.
# Vulnerable config
database:
user: app
password: hunter2
# Better: reference a secret supplied at runtime
database:
user: app
password_env: DB_PASSWORD
What an attacker gains
The listed consequence is loss of confidentiality: the attacker reads application data.
How to find it
MITRE says static analysis (SAST) can find some instances by analyzing source or compiled code. Add these checks:
- Run a secrets scanner over the repository, including history.
- List files your application writes at runtime, including temp and cache locations, and read them.
- Check file permissions on config and data files.
- Look for plain copies produced by "convenience" features such as reply, export and debug modes.
How to fix it
The record lists no formal mitigations, so these are general practice consistent with the weakness:
- Keep passwords and keys out of files. Supply them at runtime from a secrets store or the environment.
- Where a file must hold a secret, encrypt it and tighten permissions to the account that needs it.
- Never write decrypted copies of protected data to disk, or delete them reliably after use.
- Encrypt disks and backups as a second layer.
Quick check
Is a config file with strict permissions enough?
It helps against local users but not against backups, administrators or physical access to the disk. Prefer not storing the secret there.
