Summary
mopa is technically unsound
The mopa crate redefines the deprecated TraitObject struct from core::raw like so:
#[repr(C)]
#[derive(Copy, Clone)]
#[doc(hidden)]
pub struct TraitObject {
pub data: *mut (),
pub vtable: *mut (),
}
This is done to then transmute a reference to a trait object (&dyn Trait for any trait Trait) into this struct and retrieve the data field for the purpose of downcasting. This is used to implement downcast_ref_unchecked(), in terms of which downcast_ref() is also implemented. Same goes for mutable reference downcasting and Box downcasting.
The Rust compiler explicitly reserves the right to change the memory layout of &dyn Trait for any trait Trait. The worst case scenario is that it swaps data and vtable, making an executable location breach and compromisation of ASLR possible, since reads from data would read vtable instead. Likewise, arbitrary code execution is also theoretically possible if reads of vtable generated by the compiler read data instead.
While, as of Rust 1.52, this unsound assumption still holds true, updating the compiler may silently create UB in a crate which previously compiled and run without issues, compromising the security of builds which are believed to be reproducible.
A potential strategy to resolve this has already been suggested in an issue on the GitHub repository of the crate.
Impact
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-8MV5-7X95-7WCF? GHSA-8MV5-7X95-7WCF is a high-severity security vulnerability in mopa (rust), affecting versions <= 0.2.2. No fixed version is listed yet.
- Which versions of mopa are affected by GHSA-8MV5-7X95-7WCF? mopa (rust) versions <= 0.2.2 is affected.
- Is there a fix for GHSA-8MV5-7X95-7WCF? No fixed version is listed for GHSA-8MV5-7X95-7WCF yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is GHSA-8MV5-7X95-7WCF exploitable, and should I be worried? Whether GHSA-8MV5-7X95-7WCF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-8MV5-7X95-7WCF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.