How many vulnerabilities are memory safety bugs? Read the figures

Vendors report that a large share of their serious bugs are memory safety problems: about 70% for Microsoft CVEs and Chromium high severity bugs, and over 60% for high severity Android vulnerabilities. The figures are not interchangeable, because each counts a different set of bugs in a different codebase.

The published figures

• Microsoft. A 2019 MSRC post says the root cause of approximately 70% of the security vulnerabilities Microsoft fixes and assigns a CVE is memory safety, and that the share had stayed near that level for over a decade.
• Chromium. The project says around 70% of its high severity security bugs are memory unsafety problems, with half of those use after free. The figure comes from 912 high or critical bugs since 2015.
• Android. The Android documentation says memory corruption and use after free account for over 60% of high severity vulnerabilities on the platform.
• ONCD. The 2024 White House report says that in some cases up to 70 percent of security vulnerabilities in memory unsafe languages that are patched and given a CVE are due to memory safety issues.

Why they differ

Different denominators. Microsoft counts CVEs it assigns. Chromium counts high and critical bugs in one browser. Android counts high severity platform vulnerabilities. A product written mostly in memory unsafe languages will show a high share, and one written in a managed language will show a low one.

Different time windows matter too. The Chromium analysis starts in 2015, and the Microsoft post dates from 2019. Both are snapshots, not live statistics.

What not to do with them

Do not quote 70% as a share of all vulnerabilities everywhere. The ONCD wording is deliberately narrow: it speaks of memory unsafe languages and of patched, CVE assigned issues. Do not mix numbers from different sources into a trend line either.

How to get your own number

1. Export your fixed vulnerabilities for a period you can name.
2. Map each to a weakness class (CWE) where the record has one.
3. Count the spatial and temporal classes, such as out-of-bounds write, out-of-bounds read and use after free.
4. Divide by the total, and note the share with no CWE recorded.

Your own figure, with its caveats written next to it, is more persuasive in a planning meeting than a borrowed headline number.

A worked example of reading a figure

Suppose a slide says 70% of vulnerabilities are memory bugs. Ask four questions. Which organization produced the number? What was counted, CVEs or all bugs, or only high severity ones? Over which years? And in what language mix was the code written?

If the slide cannot answer, treat the number as a talking point rather than evidence. The Chromium page is a good model of how to cite: it gives the share, the bug count behind it (912) and the start year. The Microsoft post says "approximately" and ties the figure to CVEs it assigns. Both tell you what the percentage is a percentage of.

Another trap is survivorship. A count of fixed and reported bugs says nothing about bugs nobody found. The ONCD report makes this point in a different way: even if every known vulnerability were fixed, undiscovered ones would remain, which is why it argues for removing whole classes.

Try it yourself

Click through it at your own pace, or open it full screen. Notice how findings can be grouped and filtered by weakness type.

Quick check

Sources

• Microsoft MSRC, We need a safer systems programming language
• Chromium memory safety page
• Android memory safety documentation
• Back to the Building Blocks, ONCD, February 2024

Last reviewed: 19 October 2026.