Update TLS stack (tokio-rustls/rustls): bundled rustls-webpki 0.101.7 flagged by RUSTSEC-2026-0098/0099/0104

Rocket Version

0.5.1

Operating System

All (dependency-level issue; reproduced on Linux)

Rust Toolchain Version

rustc 1.96.0 (ac68faa20 2026-05-25)

What happened?

Enabling Rocket's tls feature pulls in rustls-webpki 0.101.7 through the TLS stack:

rustls-webpki 0.101.7
└── rustls 0.21.12
    └── tokio-rustls 0.24.1
        └── rocket_http 0.5.1
            └── rocket 0.5.1

Security scanners (cargo audit, GitLab/GitHub dependency scanning) flag this version for three open RustSec advisories:

• RUSTSEC-2026-0098 : name constraints for URI names incorrectly accepted (patched in 0.103.12)
• RUSTSEC-2026-0099 : name constraints accepted for a certificate asserting a wildcard name (patched in 0.103.12)
• RUSTSEC-2026-0104 : reachable panic in CRL parsing (patched in 0.103.13)

None of these advisories list a patched release in the 0.101.x or 0.102.x lines, only 0.103.12+ (and the 0.104.0-alpha series). So there is no in-line fix for the 0.101.7 that Rocket currently bundles; clearing them requires moving to rustls-webpki 0.103.x, which in turn requires updating Rocket's TLS stack bumping tokio-rustls to 0.26.x / rustls to 0.23.x.

These advisories concern peer-certificate validation (name constraints) and CRL parsing. For typical server-side TLS where Rocket presents its own certificate (no mutual TLS / client-certificate auth), these paths appear not to be reached, so this is unlikely to be a critical exploit for most Rocket apps. However, the dependency keeps tripping security scanners and cannot be silenced at the version level without a Rocket release that updates the TLS stack.

Test Case

This is a dependency-level finding (`cargo audit` reads `Cargo.lock`; the app is
not run). The trigger is simply enabling the `tls` feature, the application code
is irrelevant. Minimal reproduction:


# Cargo.toml
[dependencies]
rocket = { version = "0.5.1", features = ["tls"] }



// src/main.rs
#[macro_use] extern crate rocket;

#[get("/hello/<name>/<age>")]
fn hello(name: &str, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![hello])
}


Then run `cargo audit`.

Log Output

$ cargo audit
Crate:     rustls-webpki
Version:   0.101.7
Title:     Name constraints for URI names were incorrectly accepted
ID:        RUSTSEC-2026-0098
URL:       https://rustsec.org/advisories/RUSTSEC-2026-0098
Solution:  Upgrade to >=0.103.12

Crate:     rustls-webpki
Version:   0.101.7
Title:     Name constraints were accepted for certificates asserting a wildcard name
ID:        RUSTSEC-2026-0099
URL:       https://rustsec.org/advisories/RUSTSEC-2026-0099
Solution:  Upgrade to >=0.103.12

Crate:     rustls-webpki
Version:   0.101.7
Title:     Reachable panic in certificate revocation list parsing
ID:        RUSTSEC-2026-0104
URL:       https://rustsec.org/advisories/RUSTSEC-2026-0104
Solution:  Upgrade to >=0.103.13

Dependency tree (identical for all three):
rustls-webpki 0.101.7
└── rustls 0.21.12
    └── tokio-rustls 0.24.1
        └── rocket_http 0.5.1
            └── rocket 0.5.1

error: 3 vulnerabilities found!

Additional Context

The request is simply to bump Rocket's TLS dependencies (tokio-rustls / rustls) to a maintained line, so transitive rustls-webpki advisories can be resolved going forward rather than re-appearing with each new finding.

Related: #2992 (closed, it covered RUSTSEC-2026-0049, whose affected range was later re-scoped to exclude < 0.102.0, so Rocket's 0.101.7 fell out of scope there. The three advisories above are different and still list 0.101.7 as affected.)

System Checks

• My bug report relates to functionality.
• I have tested against the latest Rocket release or a recent git commit.
• I have tested against the latest stable rustc toolchain.
• I was unable to find this issue previously reported.