CVE-2026-33846

What it actually does

This vulnerability is a remotely reachable heap buffer overflow in GnuTLS DTLS handshake fragment reassembly. During DTLS handshakes, fragmented handshake messages are merged based on handshake type without consistently validating that all fragments agree on the logical message_length. A crafted sequence of fragments can cause GnuTLS to allocate a heap buffer sized for a smaller message and then copy later fragment data beyond that allocation. The most likely impact is a crash of the application using GnuTLS, resulting in denial of service; memory corruption may also be possible depending on allocator behavior, compiler hardening, and how the affected application is built.

Why it matters to the business

Any service that accepts DTLS traffic through GnuTLS could be remotely crashed without authentication, potentially disrupting VPNs, voice/video services, telemetry collectors, IoT gateways, or other UDP/TLS-based applications. The CVSS score indicates high availability impact, while the current EPSS is low and stable and the issue is not listed in CISA KEV or known ransomware campaigns, so prioritization should focus on internet-exposed or business-critical DTLS services first.

How an attack unfolds

An attacker identifies a service that uses GnuTLS for DTLS and can be reached over the network, typically over UDP. The attacker initiates a DTLS handshake and sends a crafted set of fragmented handshake messages where fragments that should belong to the same logical message carry inconsistent length metadata. Because the vulnerable reassembly logic matches fragments too broadly and does not enforce a consistent total message length, the first fragment can cause allocation of a buffer that is too small. Subsequent fragments are then merged into that buffer and can write past the end of the heap allocation. In practical exploitation, this can terminate the target process, restart the service, or repeatedly deny service. Reliable code execution is not established from the provided intelligence, but the primitive is memory corruption and should be treated seriously for exposed services.

How to fix it

Upgrade GnuTLS to a vendor-provided fixed release as soon as one is available for the affected distribution or product. No exact fixed versions were provided in the input, so use the operating system, appliance, container base image, or application vendor advisory as the source of truth. Rebuild or redeploy applications that statically link GnuTLS, and restart services that dynamically link it so the patched library is loaded. If immediate patching is not possible, disable DTLS where it is not required, restrict UDP access to trusted sources, place DTLS services behind rate-limiting or filtering controls, and monitor for repeated malformed handshake attempts or unexplained crashes. Prioritize remediation for internet-facing DTLS endpoints and services where availability is business-critical.

How to confirm the fix worked

Confirm exposure by inventorying systems and applications that use GnuTLS and accept DTLS traffic. Check installed package versions with the relevant package manager, inspect container images and appliance firmware, and identify applications that statically bundle libgnutls. After updating, verify that the runtime process is loading the patched library, not an older copy left on disk or inside an image. Validate that DTLS services remain functional after patching and that crafted or malformed fragmented handshakes are rejected without crashing in a controlled test environment. Review crash history before and after remediation to confirm that heap corruption, segmentation faults, or abnormal restarts associated with DTLS handshakes have stopped.

Typical attack path

1. Discover a UDP service that negotiates DTLS and is linked against a vulnerable GnuTLS version.
2. Initiate a DTLS handshake with the target service without needing credentials.
3. Send fragmented DTLS handshake messages with conflicting message_length values for fragments treated as the same logical handshake message.
4. Trigger vulnerable fragment reassembly so GnuTLS allocates an undersized heap buffer.
5. Cause an out-of-bounds heap write when later fragments are merged into the undersized buffer.
6. Crash or destabilize the application using GnuTLS, producing a remote denial-of-service condition.

How to detect it

To assess whether exploitation has already occurred, review logs and telemetry from services that accept DTLS traffic and use GnuTLS. Look for repeated failed DTLS handshakes, malformed or fragmented handshake messages, bursts of UDP traffic followed by process crashes, service restarts, segmentation faults, heap corruption errors, or watchdog restarts. Correlate network telemetry with host crash logs: suspicious activity is stronger when malformed DTLS handshakes from the same source IP precede a crash in an application linked to libgnutls. Packet captures may show DTLS handshake fragmentation with inconsistent handshake message lengths or protocol analyzer warnings about malformed DTLS records. On Linux and Unix-like systems, inspect syslog, journald, application logs, supervisor logs, coredump metadata, and kernel messages for crashes around the same time as inbound DTLS traffic. There are no named threat actors, KEV listing, ransomware association, or public exploit maturity in the provided data, so detection should focus on behavioral evidence rather than actor-specific infrastructure.

• merge_handshake_packet
• libgnutls
• gnutls_handshake
• DTLS handshake failed
• malformed DTLS
• fragmented DTLS handshake
• heap-buffer-overflow
• heap buffer overflow
• out-of-bounds write
• SIGSEGV
• segmentation fault
• core dumped
• double free or corruption
• malloc(): corrupted top size
• free(): invalid next size
• corrupted size vs. prev_size

What your security team should do

• Identify all externally reachable services that use DTLS and GnuTLS, including appliances, containers, embedded systems, and applications with bundled libraries.
• Patch or upgrade GnuTLS through vendor-supported packages, prioritizing internet-facing and high-availability services.
• Restart or redeploy affected services after patching to ensure the fixed library is actually in use.
• Apply temporary network controls for unpatched systems, including UDP allowlisting, rate limiting, and disabling DTLS where operationally feasible.
• Search historical logs, crash dumps, and network telemetry for signs of malformed DTLS handshakes followed by service crashes or restarts.
• Enable collection of core dumps or crash telemetry for exposed DTLS services until remediation is complete.
• Track vendor advisories for exact fixed versions because none were supplied in the input intelligence.
• Treat the issue as urgent for critical exposed DTLS services despite low current EPSS, because exploitation requires no authentication and can directly affect availability.