h2 0.4.15 has RUSTSEC-2026-0258 and lru 0.18.1 has RUSTSEC-2026-0253 in the 1.31.0 bridge Cargo.lock

[ZacharyHampton]

Summary

The published temporalio 1.31.0 wheels ship temporalio/bridge/Cargo.lock with two crates that have open RustSec advisories:

Crate	In the wheel	Patched in	Advisory
h2	0.4.15	0.4.16	RUSTSEC-2026-0258 / GHSA-q83h-524g-xf6h — h2 queued empty DATA frames without limit; unbounded memory or a length-overflow panic if streams are not drained
lru	0.18.1	0.18.2	RUSTSEC-2026-0253

Both are low severity. Neither looks reachable the way a Temporal client uses the bridge — h2 is used as an HTTP/2 client to the Temporal service, not as a server accepting arbitrary peers — so this is a lockfile-hygiene report, not an exploit report.

Why it needs a release rather than a downstream pin

The bridge is a pre-compiled Rust component inside the wheel, so a downstream project cannot patch its Cargo.lock from its own dependency manifest. Any container scanner that reads vendored Cargo.lock files (AWS Inspector, Trivy, Grype) reports both against every image that installs temporalio, and the only resolutions available downstream are a scanner suppression or a fork.

Reproduction

pip download temporalio==1.31.0 --no-deps
unzip -p temporalio-1.31.0-*.whl temporalio/bridge/Cargo.lock | grep -A1 -E '^name = "(h2|lru)"$'

Ask

Bump h2 to >= 0.4.16 and lru to >= 0.18.2 in the bridge lockfile and cut a release. Same shape as #1615 (quinn-proto) and #1485 (rustls-webpki).