CWE-316 is about secrets that sit in memory in cleartext. At some point a program must hold a password or key in plain form to use it. The weakness is keeping it there longer than needed, or in a way that lets it escape.
Desktop clients, password managers, SSH tools and long-running services are the typical homes.
How it happens
MITRE explains why memory is not a safe resting place. Sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the product crashes or the programmer does not clear it before freeing it. It could be argued that this is only exploitable by administrators, but swapping can write memory to disk and leave it open to physical attack. Core dump files may have insecure permissions or end up in archives accessible to untrusted people. Uncleared memory may also be exposed through another weakness.
Observed examples from the record:
- CVE-2025-24870: the GUI of a desktop client stores credentials in program memory, allowing privilege escalation.
- CVE-2001-1517: sensitive authentication information in cleartext in memory.
- CVE-2001-0984: a password protector leaves passwords in memory when the window is minimized, even when "clear password when minimized" is set.
- CVE-2003-0291: an SSH client does not clear credentials from memory.
/* Vulnerable: secret lingers after use */
char password[64];
read_password(password, sizeof password);
authenticate(password);
/* buffer left as is */
/* Better: clear it with a call the compiler cannot remove */
explicit_bzero(password, sizeof password);
A plain memset right before the buffer goes out of scope may be optimized away, which is why a dedicated function is preferred where available.
What an attacker gains
The listed consequence is loss of confidentiality through reading memory.
How to find it
The record lists no detection methods. Practical checks:
- Review code paths that read or generate secrets and ask where each copy ends up and when it is cleared.
- Trigger a core dump or inspect a memory snapshot of your own process after a login, and search it for the test password.
- Check swap and hibernation settings on hosts that run sensitive tools.
- Confirm that crash dumps are stored with restricted permissions.
How to fix it
The record lists no formal mitigations. Practices that follow from the weakness:
- Hold secrets in memory for as short a time as possible.
- Overwrite buffers as soon as you are done, using functions designed not to be optimized out.
- Where the platform allows, keep secret buffers out of swap and core dumps.
- Restrict access to dump files and do not archive them in shared places.
- Make sure any "clear on minimize" or "clear on timeout" feature really clears every copy.
Quick check
Is this only a problem if the attacker is an administrator?
Often that is the entry point, but swap files, core dumps and a second vulnerability can expose memory contents to others, as MITRE points out.
