CVE-2026-27893
Vllm 0.10.1 – 0.18.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HSummary
CVE-2026-27893 is a high-severity Protection Mechanism Failure (CWE-693) vulnerability in Vllm Vllm. Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Abuse Elevation Control Mechanism (T1548); ranked in the top 31% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
This vulnerability is AI-related — categorised as NLP and Transformers; in the Supply Chain and Deployment risk domain.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and AC-4 (Information Flow Enforcement) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-27893 is a vulnerability in vLLM, an inference and serving engine for large language models (LLMs). It affects versions starting from 0.10.1 up to but not including 0.18.0. The issue stems from two model implementation files that hardcode `trust_remote_code=True` when loading sub-components, which bypasses the user's explicit `--trust-remote-code=False` security opt-out. This flaw enables remote code execution via malicious model repositories even when remote code trust is disabled, and it is classified under CWE-693 with a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).
A remote attacker can exploit this vulnerability by hosting a malicious model repository that users might load into vLLM. Although the user specifies `--trust-remote-code=False` to prevent code execution from untrusted sources, the hardcoded setting in the affected files overrides this protection, allowing arbitrary code execution on the victim's system. Exploitation requires user interaction, such as intentionally or inadvertently loading the malicious model, but needs no privileges and has low complexity over the network, potentially leading to high-impact compromise of confidentiality, integrity, and availability.
The vulnerability is addressed in vLLM version 0.18.0. Security advisories recommend upgrading to this patched version. Details on the fix are available in the vLLM GitHub security advisory at GHSA-7972-pg2x-xr59, pull request #36192, and the patching commit 00bd08edeee5dd4d4c13277c0114a464011acf72.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-16478
Vulnerability Data
vLLM is an inference and serving engine for large language models (LLMs). Starting in version 0.10.1 and prior to version 0.18.0, two model implementation files hardcode `trust_remote_code=True` when loading sub-components, bypassing the user's explicit `--trust-remote-code=False` security opt-out. This enables remote…
more
code execution via malicious model repositories even when the user has explicitly disabled remote code trust. Version 0.18.0 patches the issue.
- CWE(s)
AI Security AnalysisAI
- AI Category
- NLP and Transformers
- Risk Domain
- Supply Chain and Deployment
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: llms, vllm
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 8 hardening rules · 6 OS baselines
V6.3.3V6.6.3V10.2.2
Mitigating Controls (NIST 800-53 r5) AI
AC-3 directly requires enforcement of access authorizations via the protection mechanism itself.
AC-4 mandates use of information flow enforcement mechanisms to control data movement.
SC-2 requires separation of user and system functionality as a protection mechanism.
SC-28 requires protection mechanisms for information at rest.
SC-3 requires isolation of security functions from non-security functions.
SC-7 requires boundary protection mechanisms to monitor and control external communications.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Enforcing authentication directly implements a core protection mechanism whose absence or misuse is the CWE.
Defining and enforcing access authorizations is a protection mechanism; proper use prevents the CWE.
Cryptographic and integrity controls are protection mechanisms whose correct deployment mitigates the CWE.
Encryption and integrity protections for transit are explicit protection mechanisms.
Logical network protections are protection mechanisms whose failure matches the CWE.
Secure-development practices (coding standards, reviews, validation) directly prevent mixing trusted and untrusted data inside the same structures.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure architecture principles require explicit trust zones and data segregation, mitigating mixing of trusted/untrusted data.
Secure coding standards can enforce input validation and data tagging, but do not guarantee architectural separation.
Systematic verification that security mechanisms operate according to defined standards reduces the likelihood that protection mechanisms are bypassed or disabled.
Hardening devices, disabling vulnerable protocols, and maintaining accurate network diagrams reduce the likelihood that a protection mechanism is misconfigured or left in a weak state.
Secure development lifecycle mandates separation of trusted and untrusted data flows, directly preventing mixing in the same structure.
Application security requirements include explicit trust-boundary definitions and data classification at interfaces.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (2 rules)
- V-248524 OL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-693
- V-248525 All OL 8 local disk partitions must implement cryptographic mechanisms to prevent unauthorized disclosure or modification of all information that requires at-rest protection. prevents CWE-693
Windows 10 (2 rules)
- V-220865 The Windows Remote Management (WinRM) service must not use Basic authentication. prevents CWE-693
- V-220812 Credential Guard must be running on Windows 10 domain-joined systems. prevents CWE-693
Windows 11 (1 rule)
- V-253418 The Windows Remote Management (WinRM) service must not use Basic authentication. prevents CWE-693
Windows Server 2016 (1 rule)
- V-225012 Windows Server 2016 must be running Credential Guard on domain-joined member servers. prevents CWE-693
Windows Server 2019 (1 rule)
- V-205907 Windows Server 2019 must be running Credential Guard on domain-joined member servers. prevents CWE-693
Windows Server 2022 (1 rule)
- V-254441 Windows Server 2022 must be running Credential Guard on domain-joined member servers. prevents CWE-693