The easy version of this story is annoying and wrong: Rust got audited, dozens of CVEs showed up, therefore Rust is overrated.

The more useful version is sharper. Rust is still very good at deleting one whole category of pain. What it does not do is save you from the parts of systems programming that happen outside the compiler's control: path resolution, filesystem races, Unicode assumptions, option semantics, and the ugly little timing gaps between one syscall and the next.

That is why a fresh r/programming thread around Corrode's "Bugs Rust Won't Catch" article landed so hard. Developers were not reacting to memory unsafety. They were reacting to the fact that modern safe languages still have to negotiate with old operating-system reality, and that reality does not care how pretty your type signatures look.

What is actually verified

The official Ubuntu update on rust-coreutils is the primary source here, not the blog post reacting to it.

Ubuntu says it commissioned an external security audit of uutils, the Rust reimplementation of GNU coreutils, ahead of Ubuntu 26.04 LTS. It also says Ubuntu 25.10 shipped rust-coreutils by default to increase real-world testing before the LTS cycle. For Ubuntu 26.04, Canonical says it is shipping rust-coreutils 0.8 with most of the security fixes, but cp, mv, and rm still fall back to GNU coreutils because those utilities still had unresolved time-of-check to time-of-use issues during the release decision.

That alone is a useful reality check. The most security-sensitive parts were not waved through for ideological reasons. They were held back.

Ubuntu's post also publicly lists 44 CVEs tied to the audit process, from CVE-2026-35338 through CVE-2026-35381. Canonical frames that disclosure as part of a transparent hardening effort and says the long-term goal is "100% rust-coreutils" in Ubuntu 26.10, once the remaining issues are addressed.

Corrode's article adds the interpretive layer that made this into a broader developer discussion. The post argues that the interesting lesson is not "Rust failed," but that the surviving bugs cluster around places where safe Rust still has to model messy external state: paths that get re-resolved across syscalls, symlink races, non-UTF-8 filenames, and compatibility mismatches when reimplementing long-lived Unix tools.

That interpretation lines up with Ubuntu's own release choice. If cp, mv, and rm are the ones still withheld because of TOCTOU concerns, the compiler clearly was not the final line of defense.

Why this matters more than another language-war post

The low-quality takeaway is that safe languages are fake. The better takeaway is that the security boundary moved.

For years, systems-language arguments were dominated by memory corruption: use-after-free, buffer overflows, double free, and the rest of the greatest-hits catalog. Rust still helps a lot there. Corrode's piece makes that point explicitly, and it is hard to argue with. A Rust rewrite can avoid entire exploit classes that older C code spends years paying down.

But filesystems are not memory. They are shared mutable state exposed through names, handles, permissions, links, mounts, encodings, and timing. The bug appears when developers treat those names as stable facts instead of attacker-controlled references that can change between checks.

That is the part many developers miss when they hear "safe language." Safety in the language does not magically extend to a path that gets resolved twice, a symlink swapped at the right moment, or a utility whose edge-case behavior has to match decades of shell scripts.

In other words, Rust did not erase the hard part. It narrowed the battlefield.

The public reaction was telling

The Reddit thread in r/programming pushed the article into the hot feed within hours of publication, and the most useful comments were not doing the usual "language X versus language Y" routine. One highly upvoted reply agreed with the article's praise for the audit transparency, then zeroed in on path-based APIs and string equality checks as the kind of thing that still bites even careful Rust code.

Another Reddit commenter argued that Rust's std::fs surface makes this class of mistake too easy because privileged programs often need descriptor-anchored operations rather than path-based convenience calls. That is a strong claim, but it matches the shape of the discussion elsewhere.

Hacker News picked up the same post and pushed it onto the front page. The best comments there were not mocking Rust. They were debating how much safer file APIs should be exposed directly in higher-level tooling, and how hard secure filesystem interaction remains even when the core language removes memory-unsafe footguns. That reaction matters because it shows the story landed as a design problem, not just a tribal argument.

What remains uncertain

A few details need restraint.

First, Ubuntu's public update clearly confirms the audit, the 44 disclosed CVEs, the partial rollout in 26.04, and the decision to keep cp, mv, and rm on GNU coreutils for now. What it does not provide in the same post is a neat, officially summarized taxonomy of every root cause. Corrode's breakdown of bug patterns is informed and plausible, but it is still a secondary interpretation layered on top of Canonical's disclosure.

Second, the broader issue counts reported around the audit are less clean than the 44-CVE figure. Secondary reporting points to a larger set of findings beyond the CVEs, but the official Ubuntu post is the source I would trust for the disclosed CVE set and the shipping decisions.

Third, this is not evidence that Rust code is somehow less secure than the GNU originals in aggregate. It is evidence that a Rust rewrite still inherits the old Unix problem set once it starts touching the real filesystem under adversarial conditions.

The practical lesson for people shipping Rust

If you build privileged tools, installers, package managers, CI helpers, backup software, or anything else that walks the filesystem under attacker influence, this story is a warning not to confuse memory safety with total safety.

You should assume path-based logic is suspicious by default when the same resource is checked and then used later. You should treat Unicode conversions and string assumptions around filenames as potential correctness and security bugs, not cleanup work. And if you are rewriting old Unix tools, bug-for-bug compatibility is not just a compatibility chore. Sometimes it is part of the security model because scripts, exit codes, and strange edge cases already have operational meaning.

The deeper point is uncomfortable but healthy. Rust changes what you have to be paranoid about. It does not let you stop being paranoid.

The headline was "Bugs Rust won't catch." The better lesson is this: once your program crosses into the operating system, the compiler stops being your bodyguard and becomes just one member of the security team.

Sources