Programming

The C language's biggest problem: evidence of its insecurity

Written by FlyWithMe (a SimpleX chat user) —

C is not a memory-safe language. You can write secure software in C, but flawless memory management is not a realistic expectation, no matter how skilled the programmers are or how many reviews the code receives. Formal verification can help in rare cases; the seL4 microkernel and the CompCert compiler are two examples. But those projects are exceptions, not the normal path for most software.

In practice, formal verification is difficult, expensive, and narrow in scope. It should be treated as a limited tool, not a general answer to C's memory-safety problem.

For readers who argue that memory-management vulnerabilities are rare or obsolete, this article looks at the numbers directly.

Analysis: Memory Management Vulnerabilities in CVEs (2015-2025)

Total data

I analyzed registered CVEs from 2015 through December 20, 2025, using data from CVEDetails.com and the NIST NVD.

CVEs analyzed: 107,173

Memory-management vulnerabilities

  • Category: Overflow (buffer, stack). Total CVEs: 15,882
  • Category: Memory Corruption (heap, use-after-free, out-of-bounds). Total CVEs: 20,777
  • Total: 36,659

Percentage of memory-management vulnerabilities

36,659 ÷ 107,173 × 100 = 34.20%

Put simply, 34.20% of all software vulnerabilities registered between 2015 and 2025 were tied to memory-management errors, including buffer overflows, heap overflows, use-after-free bugs, and out-of-bounds reads or writes.

Distribution by year

The year-by-year breakdown fluctuates significantly:

Memory-management vulnerabilities by year (2015-2025)
Year Memory Vulnerabilities Total CVEs Percentage
2015 1,436 3,758 38.22%
2016 1,514 3,355 45.13%
2017 4,011 10,458 38.35%
2018 3,808 10,644 35.74%
2019 3,209 9,081 35.35%
2020 3,066 8,248 37.18%
2021 4,184 10,414 40.18%
2022 4,685 12,198 38.39%
2023 3,741 12,568 29.76%
2024 4,171 15,377 27.12%
2025 2,834 11,478 24.68%

Important context

The overall 34.20% figure changes sharply depending on the kind of software and the language used:

For compiled C/C++ code, the share rises to roughly 66–75%. Large organizations have reported the following:

  • Microsoft: 70% of CVEs are related to memory management.
  • Google: 70% of bugs in Chromium are memory-related; 90% on Android.
  • Apple: 60–70% of vulnerabilities in iOS and macOS.
  • Linux Kernel: 66% of vulnerabilities.
  • Project Zero (Google): 75% of CVEs exploited in the wild were memory-related; 67% of zero-days in 2021.

For memory-safe languages such as Java, Python, and C#, the proportion is less than 5%.

Temporal trend

The data shows an important distinction. The absolute number of memory vulnerabilities remains high, but their relative share dropped from roughly 38–45% in 2015–2016 to 24–29% in 2024–2025. That does not mean memory bugs disappeared. It means other categories grew faster, especially XSS at 31.18% of the total.

2026 preliminary data

According to CVE Program Metrics [24], 15,176 CVE records were published in Q1 2026. Q2-Q4 were still marked as TBA at the time of writing.

That confirms that CVE publication volume remained high into 2026. However, this figure should not be mixed directly with the 2015-2025 table above, because that analysis uses a different aggregation and categorization method: CVEDetails plus NVD, with "Overflow" and "Memory Corruption" grouped together.

Conclusion

Of the 107,173 software vulnerabilities registered between 2015 and 2025, 36,659, or 34.20%, were related to memory-management errors. That global percentage hides the more serious reality: in the compiled software that dominates critical infrastructure, especially C and C++, roughly two out of three vulnerabilities are caused by memory-management errors. This is why CISA, the NSA, and other agencies keep calling for memory-safe languages where they are practical.

References