Repository navigation
Track RUSTSEC-2026-0258 (h2 0.3 via libsql remote) and its temporary audit exception #349
Description
The nightly cargo audit reports RUSTSEC-2026-0258 in h2 0.3.27. Nothing upstream fixes it yet, so I'm tracking it here alongside a temporary audit exception.
Where it comes from
libsql 0.9.30'sremotefeature (Hrana over HTTP) depends onhyper 0.14withhttp2enabled, which pulls inh2 0.3.x.- Our own
hyper 0.14dependency doesn't enable http2, so libsql'sremotefeature is the only reason h2 0.3 is in the tree. The h2 0.4 copy that comes through hyper 1, reqwest and axum isn't affected. - We can't drop
remote, because it's the remote database path insrc/db.rs.
Why the risk is negligible for us
- The advisory is a low-severity way to crash or exhaust memory by flooding an h2 connection with empty DATA frames.
- We only use h2 as a client, and only toward the database server the operator configured.
src/remote_https.rsoffers onlyhttp/1.1during the TLS handshake, and a test covers that. libsql never forces HTTP/2, so the h2 code is built but never runs. We also confirmed that our hosted database endpoint works fully over HTTP/1.1.
Upstream status
libsql 0.10.0(2026-10-13) still useshyper ^0.14.- The hyper 1 migration is in feat: Upgrade to Hyper 1.0, Tonic 0.12, and hyper-rustls 0.27 tursodatabase/libsql#2224, which is open and unmerged. Related: hyper-rustls 0.25 pin transitively forces rustls-webpki 0.102.x, which has unpatchable advisories (incl. one high) tursodatabase/libsql#2266.
Plan
- Add a narrow audit ignore for
RUSTSEC-2026-0258only, with a written reason, plus an expiry date check inscripts/ci-preflight.sh(about 90 days out) so it can't be forgotten. - Keep the HTTP/1.1-only connector test, since it's what makes the exception safe.
- When libsql ships a release whose remote path uses hyper 1 / h2 0.4, bump libsql, remove the ignore and close this issue.
- If the exception expires with no upstream movement, scope replacing the remote client (Hrana over hyper 1 or reqwest, keeping libsql core for local) as a separate backlog item.
The rustls advisories (RUSTSEC-2026-0346 to 0349) are fixed by a separate lockfile bump, not here.
Activity
jatmn commentedon Oct 17, 2026
Backlog note: options for replacing the libsql remote client. These are deferred for now; the audit exception stays in place.
libsql://URLs with a token. The open questions: it's young (0.1.x), it targets Turso's new engine so it hasn't been proven against our hosted libSQL database, and it may not cover everything we use (transactions, batches, retry handling).I'll revisit this if libsql moves to hyper 1 or turso_serverless matures, whichever comes first.
jatmn commentedon Oct 17, 2026
Addendum from the public bunny.net docs (checked 2026-10-17):
POST /v2/pipeline, and that API is marked beta (SQL API).libsqlcrate withBuilder::new_remote(Rust page).tursosync protocol.turso_serverlesshasn't been verified against Bunny.This makes the in-house
/v2/pipelineclient the most likely replacement, if we ever need one. It's essentially what Bunny's own TypeScript client does. The trade-offs are that we'd have to handle value encoding ourselves (integers as strings, blobs as base64), and we'd use batch/sequence requests instead of interactive transactions.fix(ci): bump rustls to 0.23.46 and expire the h2 audit exception (#350)
jatmn commentedon Oct 28, 2026
Work guideline
This is a watch item only, with no code work until upstream ships a fix. The only allowed change is a dependency bump that removes h2 0.3, along with removing the audit exception. That should be a small PR with no refactoring.