Memory safety remains a major software-security concern. Microsoft reported that approximately 70% of the CVEs it fixed from 2006 through 2018 were caused by memory-safety issues, while Google has continued to find high concentrations in browsers, Android, and other memory-unsafe codebases. The figures below are not directly interchangeable: the sources measure different populations, including CVEs, security-bulletin vulnerabilities, high- or critical-severity bugs, exploited vulnerabilities, and lines of code.
Contents
- How common are memory-safety vulnerabilities?
- What browser and Chromium data shows
- How Android counts have changed
- Severity, exploitation, and vulnerability lifetime
- What language and codebase comparisons show
- How exposed critical open-source projects are
How common are memory-safety vulnerabilities?
The most frequently cited broad estimate comes from Microsoft’s analysis of its own fixes. In the period from 2006 through 2018, approximately 70% of the CVEs Microsoft fixed were caused by memory-safety issues. The measurement covers Microsoft’s fixed CVEs across that 13-year period; it is not a count of every vulnerability in all software. Microsoft, “We need a safer systems programming language”
A CISA-cited industry summary places memory-safety issues at about 70% of reported vulnerabilities for Microsoft and Google, with reporting through 2023. The same summary says that 32 of 34 critical or high Mozilla bugs in a cited Mozilla analysis were memory-safety vulnerabilities. Those numbers describe the populations and classifications used in the underlying analyses, rather than a universal rate for every software project. CISA and partner agencies, “The Case for Memory-Safe Roadmaps”
Google’s 2024 estimate offers two related perspectives. It estimated that about 70% of severe vulnerabilities in memory-unsafe codebases are memory-safety bugs. It also estimated that 75% of CVEs used in zero-day exploits were memory-safety vulnerabilities, based on a 2023 threat-intelligence study. These are estimates, not a new all-software census. Google, “Safer with Google: Advancing Memory Safety”
Project Zero’s in-the-wild tracking gives a smaller but more operationally focused population. It recorded 58 in-the-wild zero-days in 2021, including 39 memory-corruption vulnerabilities, or 67%. Its previous record was 28 detected in-the-wild zero-days in 2015. The comparison indicates how the number of observed zero-days changed in Project Zero’s tracking, but does not establish that all real-world zero-days were found. Google Project Zero, “The More You Know, The More You Know You Don’t Know”
| Measurement | Result | Period or basis |
|---|---|---|
| Microsoft fixed CVEs caused by memory-safety issues | About 70% | 2006–2018 |
| Memory-safety issues in reported Microsoft and Google vulnerabilities | About 70% | Reported through 2023 |
| Memory-safety share of Project Zero’s 2021 in-the-wild zero-days | 39 of 58; 67% | 2021 |
| Memory-safety share of CVEs used in zero-day exploits | 75% estimate | Based on a 2023 study; reported in 2024 |
What browser and Chromium data shows
Chromium’s own analysis covered 912 high- or critical-severity security bugs affecting the Stable channel since 2015. Around 70% of those high-severity bugs were memory-unsafety problems, and half of the memory-unsafety problems in the analysis were use-after-free bugs. Because the denominator is restricted to high- or critical-severity Stable-channel bugs, this should not be read as the share of every Chrome defect. Chromium, “Memory safety”
Google separately reported in 2019 that more than 60% of Chrome’s high-severity vulnerabilities were memory-safety errors. The two browser measurements use different reporting contexts and dates, but both point to memory safety as a large share of severe browser security work. Google, “GWP-ASan: Sampling heap memory error detection in-the-wild”
Chrome’s mitigation measurements also show the engineering trade-offs involved. In 2022, Google reported rewriting more than 15,000 raw pointers in Chrome into raw_ptr<T> for MiraclePtr protection. Google estimated that MiraclePtr could protect about 50% of Chrome use-after-free issues against exploitation. In a Chrome 99 measurement, the protection increased browser-process memory use by 4.5%–6.5% on Windows and 3.5%–5% on Android. Quarantined memory represented 0.01% of Chrome browser-process usage in that measurement, while main-thread contention increased by about 7% on Windows. Google, “Use-after-freedom: MiraclePtr”
These figures measure mitigation cost and estimated protection, not a reduction in the total number of memory-safety bugs. They are useful for understanding why browser security programs measure memory, CPU contention, and exploitability alongside vulnerability counts.
How Android counts have changed
Android’s published counts show a substantial decline in memory-safety vulnerability numbers and share. The annual count fell from 223 in 2019 to 85 in 2022. Memory-safety issues made up 76% of Android vulnerabilities in 2019 and 35% in 2022. Google also said Android security bulletins averaged around 20 reported vulnerabilities per month over the approximately four years discussed in its analysis. Google, “Memory Safe Languages in Android 13”
The 2022 Android data has an important severity split. Memory-safety vulnerabilities were 36% of Android security-bulletin vulnerabilities, but represented 86% of critical-severity security vulnerabilities and 89% of remotely exploitable vulnerabilities. They also accounted for 78% of confirmed in-the-wild exploited vulnerabilities on Android devices over the preceding few years through 2022. Around 15% of Android vulnerabilities in 2022 were denial-of-service vulnerabilities requiring a factory reset. These categories overlap in purpose but are not interchangeable denominators. Google, “Memory Safe Languages in Android 13”
Google’s 2024 update reported 27 memory-safety vulnerabilities through the September security bulletin and extrapolated 36 for the full year. The full-year figure is explicitly a forecast, and Google estimated that memory-safety issues would account for 24% of Android vulnerabilities in that year. A later Google update said memory-safety vulnerabilities fell below 20% of total Android vulnerabilities for the first time in 2025; Google described that update as near-final and published it before the year ended. Google, “Eliminating Memory Safety Vulnerabilities at the Source”; Google Online Security Blog, 2025
| Android measure | 2019 | 2022 | 2024 estimate | 2025 update |
|---|---|---|---|---|
| Annual memory-safety vulnerabilities | 223 | 85 | 36 forecast | — |
| Share of Android vulnerabilities | 76% | 35% | 24% forecast | Below 20% |
The annual counts should be read with their measurement dates. The 2024 total was extrapolated from January through September, and the 2025 percentage was described as a near-final update rather than a completed year-end result.
Severity, exploitation, and vulnerability lifetime
The Android figures show why a lower overall share does not necessarily mean a lower security priority. In 2022, memory-safety vulnerabilities were 36% of Android bulletin vulnerabilities but 86% of critical vulnerabilities, 89% of remotely exploitable vulnerabilities, and 78% of confirmed in-the-wild exploited vulnerabilities over the preceding few years. A vulnerability category can therefore be a minority of total findings while remaining dominant in the most consequential subsets. Google, “Memory Safe Languages in Android 13”
Age is another measured dimension. Google’s 2024 analysis estimated that five-year-old code had 3.4 times lower vulnerability density than new code when using USENIX lifetime data. Using Android and Chromium lifetime observations, it estimated a 7.4-times lower vulnerability density for five-year-old code than for new code. These are comparative estimates from different datasets, not a guarantee that every older component is safer. Google, “Eliminating Memory Safety Vulnerabilities at the Source”
The USENIX FOSS study, published in 2022, found an average vulnerability lifetime of around four years across its studied projects. Its project-level results were about two years for Chromium and about seven years for OpenSSL. A vulnerability lifetime describes how long a flaw remains in code under the study’s methodology; it does not measure how long an exploit is active. USENIX, “How Long Do Vulnerabilities Live in the Code?”
What language and codebase comparisons show
Android’s language transition provides measured codebase comparisons. Android 13 put about 21% of its new native C, C++, and Rust code in Rust, while the Android Open Source Project contained approximately 1.5 million lines of Rust code when Google reported the result in 2022. Google reported zero discovered memory-safety vulnerabilities in Android’s Rust code at the time of that Android 13 report. It also said historical vulnerability density exceeded one vulnerability per 1,000 lines of code in many Android C and C++ components. Google, “Memory Safe Languages in Android 13”
Google’s 2025 Android Rust analysis used roughly five million lines of Rust code. It found one potential Rust memory-safety vulnerability, fixed before release, and estimated a density of 0.2 vulnerabilities per million lines of code. Google’s historical Android C and C++ data showed memory-safety density closer to 1,000 vulnerabilities per million lines of code. The comparison uses historical C/C++ data and a 2025 Rust estimate, so the periods and measurement conditions differ. Google Online Security Blog, 2025
Approximately 4% of Android Rust code was inside unsafe blocks in Google’s 2025 discussion. Google also reported that Rust changes in Android had a rollback rate four times lower than the comparison set. These observations concern the Android codebase and Google’s comparison methods; they do not establish a universal rate for all Rust, C, or C++ projects.
How exposed critical open-source projects are
A joint government analysis examined 172 projects from the OpenSSF critical-projects list in a 2024 report. Fifty-two percent of those projects contained code in a memory-unsafe language, and memory-unsafe languages accounted for 55% of total lines of code across the analyzed projects. CISA and partner agencies, “Exploring Memory Safety in Critical Open Source Projects”
The largest projects had substantial exposure even when the averages are considered by project. Each of the ten largest analyzed projects had more than 26% of its lines written in memory-unsafe languages. The median memory-unsafe share among those ten was 62.5%, and four of the ten had shares above 94%. These figures describe source-code composition, not the percentage of vulnerabilities caused by that code.
The analysis also found that all three analyzed projects written in memory-safe languages depended on components written in memory-unsafe languages. That dependency result matters for C programmers and systems developers: changing a project’s primary language does not automatically remove memory-unsafe code from its supply chain.
Across products and the wider industry, Google reported that memory-safety vulnerabilities had represented more than 65% of vulnerabilities for more than a decade through 2022. A 2025 government information sheet also cited estimates that memory-safety issues made up 66% of iOS 12 CVEs and 71% of macOS Mojave CVEs. Those legacy platform figures come from cited studies and should not be treated as independently remeasured here. CISA and partner agencies, “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development”
Taken together, the measurements point to a consistent pattern: memory safety is often a large share of severe or exploitable defects, while language composition, code age, mitigation cost, and transitive dependencies all affect how that risk appears in a particular project.