Memory Corruption Vulnerabilities Guide: Classes, Mitigations and Memory-Safe Languages

Memory corruption vulnerabilities are flaws where a program reads or writes memory it should not, and they remain one of the largest sources of critical, actively exploited bugs in browsers, operating systems and edge devices. A memory corruption vulnerability occurs when software written in a language without built-in memory safety, usually C or C++, accesses memory outside an object's bounds, after the object has been freed, or with the wrong type. This guide explains the vulnerability classes at concept level, why they are so valuable to attackers, and what defenders and engineering leaders can do about them: compiler and operating system mitigations, testing, patch prioritisation and the move to memory-safe languages that CISA and NSA now urge. It is written for security architects, AppSec engineers, vulnerability managers and the leaders who fund engineering roadmaps. It deliberately contains no exploitation detail.

Key takeaways

• It is a class problem, not a bug problem. Google reports that about 70% of high and critical severity security bugs in Chromium are memory safety issues, and roughly half of those are use-after-free bugs.
• Attackers use these bugs in the wild. In the CISA Known Exploited Vulnerabilities (KEV) catalogue version 2026.10.21, 413 of 1,754 entries (about 24%) are tagged with at least one common memory safety weakness such as CWE-787, CWE-416 or CWE-119.
• Mitigations raise cost, they do not remove the class. Stack canaries, DEP, ASLR, control-flow integrity and shadow stacks make exploitation harder, but determined attackers chain bugs to get around them.
• New code is where to start. Android cut memory safety issues from 76% of its vulnerabilities in 2019 to 24% in 2024 mainly by writing new code in memory-safe languages, without rewriting old code.
• Vulnerability management must treat this class as urgent. Memory corruption in internet-facing appliances, browsers and kernels is a common route to remote code execution and privilege escalation, so patch these first.

What it is

Memory corruption is the umbrella term for bugs that let a program violate the rules about which memory it may touch and how. Memory-safe languages such as Rust, Go, Java, C#, Swift and Python enforce those rules for the programmer through bounds checks, automatic memory management and type rules. C and C++ leave them to the programmer, so a single missed length check or a pointer used after its object is released becomes a security flaw. The NSA and CISA joint Cybersecurity Information Sheet (CSI) of June 2025, Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development, describes the built-in protections memory-safe languages offer: checks on memory access boundaries, automatic memory management and prevention of data races.

The flaws fall into two broad families. Spatial errors access memory outside the bounds of an object (overflows and out-of-bounds reads). Temporal errors access memory at the wrong time (after it was freed, before it was initialised, or freed twice). Type confusion and integer errors usually act as the trigger that produces a spatial or temporal error.

KEV counts come from the CWE tags in the CISA KEV catalogue data file (version 2026.10.21). Many KEV entries carry no CWE tag, so these figures are a floor, not a total. In the 2024 CWE Top 25, CWE-787 ranked 2nd, CWE-125 6th, CWE-416 8th, CWE-119 20th, CWE-476 21st and CWE-190 23rd.

How it works

At concept level, every memory corruption exploit follows the same arc, and each step is a place where a defence can interrupt it.

1. Untrusted input reaches unsafe code: a file, network packet, web page, font or image is parsed by C or C++ code. Parsers of complex formats are the classic hotspot, which is why Chromium calls its network process the "doom zone".
2. A bug corrupts or leaks memory: an index, length or object lifetime is wrong, so the program overwrites or reveals memory it should not.
3. The attacker gains a primitive: the corruption is shaped into the ability to read or write chosen memory. Out-of-bounds reads often supply the information leak needed to defeat address randomisation.
4. Control flow or data is hijacked: the attacker redirects execution or changes security-relevant data, such as a privilege flag.
5. Sandbox or privilege boundary is crossed: real-world chains often combine a renderer bug with a kernel or sandbox bug, which maps to ATT&CK T1203 Exploitation for Client Execution followed by T1068 Exploitation for Privilege Escalation. Server-side flaws in edge devices map to T1190 Exploit Public-Facing Application.

Not every memory bug needs code execution to cause harm. An out-of-bounds read can leak session tokens or keys directly, as the CitrixBleed 2023 breach showed: CISA KEV tags CVE-2023-4966 as CWE-119, and leaked NetScaler session cookies let attackers bypass MFA. Patching stopped new leaks but did not revoke cookies already stolen.

Where the platform mitigations act

Flags and their minimum GCC or Clang versions are listed in the OpenSSF Compiler Options Hardening Guide for C and C++; GCC 14 adds -fhardened as a bundle of recommended options. Windows exploit protection in Microsoft Defender for Endpoint exposes 22 per-process and system mitigations, including Arbitrary code guard, Validate heap integrity and Hardware-enforced stack protection.

Why it matters

• Severity: memory corruption typically yields remote code execution or privilege escalation, the outcomes that turn an initial foothold into full compromise. Chromium's own figure of about 70% of high and critical security bugs, from 912 bugs since 2015, shows the scale in one of the most scrutinised C++ codebases.
• Exploitation in the wild: the KEV analysis above shows memory safety weaknesses across browsers, mobile operating systems, kernels and network appliances. The Zero-Day and Exploited Vulnerabilities Guide and Zero-Click Exploits Guide cover how such chains are used.
• Identity impact: leaked or corrupted memory in gateways and identity infrastructure exposes session tokens, service account credentials and keys. Treat any memory disclosure bug in an authentication path as a credential exposure and rotate or revoke accordingly.
• Policy pressure: CISA's Secure by Design work, including The Case for Memory Safe Roadmaps, asks software manufacturers to publish memory safety roadmaps as evidence they own security outcomes. Buyers can and should ask suppliers for them.

How defenders reduce the risk

Phased programme

1. Inventory exposure: list products and internal code written in C and C++, prioritising anything that parses untrusted input or faces the internet. Use the SBOM to find embedded C libraries; see the SBOM Guide.
2. Prioritise patching by class: in vulnerability management, raise priority for CWE-787, CWE-416, CWE-119, CWE-122 and CWE-843 findings in browsers, kernels, VPN and edge appliances, especially those in KEV. See the Risk-Based Vulnerability Management Guide.
3. Turn on platform mitigations: set a baseline of hardening flags in build pipelines and enforce Windows exploit protection settings. Use audit mode first (Arbitrary code guard, Code integrity guard and others log to the Security-Mitigations event log), pilot on a ring of devices, then enforce. Roll back by reverting the per-application XML configuration.
4. Test continuously: run sanitizers (-fsanitize=address, ThreadSanitizer) in CI and fuzz every parser. See the Fuzzing Guide.
5. Isolate what remains unsafe: run risky parsing in sandboxed, low-privilege processes. Chromium's Rule of Two restricts combining untrusted input, an unsafe language and high privilege in one process.
6. Write new code in memory-safe languages: adopt Rust, Go, Java, C#, Swift or similar for new components and use interoperability to integrate with existing code, as the NSA and CISA CSI recommends. Google's data shows vulnerabilities concentrate in new and recently modified code, so this delivers returns quickly. See the Memory-Safe Languages Guide.
7. Publish and track a roadmap: set dates for memory-safe defaults by component and report progress, in line with CISA's roadmap guidance.

Decision guidance

• Rewrite versus harden: rewrite small, high-risk components (parsers, codecs, network protocol handlers). Harden and fuzz large, stable legacy code, since older code shows lower vulnerability density over time.
• Buyer versus builder: organisations that only consume software focus on patch speed, exploit protection settings and supplier roadmaps. Organisations that build software own the language, toolchain and testing choices.
• Small versus large teams: small teams get most value from compiler defaults, fuzzing open source dependencies through existing services and choosing memory-safe languages for anything new. Large teams can fund hardened libraries, custom static checks and hardware features such as MTE.

Detection and measurement

Exploitation of memory corruption often leaves little trace, so detect the symptoms: repeated crashes of the same process (Windows Error Reporting, core dumps), exploit protection block events, unexpected child processes from browsers or document readers, and endpoint detection alerts for process injection (ATT&CK T1055). The Memory Forensics Guide covers analysis after a suspected exploit.

• Mean time to remediate KEV memory corruption CVEs on internet-facing assets, against a target set in policy.
• Share of new code in memory-safe languages, by repository or component.
• Coverage of hardening flags: percentage of shipped binaries built with the baseline flag set, checked in CI.
• Fuzzing coverage: share of parsers with continuous fuzzing, and open sanitizer findings older than 30 days.
• Exploit protection enforcement: share of endpoints with the organisation's exploit protection baseline applied.

Common misconceptions

• "ASLR and DEP solved this years ago." They raise the cost, but information leaks and code-reuse techniques let attackers work around them, which is why newer controls such as CFI and shadow stacks exist.
• "We must rewrite everything in Rust." The NSA and CISA CSI states adoption does not require a full rewrite. Android's results came mostly from new code.
• "Memory-safe languages make code secure." They remove this class, not logic flaws, injection or broken authorisation. Unsafe blocks and foreign function interfaces also reintroduce risk.
• "Read bugs are low risk." Out-of-bounds reads can leak tokens and keys, as CitrixBleed showed, and supply the address leaks used in larger chains.
• "Only vendors need to care." Every organisation runs C and C++ code in its browsers, VPNs, firewalls and hypervisors, so patching and exploit protection are everyone's job.

Common failure patterns

• Patching without revoking: fixing a memory disclosure bug in a gateway but leaving stolen sessions valid, the lesson of the CitrixBleed 2023 breach.
• Hardening flags lost in the build: mitigations set in one build script but dropped by a vendor toolchain, a static library or a release configuration, with nobody checking the shipped binary.
• Exploit protection disabled for compatibility and never revisited: an exception granted for one legacy application becomes permanent.
• Fuzzing once: a one-off fuzzing campaign before release instead of continuous fuzzing as code changes.
• CVSS-only prioritisation: treating an actively exploited browser use-after-free like any other high score instead of using KEV and exploit intelligence.

Related concepts

Related topics: C and C++ Secure Coding Guide, Rust Security Guide, WebAssembly Security Guide, and side-channel leaks, which read memory without corrupting it, in the Side-Channel Attacks Guide.

Practitioner checklist

• Tag memory safety CWEs in your vulnerability data and fast-track those in KEV on internet-facing and identity systems.
• Revoke sessions and rotate secrets after any memory disclosure bug in an authentication path, not just patch.
• Define a baseline of compiler and linker hardening flags and verify it on shipped binaries in CI.
• Deploy Windows exploit protection in audit mode, review Security-Mitigations events, then enforce by ring.
• Run AddressSanitizer in test builds and continuous fuzzing for every parser of untrusted input.
• Sandbox remaining C and C++ parsing in low-privilege processes.
• Set a policy that new components default to a memory-safe language, with documented exceptions.
• Ask suppliers for their memory safety roadmap during procurement and renewal.

Standards and references

• NSA and CISA: Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development
• CISA: The Case for Memory Safe Roadmaps
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE: 2024 CWE Top 25 Most Dangerous Software Weaknesses
• OpenSSF: Compiler Options Hardening Guide for C and C++
• Microsoft Learn: Exploit protection reference
• Chromium: Memory safety
• Google Security Blog: Eliminating Memory Safety Vulnerabilities at the Source

Related NHI Mgmt Group resources: Memory-Safe Languages Guide · Secure Coding Guide · Windows Endpoint Hardening Guide · Vulnerability Management Guide · Side-Channel Attacks Guide