CVE-2026-33846: vLLM DTLS fragment heap overflow, DoS

CISO Take

GnuTLS's DTLS handshake reassembly logic in merge_handshake_packet() matches fragments purely by handshake type and never validates that message_length stays consistent across all fragments of the same logical message, letting a remote, unauthenticated attacker allocate an undersized buffer and then overflow it with a later, larger fragment. There's no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei scanner template, so opportunistic mass exploitation isn't happening yet — but this sits in a library carrying 78 other CVEs, has 129 downstream dependents, and directly ships inside Red Hat's AI Inference Server images (rhaiis/model-opt-cuda-rhel9, rhaiis/vllm-rocm-rhel9) and Discovery server/UI components. The CVSS vector (7.5, A:H with C:N/I:N) scores this as availability-only, so the realistic near-term outcome is crash/restart loops on any AI inference endpoint that terminates DTLS — but the underlying bug is a heap out-of-bounds write, a primitive that has historically escalated beyond DoS once someone invests in heap grooming. Patch GnuTLS to the version fixed in the applicable Red Hat errata (RHSA-2026:13274, 20611-20613, 26319, 26409, 29197, 30004, 30849, 30850) on any host running rhaiis, Discovery, or RHUI5/RHCOS components, and if DTLS transport isn't required for your inference traffic, disable it at the listener to remove the exposure entirely while patching rolls out.

Sources: NVD CISA KEV ATLAS access.redhat.com

What is the risk?

Network-exploitable (AV:N), low complexity (AC:L), no privileges or user interaction required — the classic profile for wormable/scriptable exploitation once a working PoC surfaces. Currently mitigated by the absence of EPSS scoring, KEV status, public exploit code, or scanner coverage, which caps near-term real-world risk at 'patch on schedule' rather than 'patch now, actively under attack'. The confirmed impact per CVSS is availability-only (crash), but the root cause — an OOB heap write from mismatched fragment lengths — is a class of bug (CWE-130) that has produced RCE in other DTLS/TLS reassembly implementations, so the ceiling on impact is higher than the current score reflects if an attacker invests in heap-layout research. Exposure is elevated by GnuTLS's broad footprint (78 other CVEs, 129 dependents) and its presence in AI inference server container images that may expose DTLS-terminating listeners on internal or partner-facing networks.

How does the attack unfold?

Entry via exposed DTLS listener

Attacker reaches a DTLS-enabled network service on an AI inference or Discovery component without needing credentials.

AML.T0049

Fragment injection

Attacker sends crafted DTLS handshake fragments with conflicting message_length values so the reassembly buffer is allocated too small.

Heap overflow

merge_handshake_packet() writes a later, larger fragment beyond the undersized buffer, corrupting heap memory.

Impact: crash or corruption

The AI inference service crashes (denial of service) or, depending on heap layout, memory corruption opens the door to further exploitation.

AML.T0029

Entry via exposed DTLS listener

Attacker reaches a DTLS-enabled network service on an AI inference or Discovery component without needing credentials.

AML.T0049

Fragment injection

Attacker sends crafted DTLS handshake fragments with conflicting message_length values so the reassembly buffer is allocated too small.

Heap overflow

merge_handshake_packet() writes a later, larger fragment beyond the undersized buffer, corrupting heap memory.

Impact: crash or corruption

The AI inference service crashes (denial of service) or, depending on heap layout, memory corruption opens the door to further exploitation.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
89.7K 128 dependents Pushed 2d ago 24% patched ~52d to patch Full package profile →
discovery/discovery-server-rhel9	—	—	No patch
discovery/discovery-ui-rhel9	—	—	No patch
gnutls	—	—	No patch
gnutls-main	—	—	No patch
libtasn1	—	—	No patch
rhaiis/model-opt-cuda-rhel9	—	—	No patch
rhcos	—	—	No patch
rhui5/cds-rhel9	—	—	No patch
rhui5/haproxy-rhel9	—	—	No patch
rhui5/installer-rhel9	—	—	No patch
rhui5/rhua-rhel9	—	—	No patch

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

1.3%

chance of exploitation in 30 days

Higher than 67% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

1) Patch GnuTLS/libtasn1 to the version fixed in the referenced Red Hat errata (RHSA-2026:13274, 20611, 20612, 20613, 26319, 26409, 29197, 30004, 30849, 30850) across all affected products: gnutls, gnutls-main, rhaiis/model-opt-cuda-rhel9, rhaiis/vllm-rocm-rhel9, discovery-server/ui-rhel9, rhui5 (cds/haproxy/installer/rhua), and rhcos. 2) Inventory which AI inference/serving hosts actually terminate DTLS and, where DTLS isn't required, disable it at the listener as an interim compensating control. 3) Segment DTLS-terminating endpoints from untrusted networks until patched. 4) Detection: monitor for unexpected crashes/restarts of GnuTLS-linked inference or Discovery processes, and watch for anomalous DTLS handshake traffic with repeated fragments carrying conflicting message_length values (IDS/IPS signature candidate). 5) Track vendor advisories for a public PoC or KEV addition, which would materially raise urgency.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Code Execution Inference AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

Frequently Asked Questions

What is CVE-2026-33846?

GnuTLS's DTLS handshake reassembly logic in merge_handshake_packet() matches fragments purely by handshake type and never validates that message_length stays consistent across all fragments of the same logical message, letting a remote, unauthenticated attacker allocate an undersized buffer and then overflow it with a later, larger fragment. There's no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei scanner template, so opportunistic mass exploitation isn't happening yet — but this sits in a library carrying 78 other CVEs, has 129 downstream dependents, and directly ships inside Red Hat's AI Inference Server images (rhaiis/model-opt-cuda-rhel9, rhaiis/vllm-rocm-rhel9) and Discovery server/UI components. The CVSS vector (7.5, A:H with C:N/I:N) scores this as availability-only, so the realistic near-term outcome is crash/restart loops on any AI inference endpoint that terminates DTLS — but the underlying bug is a heap out-of-bounds write, a primitive that has historically escalated beyond DoS once someone invests in heap grooming. Patch GnuTLS to the version fixed in the applicable Red Hat errata (RHSA-2026:13274, 20611-20613, 26319, 26409, 29197, 30004, 30849, 30850) on any host running rhaiis, Discovery, or RHUI5/RHCOS components, and if DTLS transport isn't required for your inference traffic, disable it at the listener to remove the exposure entirely while patching rolls out.

Is CVE-2026-33846 actively exploited?

No confirmed active exploitation of CVE-2026-33846 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-33846?

1) Patch GnuTLS/libtasn1 to the version fixed in the referenced Red Hat errata (RHSA-2026:13274, 20611, 20612, 20613, 26319, 26409, 29197, 30004, 30849, 30850) across all affected products: gnutls, gnutls-main, rhaiis/model-opt-cuda-rhel9, rhaiis/vllm-rocm-rhel9, discovery-server/ui-rhel9, rhui5 (cds/haproxy/installer/rhua), and rhcos. 2) Inventory which AI inference/serving hosts actually terminate DTLS and, where DTLS isn't required, disable it at the listener as an interim compensating control. 3) Segment DTLS-terminating endpoints from untrusted networks until patched. 4) Detection: monitor for unexpected crashes/restarts of GnuTLS-linked inference or Discovery processes, and watch for anomalous DTLS handshake traffic with repeated fragments carrying conflicting message_length values (IDS/IPS signature candidate). 5) Track vendor advisories for a public PoC or KEV addition, which would materially raise urgency.

What systems are affected by CVE-2026-33846?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference infrastructure, container/orchestration security.

What is the CVSS score for CVE-2026-33846?

CVE-2026-33846 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 1.26%.

What is the AI security impact?

Affected AI Architectures

model servinginference infrastructurecontainer/orchestration security

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker with network reach to a DTLS-terminating endpoint on a Red Hat AI Inference Server deployment (or a Discovery server/UI instance) initiates a DTLS handshake and sends a first handshake fragment declaring a small message_length, causing GnuTLS to allocate a correspondingly small reassembly buffer. The attacker then sends subsequent fragments of the same handshake type but with a larger, inconsistent message_length; because merge_handshake_packet() merges fragments based on type alone without re-validating length consistency, the larger fragment is written past the end of the originally allocated buffer. This out-of-bounds heap write crashes the inference server process (denial of service) and, if repeated with different heap-grooming techniques, could be leveraged by a more sophisticated attacker to attempt memory corruption for further exploitation — all without any authentication or user interaction, directly against a production model-serving endpoint.

Weaknesses (CWE)

CWE-130 Improper Handling of Length Parameter Inconsistency

CWE-130 — Improper Handling of Length Parameter Inconsistency: The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.

[Implementation] When processing structured incoming data containing a size field followed by raw data, ensure that you identify and resolve any inconsistencies between the size field and the actual size of the data.
[Implementation] Do not let the user control the size of the buffer.

Source: MITRE CWE corpus.