RUSTSEC-2026-0308 (GHSA-XC3W-55VH-CW3W)
Vulnerability from osv_rustsec – Published: 2026-09-24 12:00 – Updated: 2026-09-24 14:38 – Source websiteWhen an application reads an interned value's fields or uses that value as an input to a tracked function, Salsa must ensure that reusable storage has been validated for the current database revision. This prevents the value's fields and associated cached function results from being freed while in use. Affected versions checked this invariant only with debug_assert! when reading fields, and did not check it when using an interned value to access a tracked function's cached result.
Bugs in Salsa's dependency tracking, or an application-provided Eq implementation that incorrectly treats a changed query result as unchanged, can cause Salsa to reuse cached results containing stale interned values. If the application accesses these values and then interns additional values, Salsa can free the old fields or cached function results while references to them are still in use. This causes use-after-free through safe Rust APIs. Depending on the consuming application, attacker-controlled input may expose process memory or permit arbitrary code execution.
The fix asserts that an interned value's reusable storage has been validated for the current database revision before allowing an application to read its fields or access a tracked function's cached result using that value as input. If the assertion fails, Salsa panics before returning references to storage that could be freed while in use.
Salsa 0.28.5 and newer address this vulnerability. Dependent applications should update Salsa and rebuild.
Applications that disable garbage collection for all explicitly declared interned structs using #[salsa::interned(revisions = usize::MAX)] and do not use implicitly interned query arguments are not affected by this vulnerability.
| URL | Type | |
|---|---|---|
{
"affected": [
{
"database_specific": {
"categories": [
"memory-corruption",
"memory-exposure",
"code-execution"
],
"cvss": null,
"informational": "unsound"
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "salsa",
"purl": "pkg:cargo/salsa"
},
"ranges": [
{
"events": [
{
"introduced": "0.23.0"
},
{
"fixed": "0.28.5"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-xc3w-55vh-cw3w"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "When an application reads an interned value\u0027s fields or uses that value as an input to a tracked function, Salsa must ensure that reusable storage has been validated for the current database revision. This prevents the value\u0027s fields and associated cached function results from being freed while in use. Affected versions checked this invariant only with `debug_assert!` when reading fields, and did not check it when using an interned value to access a tracked function\u0027s cached result.\n\nBugs in Salsa\u0027s dependency tracking, or an application-provided `Eq` implementation that incorrectly treats a changed query result as unchanged, can cause Salsa to reuse cached results containing stale interned values. If the application accesses these values and then interns additional values, Salsa can free the old fields or cached function results while references to them are still in use. This causes use-after-free through safe Rust APIs. Depending on the consuming application, attacker-controlled input may expose process memory or permit arbitrary code execution.\n\nThe fix asserts that an interned value\u0027s reusable storage has been validated for the current database revision before allowing an application to read its fields or access a tracked function\u0027s cached result using that value as input. If the assertion fails, Salsa panics before returning references to storage that could be freed while in use.\n\nSalsa 0.28.5 and newer address this vulnerability. Dependent applications should update Salsa and rebuild.\n\nApplications that disable garbage collection for all explicitly declared interned structs using `#[salsa::interned(revisions = usize::MAX)]` and do not use implicitly interned query arguments are not affected by this vulnerability.",
"id": "RUSTSEC-2026-0308",
"modified": "2026-09-24T14:38:19Z",
"published": "2026-09-24T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/salsa"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0308.html"
},
{
"type": "WEB",
"url": "https://github.com/salsa-rs/salsa/pull/1329"
}
],
"related": [],
"severity": [],
"summary": "Use-after-free in interned values and cached function results"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.