CVE-2026-90713: vLLM: local DoS via malformed tiktoken vocab file

LOW
Published September 14, 2026
CISO Take

A low-severity denial-of-service flaw exists in vLLM's tiktoken vocabulary file handler (TiktokenTokenizer::new, rust/src/text/src/backend/hf/mod.rs) up to version 0.29.0, where a malformed vocab file causes improper resource shutdown (CWE-404) and crashes the tokenizer. The attack requires local access — this is not a remotely exploitable vulnerability — but a proof-of-concept exploit is already public and the upstream fix (vllm-project/vllm PR #51135) is still awaiting merge, so no patched version exists yet. Blast radius is limited: no confidentiality or integrity impact, only availability, and there's no EPSS score or CISA KEV listing to suggest active exploitation in the wild. For CISOs running vLLM in shared or multi-tenant inference environments (research clusters, internal ML platforms, notebook-based dev environments), this is a plausible insider-risk or supply-chain vector — a malicious or corrupted tokenizer/vocab file bundled with a downloaded model could crash the serving process for all co-located users. Track the upstream PR for merge and pin vLLM builds; in the meantime, restrict local shell/file access to inference hosts and validate tokenizer artifacts before loading them, especially when pulled from third-party model repositories.

Sources: NVD vuldb.com ATLAS

What is the risk?

Overall risk is LOW. CVSS 3.3 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) reflects a purely availability-impacting bug requiring local, low-privilege access with no user interaction. Exploitability is trivial once local access is obtained — a public exploit exists — but the precondition (local access to the host running vLLM) meaningfully narrows the realistic attacker population to insiders, compromised local accounts, or supply-chain vectors delivering a malicious vocab/tokenizer file. No EPSS score, no CISA KEV entry, and no scanner template (Nuclei) exist, consistent with a low-priority, non-network-exploitable issue. The fix is not yet merged, so organizations cannot patch immediately.

How does the attack unfold?

Local Access
Attacker obtains local access to a host running vLLM (shared research/inference environment or compromised local account).
Malicious Vocab Delivery
Attacker supplies or points vLLM at a malformed tiktoken vocabulary file, potentially disguised as part of a model artifact.
AML.T0010.003
Tokenizer Initialization Crash
TiktokenTokenizer::new mishandles the malformed file, triggering improper resource shutdown/release (CWE-404) and crashing the process.
Denial of Service
The vLLM inference worker becomes unavailable, denying service to all users relying on that shared endpoint until restarted.
AML.T0029

What systems are affected?

Package Ecosystem Vulnerable Range Patched
vLLM pip No patch
91.6K 92 dependents Pushed 6d ago 27% patched ~49d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1
3.3 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 5% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

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

What should I do?

1 step
  1. 1) Track vllm-project/vllm PR #51135 and upgrade as soon as it merges and a release ships. 2) Until patched, avoid loading tiktoken vocab files from untrusted or unverified sources (third-party model repos, user-uploaded custom tokenizers). 3) Restrict local shell/filesystem access to hosts running vLLM inference to trusted operators only — this vulnerability requires local access, so standard host-hardening (least privilege, no shared shell accounts) is an effective interim control. 4) Add process-level monitoring/alerting for unexpected vLLM worker crashes or restarts, which would indicate exploitation attempts or accidental corruption. 5) In multi-tenant serving environments, consider process isolation (containers/sandboxing per tenant) so a single crashed worker doesn't affect other tenants.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
MEASURE 2.7 - AI system resilience and security assessment
OWASP LLM Top 10
LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-90713?

A low-severity denial-of-service flaw exists in vLLM's tiktoken vocabulary file handler (TiktokenTokenizer::new, rust/src/text/src/backend/hf/mod.rs) up to version 0.29.0, where a malformed vocab file causes improper resource shutdown (CWE-404) and crashes the tokenizer. The attack requires local access — this is not a remotely exploitable vulnerability — but a proof-of-concept exploit is already public and the upstream fix (vllm-project/vllm PR #51135) is still awaiting merge, so no patched version exists yet. Blast radius is limited: no confidentiality or integrity impact, only availability, and there's no EPSS score or CISA KEV listing to suggest active exploitation in the wild. For CISOs running vLLM in shared or multi-tenant inference environments (research clusters, internal ML platforms, notebook-based dev environments), this is a plausible insider-risk or supply-chain vector — a malicious or corrupted tokenizer/vocab file bundled with a downloaded model could crash the serving process for all co-located users. Track the upstream PR for merge and pin vLLM builds; in the meantime, restrict local shell/file access to inference hosts and validate tokenizer artifacts before loading them, especially when pulled from third-party model repositories.

Is CVE-2026-90713 actively exploited?

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

How to fix CVE-2026-90713?

1) Track vllm-project/vllm PR #51135 and upgrade as soon as it merges and a release ships. 2) Until patched, avoid loading tiktoken vocab files from untrusted or unverified sources (third-party model repos, user-uploaded custom tokenizers). 3) Restrict local shell/filesystem access to hosts running vLLM inference to trusted operators only — this vulnerability requires local access, so standard host-hardening (least privilege, no shared shell accounts) is an effective interim control. 4) Add process-level monitoring/alerting for unexpected vLLM worker crashes or restarts, which would indicate exploitation attempts or accidental corruption. 5) In multi-tenant serving environments, consider process isolation (containers/sandboxing per tenant) so a single crashed worker doesn't affect other tenants.

What systems are affected by CVE-2026-90713?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference.

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

CVE-2026-90713 has a CVSS v3.1 base score of 3.3 (LOW). The EPSS exploitation probability is 0.15%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference

MITRE ATLAS Techniques

AML.T0010.003 Model
AML.T0029 Denial of AI Service

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

A security flaw has been discovered in vllm-project vLLM up to 0.29.0. The affected element is the function TiktokenTokenizer::new of the file rust/src/text/src/backend/hf/mod.rs of the component tiktoken vocab File Handler. The manipulation results in denial of service. The attack is only possible with local access. The exploit has been released to the public and may be used for attacks. The pull request to fix this issue awaits acceptance.

Exploitation Scenario

In a shared research or internal ML platform, a low-privileged user with local shell access to the vLLM host (or the ability to point vLLM at a custom model/tokenizer directory) supplies a specially malformed tiktoken vocabulary file. When vLLM initializes the tokenizer via TiktokenTokenizer::new, the malformed file triggers improper resource shutdown/release, crashing the inference worker process. If the worker is shared across multiple users or applications, this denies service to everyone relying on that inference endpoint until it is restarted — a low-sophistication but disruptive insider or supply-chain-style attack.

Weaknesses (CWE)

CWE-404 — Improper Resource Shutdown or Release: The product does not release or incorrectly releases a resource before it is made available for re-use.

  • [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
  • [Implementation] It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions.

Source: MITRE CWE corpus.

CVSS Vector

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

Timeline

Published
September 14, 2026
Last Modified
September 15, 2026
First Seen
September 14, 2026

Related Vulnerabilities