fix(security): RUSTSEC-2026-0269 took the required ci / gate red on EVERY open PR at once

[noahgift]

Not a defect in any PR — an advisory-DB catch-up that fails a required check

cargo-audit picked up RUSTSEC-2026-0269 — wasmtime 43.0.2, "Filesystem sandbox escape when paths or symlinks contain trailing slashes", CVSS 8.8 HIGH, published 2026-08-20 — on 2026-08-31, and failed ci / security.

ci / security is not itself a required context, but the required ci / gate hard-requires it:

##[error]security did not succeed (result: failure)
Gate FAILED — a mandatory job did not succeed.
Note: cancelled and skipped both count as not-passed.

So every open pull request went red simultaneously — #2799, #2800, #2801, #2802, #2803 — with nothing wrong in any of them. main's last run was green at 745fa8588 on 2026-08-30, eleven days after the advisory was published, so this is the advisory database catching up rather than any change in this repository. This is the "all-PRs-red + nothing changed in-repo" signature.

Reachability — re-verified, not inherited

This is the twelfth wasmtime/cranelift advisory handled by the policy already written into .cargo/audit.toml. It is the highest severity of them, so the "test-only, not production" claim was re-derived rather than taken from the entries above:

cargo tree -p aprender                        -> 0 wasmtime paths
cargo tree -p aprender --no-default-features  -> 0 wasmtime paths
cargo tree -p apr-cli                         -> 0 wasmtime paths

wasmtime is optional and gated behind aprender-test-lib's runtime feature, which nothing in the workspace enables. It reaches cargo-audit only because Cargo.lock records optional dependencies. No shipped artifact links it, and nothing here runs untrusted wasm with a preopened directory — the only configuration in which the escape is reachable at all.

Why this is a deferral and not the fix

There is no fixed 43.x. The advisory's ranges are >=24.0.13,<25 | >=36.0.14,<37 | >=46.0.3,<47 | >=47.0.4. The real fix is the same three-major-version bump that the RUSTSEC-2026-0222 note directly above this entry already defers, and it must land before anything starts enabling runtime. That is a dependency decision worth its own ticket, not something to rush through to unblock a queue.

Verification

Mutation-verified, the same way the guards in this repo are:

	cargo audit
entry removed	rc=1 (error: 1 vulnerability found!)
entry present	rc=0

One file, one entry, no lockfile change.

🤖 Generated with Claude Code

[noahgift]

Independent verification of this PR's reachability claim, done in a separate worktree off
origin/main 745fa85 without reading this branch first. Claim CONFIRMED — this
containment is correct. Two notes, one methodological and one that strengthens it.

The three cargo tree invocations reproduce, plus five more. A zero from a command
that silently did nothing proves nothing, so the pattern was positive-controlled first
(-p aprender-test-lib --features runtime -> 35 matches) and every tree below is
non-empty:

invocation	tree lines	wasmtime
cargo tree -p aprender	1808	0
cargo tree -p aprender --no-default-features	140	0
cargo tree -p aprender --all-features	2051	0
cargo tree -p apr-cli	1904	0
cargo tree -p apr-cli --all-features	2155	0
cargo tree -e normal -p aprender	1713	0
cargo tree --workspace	3539	0
cargo tree --workspace --all-features	5492	35

Methodological warning for anyone re-running this. My first pass reported 81 wasmtime
paths in -p aprender and briefly looked like it refuted the claim. It did not — my
worktree was named aprender-wasmtime-fix, so a bare grep wasmtime matched the path on
every line. An earlier loop also reported rc=101, 0 matches on all five invocations,
which looked like clean zeros; that was zsh not word-splitting an unquoted $args, so
cargo received one bogus argument and died. Two different ways to get a confident wrong
answer out of this exact check, in five minutes. Anchor the pattern to the crate name
(wasmtime[a-z-]* v[0-9]), assert the tree is non-empty, and read the exit code.

--all-features does pull it in (35), but no CI lane runs that. make coverage
(coverage-nightly.yml:195) is --workspace --exclude aprender-gpu --lib; cargo mutants
(ci.yml:1564) is -- --lib. The --all-features targets that would reach it (test-full,
coverage-full) are not CI-wired. Nothing in .github/workflows/, scripts/ or the
Makefile enables runtime.

Second, independent reason this is not exploitable — worth adding to the entry. The
advisory is filed against the wasmtime umbrella crate, but per GHSA-vqjp-4c8c-hfgg the
bug is in wasmtime-wasi: "Wasmtime's filesystem implementation provided in the
wasmtime-wasi crate contained a bug which allowed guests to escape their filesystem
sandbox." There is no wasmtime-wasi in Cargo.lock at all — the 14 wasmtime entries are
the core engine and cranelift internals — and runtime.rs uses a bare Linker with four
host functions and no filesystem access. The vulnerable code is not merely unreachable; it
is not compiled. So this containment is even safer than the entry claims.

The fix is ready and is much smaller than the file's own deferral note assumed. #2807
takes wasmtime to 47.0.4 with zero source changes — 73 runtime tests pass unmodified
— and deletes all ten wasmtime exemptions, cargo audit exit 0. The RUSTSEC-2026-0222
note called it "a four-major jump" and deferred it on that basis; there is no API breakage
at all. The only blocker is that wasmtime >=46 needs Rust 1.94.0 against a 1.93.0
rust-toolchain.toml pin, and that does not affect CI because nothing builds the feature.

Land this, then #2807. Details and the second-deferral history in #2806.

[noahgift]

Two corrections to this PR's own reasoning, recorded here rather than as a new commit — a push would reset the already-green ci / security on this branch and re-roll the flake dice, and #2805 is currently the fastest single file that can reach main and unblock the queue. #2807 deletes this entry anyway.

1. The containment argument in this PR is understated. I argued unreachability from cargo tree. The stronger fact is that per GHSA-vqjp-4c8c-hfgg the vulnerable code lives in wasmtime-wasi, and there is no wasmtime-wasi in Cargo.lock at all — verified, 0 occurrences; the 14 wasmtime packages present are core/environ/cranelift/winch only. Not merely unreachable: not compiled.

2. The deferral rationale I inherited from the RUSTSEC-2026-0222 note is false. That note calls the bump "a four-major jump on a test-only dep," implying API breakage. #2807 shows the bump to 47.0.4 is zero source changes, 73 tests pass, and all ten wasmtime exemptions delete cleanly. I repeated that premise without checking it, which is exactly how a rule gets deferred a third time — the failure mode #2806 exists to prevent.

So this entry is a queue-unblocking stopgap with a named successor, not a judgement that the bump is hard. Land this, then #2807 removes it.

The real cost of #2807 is toolchain, and the number is worth stating precisely because it decides whether #2807 is cheap:

• rust-toolchain.toml pins channel = "1.93.0" — this is the pin that must move to >= 1.94.
• The declared MSRV is separate: workspace rust-version = "1.91", enforced by scripts/check_msrv.sh (floor) with toolchain-ceiling.yml guarding the ceiling.

Open question for #2807, raised on #2806: does the floor have to move at all? wasmtime is optional and gated behind aprender-test-lib's runtime feature, which nothing enables, and cargo only enforces rust-version for crates it actually builds. If the floor can stay at 1.91 and only rust-toolchain.toml moves, #2807 costs one line and no published-MSRV break for downstream consumers. If the floor must go 1.91 -> 1.94, that is a crates.io-visible break and a much bigger decision.