Rust Memory Safety Issues Found by Microsoft FORGE

Introduction

Microsoft’s FORGE Lab has published new research on memory safety issues in Rust’s standard library, showing that even code written in safe Rust can, in rare cases, trigger undefined behavior when unsafe internals break their safety contracts. This matters because Rust is increasingly used in security-sensitive software, platforms, and services across Microsoft and the broader industry.

What Microsoft found

Using Hyenas, FORGE’s AI-assisted vulnerability research system, researchers identified and validated several soundness bugs in Rust’s std and core libraries. The post groups the findings into three recurring patterns of misplaced trust in unsafe code:

• Trusting code not to panic

  • Unsafe code may temporarily violate invariants and assume execution will complete normally.
  • If user-controlled code panics during that window, destructors can run against invalid state and cause undefined behavior.

• Trusting user-provided implementations

  • Unsafe code may assume trait implementations such as AsRef behave consistently.
  • A safe but unexpected implementation can break those assumptions and lead to out-of-bounds access.

• Trusting the underlying system

  • Some unsafe code relies on platform or system behavior that may not always hold as expected.
  • When those assumptions fail, Rust’s safe API surface can still be affected.

One example highlighted is a panic-safety issue in MapWindows::clone, where a panic during cloning could expose uninitialized memory to a destructor. Microsoft reported the issue, and the mitigation uses ManuallyDrop so partially initialized state is leaked instead of unsafely dropped.

Why this matters for security teams

Rust still significantly reduces entire classes of memory safety vulnerabilities compared with traditional systems languages. However, this research is a reminder that unsafe Rust remains a critical review area, especially inside foundational libraries that many applications depend on.

For security teams and developers, the key takeaway is not that Rust is unsafe, but that its guarantees depend on correct unsafe implementations beneath safe APIs. Bugs in std or core can have ecosystem-wide impact because so much modern software relies on them.

Impact on administrators and engineering leaders

For most IT administrators, there is no immediate tenant-level action required. But teams that build or ship Rust-based software should pay attention because:

• Standard library bugs can affect downstream applications broadly
• Secure code review practices for unsafe Rust remain essential
• AI-assisted vulnerability discovery is becoming more effective in core platform components

Next steps

• Monitor Rust issue tracker updates tied to the reported findings
• Review internal Rust projects that use unsafe code or depend on nightly features
• Incorporate panic-safety and trait-assumption checks into secure development reviews
• Track Microsoft security research on AI-assisted code analysis for future tooling implications

Rust remains an important part of modern secure software development, but this research shows that memory safety still requires careful engineering at the lowest layers.