CVE-2026-56862High· 7.5▾ TwilightLimit handshake messages we are willing to accept post-handshake in crypto/tls
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Aug 14.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
0.2%
0.2% → 0.6%
7.5 → —
high → none
— → 7.5
none → high
7.5 → —
high → none
— → 7.5
none → high
7.5 → —
high → none
— → 7.5
none → high
Last analysed / modified upstream
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.
stdlib >= 1.27.0-0, < 1.27.0-rc.3Upgrade to a patched release:
stdlib 1.27.0-rc.3Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-56860High· 7.5Avoid quadratic complexity in resolvePath in net/url
CVE-2026-56858High· 8.1Fix Javascript regexp context tracking in html/template
CVE-2026-56853High· 7.5Apply ReadHeaderTimeout when doing unencrypted HTTP/2 check in net/http
CVE-2026-56859High· 7.5Add recursion depth guard during decode in encoding/xml
CVE-2026-32281Medium· 5.9Inefficient policy validation in crypto/x509
CVE-2026-97031High· 7.5Multiple ECH outer extension references are not permitted under RFC 9849; previously, a client could send a well-crafted packet that could trigger memory exhaustion in the server process by specifying multiple references