RUSTSEC-2026-0349: Unauthenticated ServerHello can downgrade later connections to classical key exchange
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 55/100
Research direction
The vulnerable dependency is rustls at 0.23.40, so start with Cargo.toml and Cargo.lock to find where it is pinned. Raise it to at least 0.23.46 with cargo update -p rustls, then run cargo build and cargo test to confirm nothing breaks. Done when the lockfile resolves rustls to 0.23.46 or later and the build and tests pass.
Written by the indexing model from the issue text.
Description
Unauthenticated ServerHello can downgrade later connections to classical key exchange
| Details | |
|---|---|
| Package | rustls |
| Version | 0.23.40 |
| URL | https://github.com/rustls/rustls/pull/3355 |
| Date | 2026-10-14 |
| Patched versions | >=0.23.46 |
The client recorded the server-selected key exchange group for each server
name when processing the ServerHello, before the server was authenticated.
This record is used to predict which key share to send in future ClientHellos
to that server name.
A network attacker can answer one connection attempt with a ServerHello
selecting X25519, and then close the connection. Later ClientHellos for that
name carry only an X25519 key share, while supported_groups still lists
X25519MLKEM768 first. If the genuine server accepts that share rather than
sending a HelloRetryRequest for its preferred hybrid group, the handshake
completes with classical-only key exchange and no error. This persists for as
long as the entry stays in the client's session store.
The impact is loss of post-quantum confidentiality for affected connections
("harvest now, decrypt later"). There is no key compromise and no
authentication bypass.
The following are not affected:
- connections to servers which send a HelloRetryRequest for their preferred group,
- clients with resumption disabled (as nothing is stored), and
- other server names.
This behaviour is discussed in
draft-ietf-tls-key-share-prediction,
so the practical impact depends largely on server policy.
See advisory page for additional details.
- Dominant language
- Rust
- Stars
- 0
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stackabletech/postgresql-trino-gateway
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authenticationOpen
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
All issues in stackabletech/postgresql-trino-gateway
Similar issues
-
agent:triaged bug bughunt pm:pipenv priority:p1
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
SocketDev/socket-patch#1608 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
adorsys/status-list-server#698 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
nannou-org/egui_graph#92 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 Half a day Newbie friendliness 72/100
sujithputta02/Esapay#13 ·
-
Deduplicate normalized_f64_bits (hash_table.rs and bloom_filter.rs)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
tursodatabase/turso#10002 ·
Maintainers usually reply within 1 day