ZDF
Sign inSign up

Vulnerabilities

Vulnerability · RUSTSEC-2026-0347

Buffered application data sent to outer server after ECH rejection

Published Oct 14, 2026 · catalog updated Oct 14, 2026 · RustSec Rust

Open the advisory

Exploitation likelihood is not on this record for RUSTSEC-2026-0347. A missing EPSS score is not a low risk. Compare RustSec Rust with the linked advisory before you change production.

Gaps on this record

  • No vendor fix or required action is stored. Compare the linked advisory before you change production.
  • EPSS is missing. A missing score is not a low risk.
Severity
Low2.3
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
Awaiting synchronization with FIRST
Remediation
Advisory link
Affected products
crates.io rustls

When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's . At the end of that handshake, rustls encrypted and queued any application data buffered via *before* queueing the alert. The application correctly receives , but the next call (needed to send the alert) also sends the buffered application data. Plaintext meant for the inner server therefore goes to the client-facing server named by . That server is authenticated, so this is not exploitable by an unauthenticated party, but it violates RFC 9849 section 6.1.6, which requires the client to abort with "before sending any application data to the server". This affects only clients that: - use (GREASE ECH is not affected), - write application data before the handshake completes, and - connect to a server that rejects their ECH config (for example, because it is stale). The underlying ordering bug is older, but before 0.23.44 the client checked the server certificate against the inner server name rather than , so certificate verification failed first and no data was sent.

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • crates.io rustls0.23.44 → 0.23.46

How to fix RUSTSEC-2026-0347

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

Exploitation likelihood is not on this record for RUSTSEC-2026-0347. A missing EPSS score is not a low risk. Compare RustSec Rust with the linked advisory before you change production.

Which versions are affected?

Compare what you have installed with 0.23.44 → 0.23.46. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

No weakness class is stored. EPSS is not on this record yet. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 14, 2026 · GitHub Advisory Database

    Detected

    When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's . At the end of that handshake, rustls encrypted and queued any application data buffered via *before* queueing the alert. The application correctly receives , but the next call (needed to send the alert) also sends the buffered ap

  2. Oct 14, 2026 · GitHub Advisory Database

    Fix available

    rustls fixed in 0.23.46

  3. Oct 14, 2026 · GitHub Advisory Database

    Fix available

    rustls fixed in 0.23.46

  4. Oct 14, 2026 · GitHub Advisory Database

    Updated

    When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's . At the end of that handshake, rustls encrypted and queued any application data buffered via *before* queueing the alert. The application correctly receives , but the next call (needed to send the alert) also sends the buffered ap

Sources

  • GitHub Advisory DatabasePackage advisoryGHSA-vp88-798v-h67f

    GitHub Advisory Database record mirrored by OSV.

    github.com
  • OpenSSF OSV / OSV ScannerPackage advisoryRUSTSEC-2026-0347

    Buffered application data sent to outer server after ECH rejection

    osv.dev
  • RustSec Advisory DBVendor advisoryRUSTSEC-2026-0347

    When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's . At the end of that handshake, rustls encrypted and queued any application data buffered via *before* queueing

    crates.io

References

Freshness

Last verified in this catalog Oct 14, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.