fix(security): drop the vulnerable lru via ratatui 0.30 and ewf 0.4.9 - #10
Merged
Conversation
RUSTSEC-2026-0002 — lru's `IterMut` violating Stacked Borrows, memory-corruption
category, patched in >= 0.16.3. This repo resolved lru 0.12.5 from two
independent requirers, both caret-trapped below the patch:
ratatui 0.29.0 requires lru ^0.12 -> ratatui 0.30 drops lru entirely
ewf 0.4.7 requires lru ^0.12 -> ewf 0.4.9 requires lru 0.18.1
Both are fixed by moving forward, not by ignoring: the lockfile now resolves a
single lru 0.18.2 and the vulnerable version is gone from the graph.
The ratatui half needed a manifest change because `^0.29` cannot reach 0.30. The
ewf half needed only `cargo update`, since the requirement here was already
"0.4"; it had simply never been refreshed past 0.4.7.
NOT fixed here, and stated rather than left to be discovered: `cargo deny check
advisories` is still red on RUSTSEC-2026-0222 (wasmtime). That failure is
pre-existing — it reproduces identically on unmodified main — and is unrelated
to this change. It also does NOT share issen's cause: there wasmtime arrives via
yara-x, whereas here the requirer is `wit-component 0.244.0` needing
wasmtime ^34.0.1, and 34.x is not one of the patched lines
(24.0.12+/36.0.13+/46.0.2+/47.0.3+). Reusing issen's exemption text would have
recorded a cause that is false for this repo, so that advisory is left for a
change that can investigate its own chain.
Verified: 104 test suites pass, fmt clean, `cargo vet --locked` succeeds with
zero self-certified audits, and the resolved lru is 0.18.2.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Corrects an earlier reading in this branch. The previous commit message said
blazehash's wasmtime came from `wit-component 0.244.0` and was therefore a
different cause from issen's. That was wrong. The wit-component dependency is
`kind = dev` — a dev-dependency of a dependency, which cargo never resolves into
this graph. `cargo tree -i wasmtime --target all --all-features` names the real
chain:
wasmtime 25.0.3 <- yara-x 0.9.0 <- blazehash
which is the same yara-x cause issen has, so issen's reasoning does apply here
and scoping it out was a mistake.
The advisory still cannot be fixed by upgrading, and the numbers differ enough
to be worth stating rather than copying:
resolved: wasmtime 25.0.3 <- yara-x 0.9.0 (issen: 26.0.1 <- 0.12.0)
patched: >=24.0.12,<25 | >=36.0.13,<37 | >=46.0.2,<47 | >=47.0.3
latest yara-x: 1.19.0, requires wasmtime ^43.0.2 — not a patched line
Sharing issen's wasmtime would not help either: 26.0.1 is outside every patched
range too, so unifying the two repos on one version yields two unpatched
resolutions rather than none.
Exposure is low and worth naming: CVSS AV:L/AC:H/PR:H/UI:R — local access, high
attack complexity, high privileges, user interaction. blazehash never executes
untrusted WASM; wasmtime is present only because yara-x compiles YARA rules to
WASM internally.
Verified by control rather than by reading the green: with the entry removed,
`cargo deny check advisories` exits non-zero; with it, the check passes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RUSTSEC-2026-0002 — lru's
IterMutviolating Stacked Borrows, memory-corruptioncategory, patched in >= 0.16.3. This repo resolved lru 0.12.5 from two
independent requirers, both caret-trapped below the patch:
Both are fixed by moving forward, not by ignoring: the lockfile now resolves a
single lru 0.18.2 and the vulnerable version is gone from the graph.
The ratatui half needed a manifest change because
^0.29cannot reach 0.30. Theewf half needed only
cargo update, since the requirement here was already"0.4"; it had simply never been refreshed past 0.4.7.
NOT fixed here, and stated rather than left to be discovered:
cargo deny check advisoriesis still red on RUSTSEC-2026-0222 (wasmtime). That failure ispre-existing — it reproduces identically on unmodified main — and is unrelated
to this change. It also does NOT share issen's cause: there wasmtime arrives via
yara-x, whereas here the requirer is
wit-component 0.244.0needingwasmtime ^34.0.1, and 34.x is not one of the patched lines
(24.0.12+/36.0.13+/46.0.2+/47.0.3+). Reusing issen's exemption text would have
recorded a cause that is false for this repo, so that advisory is left for a
change that can investigate its own chain.
Verified: 104 test suites pass, fmt clean,
cargo vet --lockedsucceeds withzero self-certified audits, and the resolved lru is 0.18.2.