7.5
Élevée
CVE-2026-56862 Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has…
Description
Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivation operations indefinitely.
Produits et versions touchés
| Produit | Versions touchées | Corrigé en |
|---|---|---|
| crypto/tls 1.27 | premières → < 1.27.0-rc.3 | 1.27.0-rc.3 |
| crypto/tls 1.26 | 1.26.0-0 → < 1.26.6 | 1.26.6 |
| crypto/tls 1.25 | premières → < 1.25.13 | 1.25.13 |
Références
- go.dev go.dev
- go.dev go.dev
- groups.google.com groups.google.com
- pkg.go.dev pkg.go.dev
Chronologie
- Publiée
- Dernière modification
Autres CVE de crypto/tls
Les 13 CVE de crypto/tls →
CVE-2026-97031
Multiple ECH outer extension references are not permitted under RFC 9849; previously, a client could send a well-crafted…
7.5
Élevée
CVE-2026-42505
Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of…
5.3
Moyenne
CVE-2026-32283
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection…
7.5
Élevée
CVE-2025-68121
During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between…
9.1
Critique