What CVEs are caused by CWE-14?

9 recorded CVEs are attributed to CWE-14, including CVE-2023-32100, CVE-2023-32099, CVE-2023-32098.

Is CWE-14 part of the OWASP Top 10?

CWE-14 maps to OWASP Top Ten 2004: Insecure Storage (A8) in the OWASP security taxonomy.

What are the consequences of CWE-14?

Exploiting CWE-14 can lead to: Read Memory, Bypass Protection Mechanism.

Is CWE-14 actively exploited?

9 recorded CVEs are caused by CWE-14; none are currently in CISA's KEV catalog of actively exploited flaws.

Variant weakness

Draft

CWE-14: Compiler Removal of Code to Clear Buffers

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."

Last updated May 1, 2026

Recorded CVEs

With this primary weakness

KEVs

In the CISA KEV catalog

Not rated

Likelihood of exploit

Per MITRE

Variant

Abstraction

MITRE classification

Overview

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.

Real-world CVEs

9 recorded CVEs are caused by CWE-14 (Compiler Removal of Code to Clear Buffers). The highest-severity and most recent are shown first. 1 new CWE-14 CVE has been recorded so far in 2026.

Common consequences

What can happen when CWE-14 is exploited.

Read Memory, Bypass Protection Mechanism

Affects: Confidentiality, Access Control

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.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

Build and Compilation

Applies to

Languages

C++

Compiled

How to prevent it

Practical mitigations for CWE-14, grouped by where in the lifecycle they apply.

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.

How to detect it

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.

Effectiveness: 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.

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

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().

Vulnerable example

char pwd[64];

Terminology & mappings

Mapped taxonomies

7 Pernicious Kingdoms: Insecure Compiler Optimization
PLOVER: Sensitive memory uncleared by compiler optimization
OWASP Top Ten 2004: Insecure Storage (A8) — CWE More Specific fit
CERT C Secure Coding: Be aware of compiler optimization when dealing with sensitive data (MSC06-C)
Software Fault Patterns: Exposed Data (SFP23)

Frequently asked questions

Common questions about CWE-14.

What is CWE-14?: 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."
What CVEs are caused by CWE-14?: 9 recorded CVEs are attributed to CWE-14, including CVE-2023-32100, CVE-2023-32099, CVE-2023-32098.
Is CWE-14 part of the OWASP Top 10?: CWE-14 maps to OWASP Top Ten 2004: Insecure Storage (A8) in the OWASP security taxonomy.
How do you prevent CWE-14?: Store the sensitive data in a "volatile" memory location if available.
How is CWE-14 detected?: 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.
What are the consequences of CWE-14?: Exploiting CWE-14 can lead to: Read Memory, Bypass Protection Mechanism.
Is CWE-14 actively exploited?: 9 recorded CVEs are caused by CWE-14; none are currently in CISA's KEV catalog of actively exploited flaws.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Stay ahead of CWE-14

Get alerted the moment a new CWE-14 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.

Start free See pricing