rustls 0.23.42 is affected by RUSTSEC-2026-0285 and the audit gate is red #1783

cargo audit and cargo deny both fail on any pull request that re-resolves the lockfile, with:

Crate:     rustls
Title:     TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
ID:        RUSTSEC-2026-0285
Solution:  Upgrade to >=0.23.45

I first saw it on #1781, which does not touch rustls at all. Cargo.lock carries rustls 0.23.42 on develop and on main, so v5.9.3 shipped with it. The scheduled audit on main last ran on 2026-09-14 and passed, because the advisory was published that same day and the database had not picked it up yet.

How much this matters here

The advisory (GHSA-2mjx-qc3c-rqvc, CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) says rustls accepted a TLS 1.3 handshake message sent at the wrong encryption level when it shared a record with a key-changing message. The handshake transcript is still authenticated, so a network attacker cannot alter or complete a handshake with it. In podup rustls is reached through ureq, client side only, by the self-updater talking to GitHub, and every downloaded asset is verified against the release signature afterwards. So the exposure is low, but the audit gate is red for every dependency pull request until the lockfile moves.

What I will do

cargo update -p rustls to 0.23.45 or newer, lockfile only, and check that the vendored Debian build still resolves offline.