CWE-591: Sensitive Data Storage in Improperly Locked Memory | Glexia
CWE-591 (Sensitive Data Storage in Improperly Locked Memory) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK…
Glexia's Take · Automated analysis
CWE-591: Sensitive Data Storage in Improperly Locked Memory
Sensitive Data Storage in Improperly Locked Memory represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Confidentiality: Read Application Data,Read Memory: Sensitive data that is written to a swap file may be exposed.
Developer Pattern
CWE-591 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-591, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-591: Sensitive Data Storage in Improperly Locked Memory
The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.
On Windows systems the VirtualLock function can lock a page of memory to ensure that it will remain present in memory and not be swapped to disk. However, on older versions of Windows, such as 95, 98, or Me, the VirtualLock() function is only a stub and provides no protection. On POSIX systems the mlock() call ensures that a page will stay resident in memory but does not guarantee that the page will not appear in the swap. Therefore, it is unsuitable for use as a protection mechanism for sensitive data. Some platforms, in particular Linux, do make the guarantee that the page will not be swapped, but this is non-standard and is not portable. Calls to mlock() also require supervisor privilege. Return values for both of these calls must be checked to ensure that the lock operation was actually successful.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- Missing validation
- Unsafe defaults
- Insufficient authorization or memory-safety invariant
Remediation
- Architecture and Design: Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms.
- Implementation: Check return values to ensure locking operations are successful.
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.