RUSTSEC-2026-0347: Buffered application data sent to outer server after ECH rejection
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 2/5
- Tempo estimado
- 1-3 horas
- Facilidade para iniciantes
- 55/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- rust
- Domínio
- networking, security
Direção de pesquisa
The fix is a dependency bump: the rustls version in Cargo.toml and Cargo.lock must resolve to 0.23.46 or later. Start with the rustls entries in Cargo.toml and Cargo.lock, then run cargo update -p rustls and cargo test. Done when the lockfile pins a patched rustls and the build and tests pass. Check the advisory page for any API changes that affect ECH handling in this crate.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Rust
- Estrelas
- 2
- Forks
- 0
- Merge médio
- 1d 5h
- PRs com merge (30d)
- 4
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de stackabletech/stackable-odbc-trino
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 15/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
Todas as issues de stackabletech/stackable-odbc-trino
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
higress-group/HiRoute#405 ·
Mantenedores costumam responder em até 1 dia
-
rust_analyzer flycheck: no CLI way to enable clippy from `check.overrideCommand`Talvez já em andamento @TrapsterDK assumiu hoje. Abertaneeds-triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 77/100
bazelbuild/rules_rust#4392 ·
Mantenedores costumam responder em até 2 dias
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 73/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
Mantenedores costumam responder em até 1 dia
-
🐞 bug 🧩 bevy_gantz_egui
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
nannou-org/gantz#500 ·
Mantenedores costumam responder em até 1 dia