CVE-2020-35882
Description
In Rocket before 0.4.5, cloning a LocalRequest creates multiple mutable references to the same underlying Request, enabling unsound aliasing and potential data races.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In Rocket before 0.4.5, cloning a LocalRequest creates multiple mutable references to the same underlying Request, enabling unsound aliasing and potential data races.
Vulnerability
Description
The Rocket web framework for Rust contains an unsoundness in its LocalRequest::clone implementation. The LocalRequest type uses unsafe code to share a raw pointer to a Request object between a LocalRequest and a LocalResponse, justified by the fact that modifications from one are not observable from the other. However, the Clone implementation for LocalRequest allows creating two LocalRequest instances that both hold the same raw pointer, violating Rust's aliasing rules by creating multiple mutable references to the same object [1][2]. This can lead to a data race when both instances are used concurrently.
Exploitation
Conditions
Exploitation requires an attacker to be able to send requests to a Rocket application using the local testing client (e.g., rocket::local::Client). The attack complexity is high because the attacker must carefully time operations to trigger the data race. The RustSec advisory assigns a CVSS score of 8.1 (High) with a network attack vector, indicating that the vulnerability can be exploited remotely under certain conditions [4]. The proof-of-concept demonstrates that after cloning a LocalRequest, modifying one instance can cause the other to hold dangling references, leading to undefined behavior [2].
Impact
Successful exploitation can result in memory corruption, potentially leading to arbitrary code execution, information disclosure, or denial of service. The CVSS vector indicates High impact on confidentiality, integrity, and availability [4]. Because the issue is a violation of Rust's memory safety guarantees, any outcome from undefined behavior is possible.
Mitigation
The vulnerability is patched in Rocket version 0.4.5 and later. Users should upgrade to at least 0.4.5. Versions prior to 0.4.0 are unaffected because LocalRequest was introduced in 0.4.0 [4]. No workarounds are available; upgrading is the recommended action.
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
rocketcrates.io | >= 0.4.0, < 0.4.5 | 0.4.5 |
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"LocalRequest::clone creates multiple mutable references to the same Request object via a raw pointer, violating Rust's aliasing rules and enabling iterator invalidation."
Attack vector
An attacker who can control test code using `LocalRequest` can call `clone()` to obtain two `LocalRequest` instances sharing the same internal `Request` pointer [ref_id=1]. By mutating one instance (e.g., adding headers that trigger a reallocation of the header map) while holding an iterator from the other instance, the attacker can cause the iterator to become a dangling pointer [ref_id=1]. This can lead to reading attacker-controlled memory, as demonstrated by a segfault when the dangling slice's pointer and length are controlled [ref_id=1]. The precondition is that the attacker controls the test code that uses the Rocket testing API [CWE-362].
Affected code
The vulnerability is in `LocalRequest::clone` in `core/lib/src/local/request.rs` (lines 477–487) [ref_id=1]. `LocalRequest` uses a raw pointer to a shared `Request` instance, and its `Clone` implementation creates two `LocalRequest` objects pointing to the same `Request` without any synchronization, violating Rust's aliasing rules [ref_id=1].
What the fix does
The advisory recommends redesigning `LocalRequest` to avoid the unsound `Clone` implementation, for example by using safe alternatives such as `get_mut()` or `make_mut()`, or by having `Clone` clone the internal `Request` rather than sharing the raw pointer [ref_id=1]. The fix was applied in Rocket version 0.4.5. The core issue is that the original `Clone` implementation duplicated the raw pointer without accounting for Rust's aliasing rules, allowing concurrent mutable access to the same `Request` object [CWE-362].
Preconditions
- inputAttacker must control test code that uses Rocket's LocalRequest API
- inputAttacker must call clone() on a LocalRequest to create a second mutable reference to the same internal Request
Reproduction
The following PoC reproduces the issue on Rocket v0.4.4 [ref_id=1]:
```rust use rocket::http::Header; use rocket::local::Client; use rocket::Request;
fn main() { let client = Client::new(rocket::ignite()).unwrap(); let request1 = client.get("/").header(Header::new("key", "val1")); let request2 = request1.clone(); assert_eq!( request1.inner() as *const Request<'_>, request2.inner() as *const Request<'_> ); let mut iter = request1.inner().headers().get("key"); request2 .header(Header::new("1", "v1")) .header(Header::new("2", "v2")) .header(Header::new("3", "v3")) .header(Header::new("4", "v4")) .header(Header::new("5", "v5")) .header(Header::new("6", "v6")) .header(Header::new("key", "val2")); let _: Vec<usize> = vec![0, 0xcafebabe, 31337, 0]; let s = iter.next().unwrap(); dbg!(s.as_ptr()); dbg!(s.len()); println!("{}", s); // segfaults } ```
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- github.com/advisories/GHSA-8q2v-67v7-6vc6ghsaADVISORY
- nvd.nist.gov/vuln/detail/CVE-2020-35882ghsaADVISORY
- github.com/SergioBenitez/Rocket/issues/1312ghsaWEB
- rustsec.org/advisories/RUSTSEC-2020-0028.htmlghsax_refsource_MISCWEB
News mentions
0No linked articles in our index yet.