Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

RUSTSEC-2026-0347: Buffered application data sent to outer server after ECH rejection

Closed
  • Is something wrong?
#582 0 comments 0 reactions 0 assignees View on GitHub

A pull request for this has already been merged.

  • #586 by @SergioGasquez — merged

Assessment

Difficulty
2/5
Estimated time
Under an hour
Newbie friendliness
15/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
security

Research direction

This is a security advisory about the rustls dependency, not a change to espup's own code. The payload names the affected version (0.23.45) and the patched version (>=0.23.46) but no espup file. Check where rustls is pinned in the project's Cargo manifest and lockfile. Pull request #586 is already open against this issue, so review or test that change rather than starting a new one. Done when the resolved rustls is at least 0.23.46 and the build and tests pass.

Written by the indexing model from the issue text.

Description

Buffered application data sent to outer server after ECH rejection

Details
Package rustls
Version 0.23.45
URL https://github.com/rustls/rustls/pull/3300
Date 2026-10-14
Patched versions >=0.23.46
Unaffected versions <0.23.44

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 public_name. At the end of that handshake, rustls encrypted and
queued any application data buffered via ClientConnection::writer() before
queueing the ech_required alert.

The application correctly receives
Error::PeerIncompatible(ServerRejectedEncryptedClientHello), but the next
write_tls() 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 public_name.

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 ech_required "before sending any application data to the server".

This affects only clients that:

  • use EchMode::Enable (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 public_name,
so certificate verification failed first and no data was sent.

See advisory page for additional details.

Dominant language
Rust
Stars
461
Forks
37
Avg merge
1d 8h
Merged PRs (30d)
6

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from esp-rs/espup

All issues in esp-rs/espup

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.