CVE-2026-42009

What it actually does

CVE-2026-42009 is a remotely triggerable denial-of-service vulnerability in GnuTLS DTLS packet reordering logic. DTLS uses sequence numbers to order packets received over unreliable transports such as UDP. The vulnerable comparator does not correctly handle packets that carry duplicate sequence numbers, which can produce unstable ordering or undefined behavior. A remote, unauthenticated attacker can send crafted DTLS traffic to an affected service and cause the GnuTLS-consuming process to crash, hang, or otherwise become unavailable. The impact is availability only; the provided CVSS vector does not indicate confidentiality or integrity compromise.

Why it matters to the business

Services that rely on GnuTLS for DTLS can be disrupted remotely without authentication, potentially causing outages for VPNs, real-time communications, secure UDP-based services, embedded services, container workloads, or Linux-hosted applications using affected GnuTLS libraries. The CVSS score is high for availability impact, but current exploitation signals are limited: EPSS is low at 0.01335, flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. Organizations using Red Hat Enterprise Linux, OpenShift, Red Hat hardened images, or downstream images/packages that include vulnerable GnuTLS should still prioritize patching internet-exposed or business-critical DTLS services because exploitation requires only network reachability.

How an attack unfolds

An attacker first identifies a service that accepts DTLS traffic and is linked against a vulnerable GnuTLS version, commonly by scanning for UDP services that perform DTLS handshakes. The attacker then sends DTLS packets crafted to contain duplicate sequence numbers or packet sequences that exercise the flawed reordering comparator. Because the comparator does not provide stable handling for equal sequence numbers, the internal packet ordering operation may enter undefined or unstable behavior. Depending on how the affected application uses GnuTLS and how the runtime handles the resulting condition, the service may crash, consume excessive resources, stop processing traffic, or otherwise become unavailable. No authentication, user interaction, or prior compromise is required, and successful exploitation is expected to affect availability rather than permit code execution or data theft.

How to fix it

Upgrade GnuTLS and vendor packages to versions that include the fix as soon as they are available for the relevant distribution or product channel. Because no exact fixed versions were provided, use the official security advisories and package repositories for GnuTLS, Red Hat Enterprise Linux, Red Hat OpenShift Container Platform, Red Hat hardened images, and related EUS/ELS/SAP/IBM Z/Power variants. After updating shared libraries, restart all services and containers that link against GnuTLS; where practical, reboot hosts to ensure no vulnerable library remains mapped into long-running processes. Rebuild and redeploy container images that include the vulnerable package rather than only patching the host. If immediate patching is not possible, reduce exposure by disabling DTLS where it is not required, restricting UDP access to trusted sources, applying edge ACLs/firewall rules, enabling rate limits for DTLS/UDP traffic, and placing vulnerable services behind DDoS-aware filtering where feasible.

How to confirm the fix worked

Confirm exposure by inventorying systems and containers for installed GnuTLS packages and identifying applications that use libgnutls for DTLS. On Linux systems, check package versions with the platform package manager and compare them against the vendor advisory once fixed builds are published. Identify running processes linked to GnuTLS using tools such as ldd, pmap, lsof, or distribution-specific package ownership queries, then restart those services after patching. Validate network exposure by enumerating UDP listeners and confirming whether they support DTLS. Confirm remediation by verifying the patched package version, ensuring containers were rebuilt from updated base images, and confirming that no running process still has an old libgnutls library mapped. Where safe and authorized, use a DTLS test harness or vendor-provided regression test to verify that duplicate sequence-number packets no longer crash or destabilize the service.

Typical attack path

1. Scan for UDP services that appear to support DTLS or are known to use GnuTLS-backed DTLS.
2. Confirm that the target service responds to DTLS handshake traffic.
3. Send crafted DTLS datagrams containing duplicate sequence numbers or ordering patterns that trigger the vulnerable comparator path.
4. Repeat or sustain the crafted packet stream until the affected GnuTLS-consuming process crashes, hangs, or stops responding.
5. Optionally continue sending traffic to maintain denial of service until the service is patched, restarted with mitigations, or protected by filtering/rate limiting.

How to detect it

To determine whether exploitation was attempted or successful, review logs and telemetry from DTLS-enabled services, application supervisors, system logs, container orchestration events, and network devices. Look for bursts of UDP traffic to DTLS services, repeated DTLS handshake failures, malformed or duplicate sequence-number patterns if packet captures are available, and service instability such as crashes, watchdog restarts, segmentation faults, core dumps, or abrupt container restarts around the same time as suspicious UDP traffic. Useful sources include syslog/journald, application logs for services using GnuTLS, reverse proxy or gateway logs if they pass DTLS, firewall and flow logs, IDS/packet capture metadata, Kubernetes/OpenShift pod restart events, and kernel crash/core dump logs. There are no named threat actors or public exploit tooling provided, so detection should focus on behavior: high-rate or malformed DTLS traffic followed by availability failures in GnuTLS-linked processes.

• gnutls
• libgnutls
• DTLS
• duplicate sequence
• duplicate sequence number
• unexpected DTLS packet
• DTLS packet
• DTLS handshake failed
• Error in the pull function
• A TLS packet with unexpected length was received
• The TLS connection was non-properly terminated
• Segmentation fault
• segfault
• core dumped
• systemd-coredump
• Main process exited, code=dumped
• Main process exited, code=killed
• CrashLoopBackOff
• Back-off restarting failed container
• UDP

What your security team should do

• Prioritize patching internet-facing and business-critical DTLS services that use GnuTLS, especially UDP services exposed through Linux servers, OpenShift workloads, and container images.
• Track vendor advisories for GnuTLS and Red Hat product streams because exact fixed versions were not provided in the input; deploy fixed packages as soon as they are released for each supported channel.
• Inventory containers, base images, and hardened images for vulnerable GnuTLS packages and rebuild/redeploy affected workloads after updates are available.
• Apply temporary network controls for exposed DTLS services: restrict source IP ranges, rate-limit UDP traffic, and disable DTLS where it is not operationally required.
• Monitor for anomalous UDP/DTLS traffic, repeated handshake failures, duplicate-sequence test patterns, process crashes, and service restarts that may indicate attempted denial of service.
• Because the vulnerability is not currently listed in KEV, has no known ransomware association, and EPSS is low and flat, treat it as high-priority for exposed availability-critical services rather than an emergency across all assets.