Does Rewriting in Rust Prevent AI-Discovered Vulnerabilities? The Honest Answer
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Every CISO who reads the memory safety headlines eventually asks the same question: if we rewrite in Rust, are we safe from the next wave of AI-discovered vulnerabilities? The honest answer is partial. Rust eliminates an important and historically large vulnerability class, but the bugs Claude Mythos found through Project Glasswing tell a more complicated story about where the remaining risk lives.
What Rust's Memory Safety Guarantee Actually Means
Rust enforces memory safety through a compile-time ownership and borrowing system. Every value has exactly one owner, references cannot outlive the data they point to, and mutable and immutable references cannot coexist. The result is that the compiler rejects programs that would produce buffer overflows, use-after-free bugs, dangling pointers, or double-free errors. These guarantees apply to safe Rust code. Unsafe Rust blocks exist and can introduce the same classes of bugs found in C, but their use is explicit and auditable.
Vulnerability Classes Rust Eliminates
In safe Rust, the following vulnerability categories are structurally prevented: buffer overflow and out-of-bounds write, use-after-free and dangling pointer dereference, double-free, null pointer dereference, and data races between threads (through the Send and Sync traits). These categories represent a substantial share of the CVE database for system-level software. For memory-intensive code parsing untrusted binary input, the risk reduction is real and large.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Vulnerability Classes Rust Does Not Address
Rust provides no protection against logic flaws in business rules, cryptographic misuse (using correct primitives in incorrect ways), authentication and authorization bypass, integer overflow in wrapping arithmetic, type confusion in safe code using trait objects, SQL injection and SSRF at the application layer, race conditions in program logic (as distinct from memory-level data races), and configuration or deployment errors. These categories are not language-level problems. They are semantic problems, and they are exactly where AI-scale vulnerability research increasingly focuses.
The Glasswing CVEs Through a Rust Lens
Project Glasswing has produced 9 confirmed CVEs. Examining them by vulnerability class reveals which would survive a full Rust rewrite. CVE-2026-5194 in wolfSSL (CVSS 9.1) is a certificate validation logic flaw: the trust chain verification is semantically incorrect, not memory-unsafe. A Rust wolfSSL port would carry the same bug. The smart contract vulnerabilities Glasswing found are logic bugs in state machine transitions. The FreeBSD CVE-2026-4747 involves kernel logic. The browser JIT and V8 ACE findings are closer to memory safety territory, but the underlying triggering conditions often involve type confusion and state management that can appear in safe abstractions. Roughly half of the Glasswing CVE set would survive a language migration.
Google's 70 Percent Memory Safety Statistic in Context
Google has repeatedly cited a figure showing approximately 70 percent of their high-severity security bugs involve memory safety issues. Microsoft has published similar numbers. This is a real and important finding, but it requires context. The Google figure covers Chromium, which is an unusually memory-intensive C++ codebase parsing attacker-controlled content. The proportion is likely lower for application-layer services, cryptographic libraries, and business logic. Applying the 70 percent figure uniformly to your own codebase without analyzing your own bug history will produce a misleading picture of your actual risk distribution.
The NSA Rust Guidance and What It Actually Says
The NSA's 2022 Cybersecurity Information Sheet on software memory safety recommends transitioning to memory-safe languages including Rust, Go, Java, C#, and Swift. It explicitly names C and C++ as the languages creating memory safety risk. What the guidance does not say is that memory-safe languages eliminate vulnerability risk. It recommends the transition as one component of a defense-in-depth strategy, alongside code auditing, fuzzing, and static analysis. Reading the NSA document as a comprehensive risk solution rather than a targeted intervention overstates what language choice can accomplish.
A Realistic Risk Reduction Model
A Rust migration of a C or C++ codebase that processes untrusted input can realistically eliminate 40 to 70 percent of the memory-safety-related CVE surface, depending on codebase profile. For a network-facing parser or a browser component, that is a significant gain. For an authentication service or a cryptographic key management system, the dominant vulnerability class is semantic and the gain is closer to 10 to 20 percent of overall vulnerability surface. The calculation should be specific to your codebase, not drawn from aggregate industry statistics.
What to Do Alongside a Rust Migration
A language migration is not a substitute for security review of business logic. The complementary controls that address what Rust cannot fix include formal cryptographic review of all protocol implementations, authentication and authorization model review independent of implementation language, AI-assisted semantic code analysis targeting logic flaws, fuzzing of all parser and protocol handling code regardless of language, and threat modeling at the design level before any code is written. The organizations that benefit most from Rust migrations are those that pair the language change with a systematic review of the vulnerability classes Rust cannot address.
Vulnerability Class Analysis from Project Glasswing
Project Glasswing's full CVE dataset, sorted by vulnerability class and annotated for Rust-survivability, is available in the Mythos Brief. This analysis identifies the specific categories where AI-discovered vulnerabilities would survive a full language migration and where migration provides genuine protection.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
Rust is a genuine and meaningful security improvement for codebases where memory corruption is the dominant vulnerability class. It is not a comprehensive answer to AI-scale vulnerability discovery, which increasingly targets the semantic, cryptographic, and logical layers that no language migration addresses. For the full vulnerability class analysis of the Glasswing CVE dataset and a migration ROI model specific to common codebase profiles, access the Mythos Brief at decryptiondigest.com/mythos-brief.
Frequently asked questions
Does Rust prevent buffer overflow vulnerabilities?
Yes. Rust's ownership and borrowing system enforces bounds checking at compile time and prevents the conditions that produce classic buffer overflow exploits. Out-of-bounds writes that corrupt adjacent memory cannot occur in safe Rust code.
Would a Rust rewrite have prevented the wolfSSL CVE?
No. CVE-2026-5194 (CVSS 9.1) is a certificate validation logic flaw, not a memory corruption bug. The vulnerability stems from incorrect trust chain verification, which is a semantic error that survives any language migration.
What percentage of CVEs are memory safety bugs?
Google's Project Zero and Chrome Security teams have reported that roughly 70 percent of their high-severity CVEs involve memory safety issues. Microsoft has published a similar figure for Windows vulnerabilities. The proportion varies significantly by codebase and software category.
Is Rust rewriting worth the investment?
For codebases processing untrusted input, implementing network protocols, or parsing complex binary formats, a Rust migration offers a measurable reduction in a large vulnerability class. The return is lower for application-layer business logic where the dominant bug class is semantic, not memory-safety-related.
Does Go provide the same safety guarantees as Rust?
Go is garbage-collected and prevents most memory corruption bugs, but it does not provide Rust's compile-time ownership guarantees. Go programs can still produce race conditions, nil pointer panics, and integer overflow issues that Rust's type system catches earlier.
How should security teams audit unsafe Rust blocks?
Unsafe Rust blocks require manual review because the compiler suspends its safety guarantees inside them. During a security audit, enumerate every unsafe block and FFI boundary, verify that raw pointer arithmetic is bounds-checked manually, confirm that invariants required by unsafe code are enforced in the surrounding safe API, and document the rationale for each unsafe block. Static analysis tools such as cargo-geiger quantify unsafe usage across the dependency tree and should be included in CI to flag new unsafe introductions.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.