| 1 |
# cargo-audit configuration, triaged advisory posture for the MNW server. |
| 2 |
# |
| 3 |
# Every ignore below is a transitive advisory we cannot resolve by bumping our |
| 4 |
# own direct deps, each with a rationale and (where relevant) the upstream we're |
| 5 |
# waiting on. Directly-fixable advisories are NOT parked here, they get fixed in |
| 6 |
# Cargo.toml/Cargo.lock (e.g. the ammonia mXSS RUSTSEC-2026-0193 was closed by |
| 7 |
# bumping to 4.1.3, not ignored). Re-review this list on every dependency audit. |
| 8 |
|
| 9 |
[advisories] |
| 10 |
ignore = [ |
| 11 |
# rsa, Marvin timing side-channel on RSA *decryption*. Pulled only by the |
| 12 |
# signature-*verification* crates (apple-codesign, authenticode, yara-x); we |
| 13 |
# never decrypt with rsa, so the decryption-oracle attack does not apply. |
| 14 |
"RUSTSEC-2023-0071", |
| 15 |
|
| 16 |
# The rustls-webpki 0.101 trio (RUSTSEC-2026-0098/0099/0104) and the git2 UB |
| 17 |
# pair (RUSTSEC-2026-0183/0184) were dropped on 2026-07-21: the EOL rustls |
| 18 |
# 0.21 stack left s3-storage in d7a50c5a and git2 has since been bumped, so |
| 19 |
# neither advisory is reachable. cargo-deny flags unreachable ignores as |
| 20 |
# `advisory-not-detected`; that is the signal to prune this list. |
| 21 |
|
| 22 |
# Unmaintained-crate warnings, all transitive (no direct dep, no code change |
| 23 |
# available to us). Tracked for when upstreams migrate off them. |
| 24 |
"RUSTSEC-2025-0141", # bincode (unmaintained), via transitive tooling |
| 25 |
"RUSTSEC-2020-0095", # difference (unmaintained), via a dev/test dep |
| 26 |
"RUSTSEC-2025-0134", # rustls-pemfile (unmaintained), via AWS SDK TLS |
| 27 |
"RUSTSEC-2026-0173", # proc-macro-error2 (unmaintained), via a macro dep |
| 28 |
|
| 29 |
# Two wasmtime advisories, both reached only through yara-x, which is the |
| 30 |
# only path to wasmtime in this graph (`cargo tree -i wasmtime`). yara-x |
| 31 |
# 1.19.0 declares `wasmtime = "43.0.2"` with `default-features = false` and |
| 32 |
# `features = ["cranelift", "runtime"]`, so 46.x is not reachable by bumping |
| 33 |
# anything we control and the feature set is the load-bearing fact for both |
| 34 |
# entries below. Waiting on yara-x in each case. |
| 35 |
# |
| 36 |
# Checked 2026-08-31: yara-x 1.20.0 does NOT help. It moves wasmtime to |
| 37 |
# 45.0.3, which every fixed range below also skips, with the same |
| 38 |
# default-features = false and the same two features. Bumping yara-x is |
| 39 |
# not the way out of either advisory; a wasmtime 46/47 line is. |
| 40 |
|
| 41 |
# RUSTSEC-2026-0222, "Stores can mix up type indices between engines" |
| 42 |
# (3.8 low, published 2026-07-31). Fixed in 24.0.12+, 36.0.13+, 46.0.2+ and |
| 43 |
# 47.0.3+, which skip the 43 line entirely. |
| 44 |
# |
| 45 |
# Not applicable as we run it. The precondition is a store crossing between |
| 46 |
# two wasmtime Engines, and production builds exactly one: scanning/mod.rs:505 |
| 47 |
# calls yara::compile_rules_from_dir once while constructing the ScanEngine, |
| 48 |
# and every other yara_x::Compiler::new() in the tree sits under the |
| 49 |
# #[cfg(test)] at scanning/mod.rs:884. One engine for the process lifetime |
| 50 |
# means two engines never exist to confuse. THAT is the load-bearing claim |
| 51 |
# here: if a second compile ever lands in a production path, this ignore stops |
| 52 |
# being justified and has to be re-argued (see the note in scanning/yara.rs). |
| 53 |
# |
| 54 |
# Worth being precise about the blast radius rather than calling it isolated: |
| 55 |
# yara-x runs IN-PROCESS, in the server's address space (the ScanPipeline |
| 56 |
# holds the rules at scanning/mod.rs:429 and pushes the layer at :827). |
| 57 |
# What does bound it is that scanning happens on a dedicated worker pool off |
| 58 |
# the request path, a panic in a CPU layer is caught and converted to a |
| 59 |
# fail-closed scan_panic verdict rather than unwinding the worker, and the |
| 60 |
# CPU layers carry a wall-clock deadline. Defense in depth, not a sandbox. |
| 61 |
"RUSTSEC-2026-0222", |
| 62 |
|
| 63 |
# RUSTSEC-2026-0269, "Filesystem sandbox escape when paths or symlinks |
| 64 |
# contain trailing slashes" (8.8 high, published 2026-08-20). Fixed in |
| 65 |
# 24.0.13+, 36.0.14+, 46.0.3+ and 47.0.4+, which skip the 43 line entirely. |
| 66 |
# The high severity is real for anyone running WASI. We do not. |
| 67 |
# |
| 68 |
# Not applicable, and for a stronger reason than 0222: the vulnerable code is |
| 69 |
# not compiled. The bug is in wasmtime's WASI filesystem implementation, and |
| 70 |
# the filesystem sandbox it escapes only exists when WASI is built. yara-x |
| 71 |
# takes wasmtime with `default-features = false` and exactly two features, |
| 72 |
# `cranelift` and `runtime`, embedding it as a bare JIT to execute compiled |
| 73 |
# YARA rule bytecode. Nothing enables WASI, and the crates that implement it |
| 74 |
# are absent from Cargo.lock entirely: |
| 75 |
# |
| 76 |
# wasmtime-wasi, wasi-common, cap-std, cap-primitives, |
| 77 |
# cap-fs-ext, system-interface -> none present |
| 78 |
# |
| 79 |
# THAT is the load-bearing claim: no WASI in the graph, so no filesystem |
| 80 |
# sandbox exists to escape. It is invalidated the moment any of those crates |
| 81 |
# appears in Cargo.lock, or yara-x enables a WASI feature, or we embed |
| 82 |
# wasmtime ourselves for anything. Re-argue it then rather than carrying it |
| 83 |
# forward. Guest wasm here is compiled YARA rules we produce from our own |
| 84 |
# rules directory, never attacker-supplied. |
| 85 |
"RUSTSEC-2026-0269", |
| 86 |
] |
| 87 |
|