Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."

This compiler optimization error occurs when:

Secret data are stored in memory.
The secret data are scrubbed from memory by overwriting its contents.
The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.

Primary

Implementation

Build and Compilation

Confidentiality
Access Control
Read Memory
Bypass Protection Mechanism
This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.

Black Box
This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.
Limited

White Box
This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

Implementation
Store the sensitive data in a "volatile" memory location if available.

Build and Compilation
If possible, configure your compiler so that it does not remove dead stores.

Architecture and Design
Where possible, encrypt sensitive data that are used by a software system.

The following code reads a password from the
user, uses the password to connect to a back-end
mainframe, and then attempts to scrub the password from
memory using memset().

void GetData(char *MFAddr) {

char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {

if (ConnectToMainframe(MFAddr, pwd)) {

// Interaction with mainframe

}

}
memset(pwd, 0, sizeof(pwd));

}

The code in the example will behave
correctly if it is executed verbatim, but if the code
is compiled using an optimizing compiler, then the call to
memset() might be removed as a dead store, because the
buffer pwd is not used after its value is overwritten.
Because the buffer pwd contains a sensitive
value, the application may be vulnerable to attack if
the data are left memory resident. If attackers are
able to access the correct region of memory, they may
use the recovered password to gain control of the
system.
It is common practice to overwrite sensitive
data manipulated in memory, such as passwords or
cryptographic keys, in order to prevent attackers from
learning system secrets. However, with the advent of
optimizing compilers, programs do not always behave as
their source code alone would suggest. In the example,
the compiler interprets the call to memset() as dead
code because the memory being written to is not
subsequently used, despite the fact that there is
clearly a security motivation for the operation to
occur. The problem here is that many compilers, and in
fact many programming languages, do not take this and
other security concerns into consideration in their
efforts to improve efficiency.
Attackers typically exploit this type of
vulnerability by using a core dump or runtime mechanism
to access the memory used by a particular application
and recover the secret information. Once an attacker
has access to the secret information, it is relatively
straightforward to further exploit the system and
possibly compromise other resources with which the
application interacts.

Memory

Insecure Compiler Optimization

Sensitive memory uncleared by compiler optimization

A8
Insecure Storage
CWE More Specific

MSC06-C
Be aware of compiler optimization when dealing with sensitive data

SFP23
Exposed Data

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

7 Pernicious Kingdoms
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2008-10-14
updated Relationships

CWE Content Team
MITRE
2008-11-24
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes, Potential_Mitigations, Relationships, Taxonomy_Mappings, Time_of_Introduction

CWE Content Team
MITRE
2009-05-27
updated Demonstrative_Examples

CWE Content Team
MITRE
2010-02-16
updated References

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-09-13
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Common_Consequences, References, Relationships

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-01-19
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2018-03-27
updated References, Type

CWE Content Team
MITRE
2020-02-24
updated References, Relationships

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples, Description

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Weakness_Ordinalities

Insecure Compiler Optimization