Memory-corruption bugs fell from 31% to 14% of exploited flaws

01The line: a third of exploited flaws, then a seventh

The fall is not a straight line. The share held near a third in 2022 (160 of 486 entries) and fell to 28% in 2023 (46 of 165). It dropped to 17% in 2024, rose to 22% in 2025, and stands at 14% this year: 35 of 255 entries.¹ On the same calendar window, 1 January to 19 October, 2025 was at 22.5%, so this year’s fall is not an artefact of a part year.

02What drives it: three readings, none proven by this data

KEV records that a flaw was exploited and what kind of weakness it is. It does not record why attackers chose it, or how much code behind it was written in which language. Three explanations are on the record, each from people who measured something else.

Memory-safe code. Google says memory-safety bugs fell from 76% to 24% of Android’s vulnerabilities between 2019 and 2024 “as development shifted to memory safe languages”, and that most bugs live in new code, so writing new code safely pays off fastest.³ In November 2025 it reported the share below 20% for the first time, and a Rust density of 0.2 vulnerabilities per million lines against “closer to 1,000” for its C and C++.⁴ That is Android’s own code, not the KEV list.

Attackers moved. Google’s Threat Intelligence Group (GTIG) counted 43 of 90 zero-days exploited in 2025, 48%, in enterprise software and appliances, about half of them in security and networking products. It wrote that command injection and deserialisation “often allow for reliable remote code execution without the complexity of memory corruption exploits”.⁵ Verizon found edge devices and VPNs were 22% of exploitation targets in its 2025 report, up from 3%.⁷

Hardening. GTIG credited “vendor investments in exploit mitigations” for browser and mobile zero-days falling in 2024,⁶ and read 2025’s low browser count as a sign “that browser hardening measures are working”, while adding that better attacker tradecraft may simply hide more of it.⁵

Memory corruption has not gone. GTIG put memory-safety issues at roughly 35% of 2025’s zero-days,⁵ a narrower list than KEV, which also holds flaws exploited after a patch. And 10 of this year’s 35 memory-corruption KEV entries sit in network appliances: five in Citrix NetScaler, two in F5 BIG-IP, one each in FortiOS, PAN-OS and DD-WRT.¹ The two readings meet there: the edge is where attackers went, and some of it is still written in C.

03What it means for a buyer

Two governments have turned this into something a buyer can ask for. CISA and the FBI call it a “bad practice” to start new product lines for critical infrastructure in a memory-unsafe language such as C or C++ where alternatives exist, and asked makers of existing products to “publish a memory safety roadmap by the end of 2025”, starting with network-facing and cryptographic code. Products whose support ends before 1 January 2030 are exempt, and the guidance is voluntary.⁸⁹ We found no official count of which makers published one.

The EU’s Cyber Resilience Act names no language. Its Annex I requires products to be sold “without known exploitable vulnerabilities”, designed “to limit attack surfaces” and built with “exploitation mitigation mechanisms”; those duties apply from 11 December 2027.¹⁰ Since 11 September 2026, makers must already report actively exploited flaws, with an early warning within 24 hours.¹¹ Our 15 September piece sets out what that means for Indian exporters. We found no CERT-In, MeitY or NCIIPC guidance on memory-safe languages, so the US and EU texts are the reference an Indian buyer can point to.

Five questions to put to a vendor, in writing:

1. Have you published a memory-safety roadmap, and where can we read it?
2. What share of new code in this product is written in a memory-safe language, and since when?
3. Which internet-facing parts (the VPN or web front end, file and packet parsers, cryptography) are still C or C++?
4. How is code that bypasses the language’s checks, such as Rust’s unsafe blocks, reviewed and fuzzed?
5. What does the product do on input it does not expect? Memory safety does not stop a crash: on 18 November 2025 Cloudflare’s Rust proxy hit a hard limit, “panicked” and served errors.¹²

None of the five covers the families that grew. Authentication bypasses and injection flaws are just as possible in Rust as in C, so the answers belong beside a vendor’s patch record, not in place of it.