Memory-safe rewrites are quietly eating C and C++ codebases one CVE at a time

Google and Microsoft have both reported that roughly 70 percent of the security vulnerabilities in their C and C++ codebases trace back to memory safety errors — buffer overflows, use-after-free, and similar bugs that a memory-safe language simply cannot express. That statistic has been public for years. What changed in 2026 is that the industry stopped debating whether to act on it and started shipping the fix, one subsystem at a time.

The Linux Kernel Stopped Treating Rust as an Experiment

At the 2025 Linux Kernel Maintainers Summit, maintainers formally declared the multi-year "Rust for Linux" effort a success rather than an ongoing trial. Rust is now used for new drivers and subsystems specifically to keep memory-safety bugs out of code that would otherwise be written in C. Linux stable kernel maintainer Greg Kroah-Hartman has been blunt about the motivation, stating that Rust "is going to save Linux" given the volume of CVEs the kernel generates from C code every year.

The approach isn't a free lunch. The first CVE assigned to Rust code in the kernel, CVE-2025-68260, landed in 2026 — a reminder that Rust's guarantees hold only within safe code, and that unsafe blocks (which the kernel still needs at hardware boundaries) reintroduce the exact class of bug the rewrite was meant to eliminate. Disciplined use of unsafe, not the mere presence of Rust, is what determines whether a component actually gets safer.

Coreutils Is Rust's Most Concrete Win So Far

The clearest evidence that this strategy works in practice is uutils coreutils, a from-scratch Rust reimplementation of the GNU coreutils designed as a drop-in replacement for tools like ls, cat, and grep. It passed 92.2 percent of the official GNU test suite in early 2026 and climbed to 94.74 percent by April. Ubuntu made rust-coreutils the default in its 25.10 release and is shipping version 0.8.0 — which folds in a wave of security fixes from a Zellic audit that found 113 issues, most now resolved — as the default in Ubuntu 26.04 LTS.

Notably, Ubuntu is not flipping the switch on every utility at once. cp, mv, and rm remain GNU implementations in 26.04 because of unresolved time-of-check-to-time-of-use (TOCTOU) race conditions in the Rust versions — the exact kind of bug class that memory safety alone doesn't fix, since it's a logic error rather than a memory error. A full transition is targeted for Ubuntu 26.10. That staged rollout is itself a useful signal: distro maintainers are treating each utility's rewrite as independently earning its way to default status, not adopting Rust coreutils as a package deal.

Not Every Maintainer Is Buying In

curl is the counterexample worth taking seriously. Maintainer Daniel Stenberg has explicitly ruled out a full Rust rewrite of the project's roughly 180,000 lines of C. An earlier experiment integrating a Rust-based Hyper backend was abandoned by April 2025 after the maintenance overhead outweighed user interest. curl remains open to individual Rust dependencies, but the core stays C — a position that looks harder to defend after curl faced a surge of vulnerability reports in spring 2026 severe enough that the project temporarily stopped accepting new reports in July 2026 to let maintainers catch up.

That's not necessarily a contradiction. curl's C codebase is small, single-purpose, and has decades of fuzzing and static-analysis coverage behind it — the kind of legacy code where a rewrite's transition risk can exceed the risk it's meant to eliminate. The lesson isn't that Rust rewrites are unambiguously good; it's that the calculus differs sharply between a kernel subsystem processing untrusted input at scale and a mature, narrowly scoped C library.

Where the Data Backs the Bet

The strongest quantitative case comes from Android. Google has reported roughly a 1,000x reduction in memory-safety vulnerability density in the Rust portions of Android's codebase compared to its C and C++ code, measured per line of new code shipped. That figure reflects Android's strategy of writing new code in Rust rather than rewriting old code wholesale — the same incremental philosophy now visible in the kernel and in coreutils.

None of this adds up to C and C++ disappearing. The volume of legacy code in production systems makes a full rewrite economically impossible for the vast majority of organizations. What's changed is that "memory-safe rewrite" has moved from an academic talking point to a line item that distro maintainers, kernel developers, and Google's own security team can point to specific CVE counts to justify.

What to Watch Next

If you maintain infrastructure that touches untrusted input — parsers, network-facing services, anything processing user-supplied data — the coreutils staged rollout is a useful template: identify the highest-value, most-attacked component first, rewrite it with a drop-in-compatible interface, and hold each replacement to the same test coverage as the code it replaces before flipping the default. Don't treat "written in Rust" as a security guarantee on its own; check whether the rewrite still has unresolved logic-level bugs like TOCTOU races before trusting it more than the C it replaced. And if you maintain a small, well-audited C codebase with strong existing tooling, curl's stance is a legitimate data point that a full rewrite isn't automatically the right call — the memory-safety math has to be weighed against real migration cost, not applied as a blanket rule.