RUSTSEC-2026-0277: Path traversal in apimock-server's file-serving fallback

What to do

1. See which version you have: cargo tree -i apimock-server (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p apimock-server. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example apimock-server = "5.19.1") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

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.

Exposure depends on the bind address. The default is 127.0.0.1; deployments binding 0.0.0.0 or a LAN address are reachable from the network. Most HTTP clients normalise .. away before sending, so reaching it requires a client that does not.

All published versions before 5.19.1 are affected. Fixed in 5.19.1 by canonicalising each resolved path and rejecting anything outside its base directory.

**This advisory also covers apimock 5.x**, which depends on apimock-server. apimock 4.x predates the crate split and carries its own advisory for the same issue, fixed in 4.8.1.

References

• Package: crates.io/crates/apimock-server
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0277.html
• Web: github.com/apimokka/apimock-rs/commit/ff0dd152ecfccb3bf00e15cc92bd4d57e485c854

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.