| 26 |
26 |
|
"RUSTSEC-2025-0134", # rustls-pemfile (unmaintained), via AWS SDK TLS
|
| 27 |
27 |
|
"RUSTSEC-2026-0173", # proc-macro-error2 (unmaintained), via a macro dep
|
| 28 |
28 |
|
|
| 29 |
|
- |
# wasmtime 43.0.2, "Stores can mix up type indices between engines"
|
| 30 |
|
- |
# (3.8 low, published 2026-07-31), reached only through yara-x 1.19.0, which
|
| 31 |
|
- |
# is the current release and pins the 43 line. The fixed ranges are 24.0.12+,
|
| 32 |
|
- |
# 36.0.13+, 46.0.2+ and 47.0.3+ — they skip 43 entirely, so there is no
|
| 33 |
|
- |
# version reachable by bumping anything we control. Waiting on yara-x.
|
|
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.
|
| 34 |
44 |
|
#
|
| 35 |
45 |
|
# Not applicable as we run it. The precondition is a store crossing between
|
| 36 |
|
- |
# two wasmtime Engines, and production builds exactly one: scanning/mod.rs:499
|
|
46 |
+ |
# two wasmtime Engines, and production builds exactly one: scanning/mod.rs:505
|
| 37 |
47 |
|
# calls yara::compile_rules_from_dir once while constructing the ScanEngine,
|
| 38 |
|
- |
# and every other yara_x::Compiler::new() in the tree is under #[cfg(test)].
|
| 39 |
|
- |
# One engine for the process lifetime means two engines never exist to
|
| 40 |
|
- |
# confuse. THAT is the load-bearing claim here — if a second compile ever
|
| 41 |
|
- |
# lands in a production path, this ignore stops being justified and has to be
|
| 42 |
|
- |
# re-argued (see the note in scanning/yara.rs).
|
|
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).
|
| 43 |
53 |
|
#
|
| 44 |
54 |
|
# Worth being precise about the blast radius rather than calling it isolated:
|
| 45 |
|
- |
# yara-x runs IN-PROCESS, in the server's address space (scanning/mod.rs:192).
|
|
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).
|
| 46 |
57 |
|
# What does bound it is that scanning happens on a dedicated worker pool off
|
| 47 |
58 |
|
# the request path, a panic in a CPU layer is caught and converted to a
|
| 48 |
59 |
|
# fail-closed scan_panic verdict rather than unwinding the worker, and the
|
| 49 |
60 |
|
# CPU layers carry a wall-clock deadline. Defense in depth, not a sandbox.
|
| 50 |
|
- |
#
|
| 51 |
|
- |
# Monitoring: cargo-deny reports an unreachable ignore as
|
| 52 |
|
- |
# `advisory-not-detected`, so this entry announces its own obsolescence once
|
| 53 |
|
- |
# yara-x moves to a fixed wasmtime. Prune it then.
|
| 54 |
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",
|
| 55 |
86 |
|
]
|