Rust’s pitch is that safe code cannot corrupt memory. Microsoft’s researchers just published a list of places where the standard library makes that guarantee harder to keep.
FORGE Lab used Hyenas, its AI-powered vulnerability scanner and the research version of Microsoft’s agentic discovery system codenamed MDASH, to sweep unsafe code inside Rust’s standard library. The most striking find had survived there for nearly 11 years.
An exit that pulls the floor out
The stale bug sits in process::exit, where a call from any child thread can leave the runtime tearing down the main thread’s alternate signal stack while that thread is still mid-execution. Overflow the main thread’s stack afterward and the operating system may never receive the signal, so the process dies in a segmentation fault rather than the intended stack-overflow handling.
Nothing the team tried produced a dependable exploitation route, so Microsoft put practical abuse in the unlikely column.
Three classes of unsound assumption
Other findings fell into three buckets: code trusting user-supplied implementations, code assuming operations will not panic, and code that misjudges the underlying system. In MapWindows::clone a buffer was created before being fully initialized and then handed to a user-provided clone, so a panic could trigger a destructor against uninitialized memory. Also, when a program handed str::replace its own Pattern implementation, that code could put a non-ASCII byte in a slot reserved for an ASCII character, so the result was invalid UTF-8 that broke later operations.
Microsoft reported everything to Rust maintainers, and two of the findings affect stable Rust. The practical lesson is narrower than the headline: unsafe internals still back the safe API, and those boundaries deserve the same review as C and C++ code.
