Why Rust memory-safety CVEs differ from C and C++

Rust’s CVE story is easy to misread if you only look at the total number of entries. Kobzol’s June 15 post gets at the real issue: a CVE count is not a clean measure of whether Rust is “as safe” as C or C++, because the metric flattens together very different bug classes, reporting patterns, and remediation paths. The more useful question is not whether Rust has vulnerabilities, but how often the language prevents memory-safety bugs outright and how often the remaining risk is pushed into explicit, auditable corners.

Raw CVE counts are the wrong scoreboard

A CVE is a label, not a diagnosis. In Rust, a vulnerability can stem from unsafe code, dependency behavior, platform quirks, or plain logic mistakes, while in C and C++ memory unsafety can be woven through the codebase in a much more implicit way. If you compare the raw number of CVEs across the languages without separating those categories, you end up treating a narrowly scoped unsafe bug and a broad memory-corruption class as if they were the same thing.

That is why Kobzol’s argument lands: the interesting comparison is memory safety, not the total CVE pile. Rust’s type system removes whole classes of undefined behavior from safe code, so a flat count tells you nothing about how many bugs never existed in the first place. It also tells you nothing about how many remaining issues were forced into a visible unsafe boundary that reviewers can actually inspect.

What Rust’s safety boundary really buys you

Rust documentation draws the line clearly: safe Rust cannot cause undefined behavior. The `unsafe` keyword marks code or interfaces that the type system cannot verify, and the classic examples are raw pointers, unsafe functions, mutable statics, and union access. That boundary matters because it changes the shape of the bug surface. In C and C++, memory mistakes can be spread across ordinary code paths; in Rust, the dangerous operations have to be declared and, in practice, are easier to isolate.

That does not make Rust magically immune. It means the surrounding ecosystem sees a different profile of issues, especially for library authors. If a crate exposes a risky operation, the unsafe block is usually small, explicit, and reviewable. The Rustonomicon reinforces that model by treating unsafe code as a boundary between safe code and operations the type system cannot prove correct. The Rust Project has tightened that boundary even further: Rust 1.85.0 began requiring explicit unsafe marking for extern blocks and for certain unsafe attributes, making the distinction harder to miss during review.

Why memory-safety data from Microsoft and Google matters here

The broader industry already treats memory safety as a first-order security problem, which is why Rust’s CVE discussion cannot be reduced to a scoreboard argument. Microsoft said in 2019 that about 70% of the security vulnerabilities it fixes and assigns a CVE are due to memory safety issues, and Matt Miller’s team has kept pointing to that figure as evidence that the core problem is structural, not cosmetic. The message is simple: if most of the pain comes from memory safety, then reducing memory-unsafety exposure changes the security baseline in a meaningful way.

Google’s Android data tells a similar story. Its memory-safety vulnerability count fell from 223 in 2019 to 85 in 2022, while memory safety issues went from 76% of Android’s total vulnerabilities in 2019 to 35% in 2022 and then to 24% in 2024. That trend matters because it shows what happens when more new code shifts into memory-safe languages and away from the traditional unsafe model. The language choice does not eliminate bugs, but it can shrink the most expensive class of bugs by a large margin.

Policy pressure has moved the argument beyond language preference

This is no longer just an internal systems-programming debate. The National Security Agency published software memory-safety guidance in 2022 and explicitly recommended memory-safe languages where possible. In 2023, the NSA and international partners issued The Case for Memory Safe Roadmaps, and the Cybersecurity and Infrastructure Security Agency followed with guidance in June 2025 on reducing memory-related vulnerabilities in modern software development.

That policy backdrop explains why Rust comparisons need to be more careful. Government and industry are not asking whether a language can make all vulnerabilities disappear. They are asking whether it can reduce exposure to the class of bugs that most often becomes exploitable code execution, data theft, or hard-to-triage incident response. Raw CVE counts do not answer that question well, because they ignore whether a vulnerability was avoidable by design or merely patched after the fact.

Rust CVEs exist, but they do not tell the whole story

Rust does have CVEs, including recent issues in Cargo and the Rust standard library. That fact is important because it keeps the discussion honest: Rust is not a guarantee of perfection, and no mature ecosystem is free of security bugs. But the presence of CVEs in Rust does not automatically mean Rust and C/C++ have the same security profile. It often means the opposite, because a Rust vulnerability may come from edge cases, platform-specific behavior, or a bug in a safe abstraction layered on top of unsafe internals.

The Rust compiler book itself notes that parts of the standard library are safe abstractions built over unsafe code and have historically been vulnerable to memory corruption. That is exactly the kind of nuance raw totals erase. A CVE in a Rust crate may reflect a failure in a narrow unsafe section, a dependency problem, or a logic flaw, while the broader language model still keeps most ordinary code outside the undefined-behavior danger zone.

The right way to read the numbers

The most honest way to interpret Rust’s security story is as risk reduction, not perfection. Rust can dramatically reduce the space of memory bugs while still leaving room for panics, unsafe misuse, logic mistakes, and protocol-level flaws. That is a much more realistic lens for teams choosing a systems language today, and it is also the one that lines up with the data from Microsoft, Google, the NSA, and CISA.

Kobzol’s point is the one that survives the noise: the real comparison is not whether Rust has CVEs, but whether those CVEs measure the same thing as C and C++ CVEs. They do not. Rust moves dangerous code into explicit boundaries, prevents many memory bugs before they exist, and makes the remaining risk easier to audit. That is the difference raw counts miss, and it is the difference that matters when you are trying to understand security outcomes in the real world.