chore(deps): bump ruint to 1.20.0 for RUSTSEC-2026-0220

[grumbach]

Linear issue

• https://linear.app/autonominetwork/issue/V2-851

Risk tier

• T0 — docs / tooling / CI / pure UX-output. Repo CI only.
• T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
• T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
• T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Proposed rather than asserted, because the boundary question is genuinely arguable here. Nothing in this change alters node behaviour, the wire protocol, stored formats, economics or the upgrade mechanism, which is what T1 asks. The counter-argument is that the bug being fixed is in arithmetic on the payment dependency path, so if the affected operations are reachable, the corrected behaviour is itself a behaviour change. I have not traced reachability. If a reviewer thinks that warrants T2, I have no objection.

Compatibility

• Wire: none.
• Storage: none.
• API: none. No manifest or source file is touched; this is the lockfile only.

Semver impact

• breaking
• feature
• fix

Test evidence

• cargo audit: no vulnerabilities. Before this change it reported one; after it, only the seven warnings already allowed on main.
• cargo build: clean.
• cargo test --lib: 768 passed, 0 failed.

Run on this branch, which is a single commit on top of main at c8f0ce1.

New dependency

None. This is a version bump of an existing transitive dependency, ruint 1.19.0 to 1.20.0. The removed lockfile entries are windows-* crates that 1.20.0 no longer pulls in.

ADR

n/a — Tier 1.

Mitigation / rollback

Revert the commit. It touches nothing but Cargo.lock, so there is no migration and no stored-data or wire implication either way.

---

What this is

cargo audit fails on RUSTSEC-2026-0220, "Uint shift operations: incorrect overflow flags and truncated shift amounts", against ruint 1.19.0. The advisory prescribes upgrading to 1.20.0, which is what this does.

ruint provides fixed-width unsigned integers with const-generic bit lengths — the crate behind types such as U256. Nothing in this repository depends on it directly. It arrives through the Ethereum stack, where 256-bit arithmetic underpins EVM word operations, RLP encoding and trie node maths:

ruint → nybbles → alloy-trie → alloy-genesis → … → alloy → evmlib → ant-node

Why it is worth more than a green check

Incorrect overflow flags mean a shift can report that it did not overflow when it did, and truncated shift amounts mean an operation can silently use the wrong one. Both produce wrong values rather than a crash, on a dependency path that carries payment arithmetic.

Stated honestly: which alloy code paths reach the affected operations has not been traced, so this is an upgrade on the advisory's say-so rather than on a demonstrated exploit. That seemed like the right way round for a one-line lockfile change.

Why this is its own PR

main pins the vulnerable version, so this reddens the Security Audit check on main and on every open PR the moment their CI re-runs. It is nobody's individual change to carry, and folding it into a feature branch would put an unrelated dependency change inside that branch's review. Landing it here fixes the check for everyone at once, and open branches pick it up on their next rebase.

[dirvine]

Approved on head f7d49527bcb3a29232b45bea7a4a2e4fc1e1a600.

Verified:

• lockfile-only ruint 1.19.0 → 1.20.0 update maps exactly to the patched version for RUSTSEC-2026-0220;
• the lockfile reproduces from main with cargo update -p ruint --precise 1.20.0;
• cargo audit: zero vulnerabilities (seven pre-existing allowed warnings);
• local cargo test --lib --locked --no-fail-fast: 768 passed, 0 failed;
• all three OS build jobs, unit-test steps, clippy, format, docs, audit, and policy checks pass;
• independent review panel found no material blockers.

The three OS e2e steps are still running, so merge should remain gated on their completion.