CVE-2026-33846: Gnutls: gnutls: denial of service via heap buffer overflow in dtls handshake fragment reassembly
A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.
Security readout for executives and security teams
Plain-English summary
This is a remotely reachable crash risk in GnuTLS when DTLS is used. A malformed handshake fragment sequence can corrupt heap memory during reassembly. The documented impact is loss of availability, with possible memory corruption, but the supplied sources do not show confirmed active exploitation.
Executive priority
Treat as high priority for externally exposed DTLS services because exploitation needs no authentication and can cause outages. Internal-only systems or hosts without DTLS exposure are lower urgency but should still be patched through normal security maintenance.
Technical view
The flaw is in merge_handshake_packet() DTLS handshake fragment reassembly. Fragments are merged by handshake type without enforcing consistent message_length across the logical message, allowing allocation from a smaller fragment followed by an out-of-bounds heap write from larger inconsistent fragments.
Likely exposure
Exposure is most likely on affected Red Hat Enterprise Linux systems running services that use GnuTLS for DTLS handshakes. Installed vulnerable packages alone may not mean reachable exposure unless a DTLS-using application is listening.
Exploitation context
The source bundle describes remote, unauthenticated exploitation through the DTLS handshake path. KEV is false, and no supplied source confirms exploitation in the wild. The practical documented outcome is denial of service; memory corruption is possible but not further characterized.
Researcher notes
Focus validation on DTLS reachability and package provenance. The bundle names CWE-130, CVSS 7.5, and Red Hat affected streams across RHEL 7 ELS, 8 variants, 9 variants, and 10 variants. Do not infer TLS-over-TCP impact from this evidence alone.
Mitigation direction
Apply the relevant Red Hat security advisory updates for affected RHEL streams.
Prioritize internet-facing or partner-facing DTLS services using GnuTLS.
Restart or redeploy services after package updates are applied.
Limit network access to DTLS endpoints where business requirements allow.
Track Red Hat guidance for fixed package versions and product-specific handling.
Validation and detection
Inventory RHEL hosts with affected gnutls or listed libtasn1 package versions.
Map which applications on those hosts accept DTLS traffic.
Check whether exposed DTLS services link against GnuTLS.
Confirm applicable RHSA updates are installed on affected systems.
Review logs for unexplained crashes in DTLS-enabled services.
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-130: 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.
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program 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.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-130 · source CWE mapping
Improper Handling of Length Parameter Inconsistency
Improper Handling of Length Parameter Inconsistency represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.