Probably unlikely. There was that thread::scoped issue last year right before 1.0 where some incorrect assumptions lead to an unsafe API that was thought safe.

Probably unlikely. There was that thread::scoped issue last year right before 1.0 where some incorrect assumptions lead to an unsafe API that was thought safe. But it was unlikely to happen to app code and be exploitable. I examined every MS security bulletin over a 2 year period. Nearly all the serious ones were regular C/C++ code memory corruption issues. From what I could tell, Rust would have prevented every one. MS's .NET had a few serious bugs. They were basically all class loader logic bugs (XBAPs getting more permissions, ways to bypass the CAS system). It's similar to the Java plugin issues: Java applets themselves were never exploitable. But the plugin might accidentally let you do things you're not supposed to. The most user-impacting was stuff in ASP.NET, which is more like an app framework, not a runtime. (There were some "load up arbitrary code/read arbitrary file" bugs IIRC, caused by bad crypto and logic.) I actually found probably the first memory safety CLR bug[1]. If you loaded a function pointer of an un-jitted function, you could end up with a safe/verified pointer (delegate) to unmanaged code. So there's a true issue, where the implementation is letting you escape and do unsafe things while saying it's verified. But, there's basically no way for this to turn into an app-level security issue. The only use was to escape the .NET code-level sandboxing (CAS). 1: Well to my knowledge -- none were published before. But neither was this one so who knows how many there actually were.