Skip to content
Fencer Intel
no cvss —

GHSA-72g6-wgrg-vhm7 json

Path traversal in apimock's file-serving fallback

published 2mo ago modified 2mo ago also RUSTSEC-2026-0276 , RUSTSEC-2026-0277

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

The file-serving fallback joined a request-derived path onto the configured response directory and checked only that the result existed, never that it stayed inside that directory. A request containing a raw `..` segment could read any file readable by the process, returned with HTTP 200.

Read-only: no write, no code execution.

On the 4.x line `apimock` is a single crate containing the serving code. Fixed in 4.8.1 by canonicalising each resolved path and rejecting anything outside its base directory.

**apimock 5.0.0 and later are not affected by this advisory.** From 5.0.0 the serving code moved to the `apimock-server` crate, which `apimock` depends on; that crate carries its own advisory for the same issue, fixed in 5.19.1.

Patch / fix

  • crates.io apimock 4.8.1, 5.0.0
  • crates.io apimock-server 5.19.1

Is GHSA-72g6-wgrg-vhm7 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
crates.io apimock
>=0.0.0-0, <4.8.1
>=5.0.0, <5.0.0
4.8.1
5.0.0
crates.io apimock-server
>=0.0.0-0, <5.19.1
5.19.1

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.