You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
wasmtime 47.0.4 is affected by RUSTSEC-2026-0315/0316: security job red on main and every PR #4633
cargo audit on main's Cargo.lock reports RUSTSEC-2026-0315 and RUSTSEC-2026-0316 against wasmtime 47.0.4 (fixed >=48.0.3, <49 or >=49.0.1). Fix: bump the workspace pin to 48.0.3, with no new audit ignore. PR #4632.
Evidence on main @ 8de4d45 (2026-10-14 18:30Z): Cargo.lock pins wasmtime 48.0.4, which is inside the patched range of both advisories (RUSTSEC-2026-0315: >= 48.0.3, < 49.0.0; RUSTSEC-2026-0316: >= 48.0.3, < 49.0.0). deny.toml has no ignore for either advisory, and cargo deny check advisories exits 0 with "advisories ok". The outcome in the title is met on main. I'm leaving closing this issue to the release owner.
0353–0359, 0361–0364 (plus rustls 0346–0349, already fixed on main by rustls 0.23.46)
The same tool and database flag the old lockfile and pass the new one, so the green is not vacuous. Neither .cargo/audit.toml nor deny.toml ignores any RUSTSEC-2026-03xx id.
Correction to my earlier evidence on this issue.cargo deny check advisories cannot show this either way. wasmtime enters the graph only through an optional feature of aprender-test-lib, and deny.toml sets all-features = false, so cargo-deny never scans wasmtime. Its "advisories ok" is green on 48.0.4 as well. My earlier comment cited that check; the version-range reading in it (48.0.4 inside the patched range of 0315/0316) still holds, but the deny run was not evidence. Lockfile-based cargo audit is the check that sees wasmtime.
Closed by the cop batch, 2026-10-14 22:3xZ. Met on main after #5361 (wasmtime 48.0.6): cargo audit is clean, and the same db flags 0353..0364 on the 48.0.4 lock, so the check is non-vacuous. Evidence: issuecomment-6179817323. The cargo-deny all-features gap is noted there.
Activity
docs(audit): PMAT-4633 — review input for the wasmtime 48.0.3 bump
noahgift commentedon Oct 14, 2026
Re-parent: former parent #4681 is closed. Moved under open epic #3997 (same 0.71 train).
noahgift commentedon Oct 14, 2026
Checked on
main@ 8c3b19c (2026-10-14):Cargo.tomlpinswasmtime = "48.0.3", andCargo.lockresolves wasmtime 48.0.4 (fix(deps): wasmtime 47.0.4 -> 48.0.3 for RUSTSEC-2026-0315/0316 #4632, merged).cargo audit -f Cargo.lock --jsonon that lock no longer lists RUSTSEC-2026-0315 or RUSTSEC-2026-0316.So this issue's own scope, the two wasmtime advisories, is met on main. I'm leaving the issue open for the closure decision.
noahgift commentedon Oct 14, 2026
Evidence on main @ 8de4d45 (2026-10-14 18:30Z): Cargo.lock pins wasmtime 48.0.4, which is inside the patched range of both advisories (RUSTSEC-2026-0315: >= 48.0.3, < 49.0.0; RUSTSEC-2026-0316: >= 48.0.3, < 49.0.0).
deny.tomlhas no ignore for either advisory, andcargo deny check advisoriesexits 0 with "advisories ok". The outcome in the title is met on main. I'm leaving closing this issue to the release owner.noahgift commentedon Oct 14, 2026
Evidence after #5361 (wasmtime 48.0.4 → 48.0.6), measured on
main@ b4b2a3e.Result: clean.
cargo audit0.22.1, advisory-db fetched 2026-10-15, which contains RUSTSEC-2026-0315, -0316 and -0353..-0364 (patched>= 48.0.6, < 49.0.0/>= 49.0.3for 0353):cargo auditmain@ b4b2a3eThe same tool and database flag the old lockfile and pass the new one, so the green is not vacuous. Neither
.cargo/audit.tomlnordeny.tomlignores any RUSTSEC-2026-03xx id.Correction to my earlier evidence on this issue.
cargo deny check advisoriescannot show this either way. wasmtime enters the graph only through an optional feature ofaprender-test-lib, anddeny.tomlsetsall-features = false, so cargo-deny never scans wasmtime. Its "advisories ok" is green on 48.0.4 as well. My earlier comment cited that check; the version-range reading in it (48.0.4 inside the patched range of 0315/0316) still holds, but the deny run was not evidence. Lockfile-basedcargo auditis the check that sees wasmtime.Leaving this open for the owner to close.
noahgift commentedon Oct 14, 2026
Closed by the cop batch, 2026-10-14 22:3xZ. Met on main after #5361 (wasmtime 48.0.6): cargo audit is clean, and the same db flags 0353..0364 on the 48.0.4 lock, so the check is non-vacuous. Evidence: issuecomment-6179817323. The cargo-deny all-features gap is noted there.