CVE-2025-14831: GnuTLS: TLS cert parsing DoS hits vllm inference

MEDIUM
Published February 9, 2026
CISO Take

GnuTLS contains a denial-of-service flaw (CWE-407) in its certificate parsing logic that allows any unauthenticated remote attacker to exhaust CPU and memory by presenting a specially crafted TLS certificate loaded with excessive name constraints and Subject Alternative Names. The direct inclusion of Red Hat AI Infrastructure Suite vllm images (CUDA, ROCm, Spyre variants) in the affected packages means GPU-accelerated LLM inference endpoints are in scope — a crash here silences your entire model serving layer with a single malformed handshake. While no public exploit exists and the CVE is absent from CISA KEV, the zero-privilege, zero-interaction network attack vector (AV:N/AC:L/PR:N/UI:N) makes opportunistic probing trivial. Organizations running vllm on RHEL 9 container images should apply the available Red Hat advisories (starting RHSA-2026:3477) immediately and place a TLS-terminating proxy in front of inference endpoints as an interim control.

Sources: NVD ATLAS vendor advisory: access.redhat.com

What is the risk?

Medium severity by CVSS (5.3), but contextually elevated for AI inference teams. The zero-complexity, unauthenticated network vector means any internet-reachable vllm endpoint is a single malformed TLS connection away from a service outage. No active exploitation evidence (no KEV, no EPSS data, no public PoC), but the attack requires no AI/ML knowledge — any developer comfortable with OpenSSL tooling could craft the certificate. The 53 prior CVEs in GnuTLS and 130 downstream dependents suggest systemic exposure beyond vllm alone. Risk is moderate in isolation but high for teams with no TLS offloading in front of inference infrastructure.

How does the attack unfold?

Target Discovery
Adversary scans for vllm inference endpoints or GnuTLS-backed AI API gateways exposed over TLS on the target network or internet.
AML.T0006
Malicious Certificate Crafting
Adversary generates a syntactically valid X.509 certificate with hundreds of name constraint extensions and thousands of SANs using standard OpenSSL tooling to maximize algorithmic complexity.
TLS Handshake Exploitation
Adversary initiates a TLS connection to the vllm endpoint and presents the malicious certificate, triggering an unbounded constraint-checking loop in GnuTLS that pegs CPU and exhausts memory.
AML.T0049
Inference Service Disruption
The vllm inference process becomes unresponsive or is OOM-killed, denying all model serving requests and taking the AI service offline for the duration of the attack.
AML.T0029

What systems are affected?

Package Ecosystem Vulnerable Range Patched
vLLM pip No patch
82.1K 130 dependents Pushed 5d ago 42% patched ~32d to patch Full package profile →
vLLM pip No patch
82.1K 130 dependents Pushed 5d ago 42% patched ~32d to patch Full package profile →
vLLM pip No patch
82.1K 130 dependents Pushed 5d ago 42% patched ~32d to patch Full package profile →
discovery/discovery-server-rhel9 No patch
discovery/discovery-ui-rhel9 No patch
gnutls No patch
gnutls-main No patch
insights-proxy/insights-proxy-container-rhel9 No patch
rhaiis/model-opt-cuda-rhel9 No patch
rhceph/rhceph-8-rhel9 No patch
rhcos No patch
rhpam-7/rhpam-businesscentral-monitoring-rhel8 No patch
rhpam-7/rhpam-businesscentral-rhel8 No patch
rhpam-7/rhpam-controller-rhel8 No patch
rhpam-7/rhpam-dashbuilder-rhel8 No patch
rhpam-7/rhpam-kieserver-rhel8 No patch
rhpam-7/rhpam-process-migration-rhel8 No patch
rhpam-7/rhpam-smartrouter-rhel8 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
5.3 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C None
I None
A Low

What should I do?

6 steps
  1. Apply Red Hat advisories RHSA-2026:3477, RHSA-2026:13812, RHSA-2026:16008/16009/16174, and RHSA-2026:4188/4655/4943/5585 as relevant to your RHEL version.

  2. Rebuild and redeploy all affected rhaiis container images after patching the base GnuTLS package.

  3. Place a TLS-terminating reverse proxy (Nginx, HAProxy, or Envoy) in front of vllm serving endpoints so GnuTLS never processes client-presented certificates directly.

  4. Apply TLS handshake rate limiting at the network perimeter (e.g., 10 new TLS sessions/sec per source IP) to blunt flood-based exploitation.

  5. Monitor inference nodes for anomalous CPU spikes correlated with TLS negotiation phases as a detection indicator.

  6. If immediate patching is not possible, restrict vllm TLS endpoints to known client IP ranges via firewall rules.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
8.4 - AI system operation
NIST AI RMF
MANAGE 2.2 - Resilience and availability of AI systems
OWASP LLM Top 10
LLM04 - Model Denial of Service

Frequently Asked Questions

What is CVE-2025-14831?

GnuTLS contains a denial-of-service flaw (CWE-407) in its certificate parsing logic that allows any unauthenticated remote attacker to exhaust CPU and memory by presenting a specially crafted TLS certificate loaded with excessive name constraints and Subject Alternative Names. The direct inclusion of Red Hat AI Infrastructure Suite vllm images (CUDA, ROCm, Spyre variants) in the affected packages means GPU-accelerated LLM inference endpoints are in scope — a crash here silences your entire model serving layer with a single malformed handshake. While no public exploit exists and the CVE is absent from CISA KEV, the zero-privilege, zero-interaction network attack vector (AV:N/AC:L/PR:N/UI:N) makes opportunistic probing trivial. Organizations running vllm on RHEL 9 container images should apply the available Red Hat advisories (starting RHSA-2026:3477) immediately and place a TLS-terminating proxy in front of inference endpoints as an interim control.

Is CVE-2025-14831 actively exploited?

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

How to fix CVE-2025-14831?

1. Apply Red Hat advisories RHSA-2026:3477, RHSA-2026:13812, RHSA-2026:16008/16009/16174, and RHSA-2026:4188/4655/4943/5585 as relevant to your RHEL version. 2. Rebuild and redeploy all affected rhaiis container images after patching the base GnuTLS package. 3. Place a TLS-terminating reverse proxy (Nginx, HAProxy, or Envoy) in front of vllm serving endpoints so GnuTLS never processes client-presented certificates directly. 4. Apply TLS handshake rate limiting at the network perimeter (e.g., 10 new TLS sessions/sec per source IP) to blunt flood-based exploitation. 5. Monitor inference nodes for anomalous CPU spikes correlated with TLS negotiation phases as a detection indicator. 6. If immediate patching is not possible, restrict vllm TLS endpoints to known client IP ranges via firewall rules.

What systems are affected by CVE-2025-14831?

This vulnerability affects the following AI/ML architecture patterns: LLM inference endpoints, model serving, containerized AI infrastructure, TLS-terminated AI APIs.

What is the CVSS score for CVE-2025-14831?

CVE-2025-14831 has a CVSS v3.1 base score of 5.3 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

LLM inference endpointsmodel servingcontainerized AI infrastructureTLS-terminated AI APIs

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service
AML.T0034.001 Resource-Intensive Queries
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: 8.4
NIST AI RMF: MANAGE 2.2
OWASP LLM Top 10: LLM04

What are the technical details?

Original Advisory

A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).

Exploitation Scenario

An adversary targeting an enterprise vllm inference gateway uses standard OpenSSL tooling to generate an X.509 certificate containing hundreds of name constraint extensions and thousands of Subject Alternative Names — all syntactically valid, all designed to maximize the quadratic complexity of GnuTLS's constraint-checking algorithm. The attacker initiates a TLS connection to the vllm API endpoint and presents this certificate during the handshake. GnuTLS enters a near-infinite loop cross-checking constraint permutations; CPU pegs at 100% and heap memory grows unboundedly. Within seconds the vllm worker process is either unresponsive or killed by the OOM killer. A single low-bandwidth connection is sufficient; no authentication, model access, or prior foothold is required. Repeated at short intervals, this keeps the inference service perpetually unavailable.

Weaknesses (CWE)

CWE-407 — Inefficient Algorithmic Complexity: An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

Timeline

Published
February 9, 2026
Last Modified
June 10, 2026
First Seen
June 12, 2026

Related Vulnerabilities