CVE-2026-32283: Unauthenticated TLS 1.3 KeyUpdate record can cause persistent connection retention and DoS in crypto/tls
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.
Security readout for executives and security teams
Plain-English summary
A flaw in Go's built-in TLS library lets a remote party stall a secure connection by sending multiple key-update messages inside a single TLS 1.3 record. The connection deadlocks and holds resources, and attackers can repeat this to exhaust server capacity. No login is required, so any Go-based service that terminates TLS 1.3 is potentially reachable from the internet.
Executive priority
Prioritize this quarter for any internet-facing Go-based service. Impact is availability only — no data disclosure — but a single unauthenticated attacker can degrade or take offline customer-facing endpoints. Coordinate patching with platform and container teams alongside Red Hat errata cycles.
Technical view
crypto/tls mishandles post-handshake KeyUpdate messages when several are packed into one TLS 1.3 record, causing a deadlock (CWE-667) and uncontrolled resource consumption (CWE-764). CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H) reflects an unauthenticated network denial of service. Impact is limited to TLS 1.3 servers or clients built on affected Go standard-library versions; the Go advisory tracks it as GO-2026-4870 with a fix landing before 1.26.0.
Likely exposure
Broad. Any internet-facing service written in Go that terminates TLS 1.3 — API gateways, ingress controllers, proxies, Kubernetes components, and custom microservices — could be reachable. Red Hat has issued multiple RHSA advisories, indicating downstream exposure across container platforms and OpenShift builds.
Exploitation context
No public exploitation, KEV listing, or in-the-wild reports are cited in the bundle. The trigger requires only crafted TLS 1.3 records without authentication, so weaponization for availability attacks is plausible once details spread. Treat as a resource-exhaustion primitive, not a data-exposure issue.
Researcher notes
Root cause is deadlock handling of stacked post-handshake KeyUpdate messages in one record (CWE-667 + CWE-764). Only TLS 1.3 code paths are affected; TLS 1.2 servers are out of scope. Track the upstream fix at go.dev/cl/763767 and issue 78334, and cross-reference the Go announce thread for version bounds. Confirm downstream rebuilds because static linking of crypto/tls means every Go binary needs its own toolchain upgrade.
Mitigation direction
Upgrade Go toolchain and rebuild affected binaries to a version at or above the fixed release noted in GO-2026-4870.
Apply Red Hat RHSA errata (e.g., RHSA-2026:24762, 24761, 27076) to affected OpenShift and RHEL packages.
Inventory internal and vendor Go binaries terminating TLS 1.3 and prioritize internet-facing services first.
Front vulnerable services with a non-Go TLS terminator or WAF that can rate-limit and drop abusive TLS records.
Track vendor advisories for embedded Go runtimes (Kubernetes, Istio, Prometheus, HashiCorp tools) and patch as released.
Validation and detection
Run `go version` on build artifacts and compare against the fixed Go release listed in GO-2026-4870.
Use govulncheck against source and binaries to flag GO-2026-4870 occurrences.
Query SBOM or container image inventory for Go stdlib versions below 1.26.0 in TLS-terminating components.
Confirm Red Hat errata coverage in patch management reports for affected RHSA IDs.
Monitor TLS termination services for unusual connection retention, half-open sockets, or memory growth after patch rollout.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.