Since its inception in 1972, the C programming language has employed a design philosophy that gives developers free reign and fine-grained control. Unfortunately, despite multiple generations of new engineers, C projects still suffer from chronic human errors that lead to vulnerabilities. Newer languages like Rust have taken a different approach with the stated goal of mitigating these errors via enforcing types and borrow checking at compile-time. These guarantees are promising, and indeed much work is being committed to “translating” C to Rust. But how much of an impact would Rust have had? The goal of this work is to inform the discussion around secure programming language designs by historically analyzing vulnerabilities in C with respect to Rust. We made a comprehensive mapping of the entire Common Weakness Enumeration vulnerability taxonomy to what Rust would be able to mitigate. We identified 68 prominent open source projects with C code, collected their vulnerability history data, and used their CWE designations to explore a best-case speculation on how many vulnerabilities might have been prevented with Rust. We estimate that 58.2% of historical vulnerabilities in our selection of open source C projects would have been virtually impossible in Rust. Depending on one’s expectations, this number might be surprisingly high or surprisingly low, so we hope this study will help ground the discussion about the decision for C projects to “oxidize.”