CVE-2026-33845

What it actually does

The flaw is in GnuTLS DTLS handshake fragment parsing and reassembly. A remote unauthenticated peer can send a malformed DTLS handshake fragment with a zero-length fragment and a non-zero fragment offset, triggering an integer underflow during reassembly. The resulting out-of-bounds read can crash the process using GnuTLS and may expose adjacent memory contents depending on how the affected application handles the read and any resulting error paths. The most reliable impact is remote denial of service against DTLS-enabled services or clients using vulnerable GnuTLS libraries.

Why it matters to the business

Systems and products that rely on vulnerable GnuTLS versions for DTLS can be remotely disrupted without authentication, potentially affecting VPNs, real-time communications, telemetry, management interfaces, or other UDP-based secure services. The CVSS score indicates high availability impact, but current public exploit maturity is listed as none, EPSS is low and flat over 30 days, and the issue is not currently in CISA KEV, so remediation should be prioritized for internet-exposed or business-critical DTLS services rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first identifies a service or client path that uses GnuTLS for DTLS handshakes. They initiate or spoof a DTLS handshake and send a crafted handshake fragment where the fragment length is zero while the fragment offset is non-zero. During handshake reassembly, vulnerable GnuTLS logic performs arithmetic that underflows and can cause an out-of-bounds read. In practical attacks, this is most likely to terminate the affected process or force connection handling failures, creating denial of service. In less common cases, if memory contents are exposed through protocol responses, logs, crash reports, or application behavior, limited information disclosure may be possible.

How to fix it

Upgrade GnuTLS and vendor-packaged products to versions that contain the fix as soon as they are available from the relevant distribution or product vendor. Because no exact fixed versions were provided in the input, use the security advisories for GnuTLS, Red Hat Enterprise Linux, and Red Hat OpenShift Container Platform to identify the corrected package builds for each supported release stream. Prioritize updates on internet-facing DTLS services, systems processing untrusted UDP traffic, and container base images that include GnuTLS. If immediate patching is not possible, reduce exposure by disabling DTLS where it is not required, restricting UDP access to trusted sources, placing affected services behind filtering controls, rate-limiting unauthenticated DTLS handshakes, and ensuring supervised processes restart safely without creating a crash loop.

How to confirm the fix worked

Confirm exposure by inventorying systems and containers that include GnuTLS and determining whether any application uses DTLS, not only TLS over TCP. Validate remediation by checking installed GnuTLS package versions against vendor advisories for the applicable operating system or product release, then restart dependent services so patched libraries are loaded. For containers, rebuild images from patched base images and redeploy workloads. Network validation should confirm that DTLS services are either patched, disabled, or restricted. Where safe and authorized, use a non-destructive DTLS handshake test or vendor-provided regression test to verify that malformed zero-length/non-zero-offset fragments are rejected without crashing the service.

Typical attack path

1. Identify UDP services, applications, appliances, containers, or platforms using GnuTLS DTLS.
2. Confirm the target accepts DTLS handshakes from an unauthenticated network peer.
3. Send a malformed DTLS handshake fragment with fragment_length set to 0 and fragment_offset set to a non-zero value.
4. Trigger vulnerable reassembly logic and integer underflow in GnuTLS.
5. Cause an out-of-bounds read, leading to process crash, service instability, or possible memory disclosure depending on the consuming application.
6. Repeat malformed handshakes to sustain denial of service if the service automatically restarts.

How to detect it

Look for evidence of unusual DTLS handshake activity and correlated service instability. Relevant sources include application logs for services using GnuTLS, system journals, container logs, reverse proxy or gateway logs that record UDP/DTLS errors, endpoint crash reports, core dumps, kernel logs for segmentation faults, and network telemetry such as NetFlow, packet captures, IDS alerts, or firewall logs for UDP traffic to DTLS-enabled ports. Investigate bursts of DTLS handshake failures, repeated short UDP sessions from the same source, process crashes immediately following inbound UDP traffic, and messages from applications reporting GnuTLS handshake or record parsing errors. Packet-level detection should focus on DTLS handshake fragments where fragment_length is 0 and fragment_offset is greater than 0. If threat hunting historical data, correlate unexplained restarts of GnuTLS-linked processes with inbound UDP activity and check whether crash artifacts show faults in GnuTLS DTLS handshake reassembly code.

• DTLS Handshake fragment_length=0 fragment_offset>0
• gnutls_handshake() failed
• GnuTLS handshake failed
• DTLS handshake failed
• A TLS fatal alert has been received
• Error in the pull function
• The TLS connection was non-properly terminated
• The DTLS connection was non-properly terminated
• Segmentation fault.*libgnutls
• segfault.*libgnutls
• core dumped.*gnutls
• gnutls_dtls
• libgnutls.so

What your security team should do

• Inventory GnuTLS usage across servers, containers, appliances, and applications, with special attention to DTLS over UDP.
• Prioritize patching internet-facing or unauthenticated DTLS services before internal-only systems.
• Track GnuTLS, Red Hat Enterprise Linux, and Red Hat OpenShift advisories for exact fixed package versions and apply the appropriate updates.
• Rebuild and redeploy container images that inherit vulnerable GnuTLS packages from base images.
• Restrict or disable DTLS on services where it is unnecessary, especially on public interfaces.
• Add monitoring for repeated DTLS handshake failures, UDP scanning, and unexplained crashes of processes linked against GnuTLS.
• Review crash dumps and logs for signs of malformed DTLS handshakes before deleting forensic artifacts.
• Because EPSS is low and no KEV listing is present, use risk-based scheduling, but do not defer patching for exposed high-availability services.