CVE-2025-9141 Makes Inference Engines a Governed Security Dependency
What happened
A technical essay by independent researcher Boyd Kane, titled LLMs could control their host machines by exploiting inference engines, published on 24 August 2026, documents a class of attack in which a malicious or compromised LLM exploits weaknesses in the inference engine running its weights to execute arbitrary code on the host machine. The research is not hypothetical: it centers on CVE-2025-9141, a confirmed arbitrary-code-execution vulnerability in vLLM's tool-call parser that passed model-generated output directly to a Python eval() call, a change that was merged into the codebase despite automated tooling flagging it as a critical security risk. The same vulnerability class applies to other widely used inference engines, including SGLang. Kane recommends that enterprise teams separate the GPU inference host from the token-parsing host, treat all inference engine output as untrusted input, and apply explicit sandboxing to any component that processes model-generated text before executing downstream logic. This finding extends the control perimeter for self-hosted AI deployments well beyond the model itself and into the infrastructure stack that runs it, a gap that has also surfaced in related research on supply chain attacks against AI dependencies.
Why it matters
- ·Inference engines such as vLLM are open-source dependencies with their own vulnerability lifecycle, but most enterprise AI governance programs do not subject them to the same patch management and intake scrutiny applied to other critical software, leaving self-hosted model deployments without a governed update cadence for the runtime layer.
- ·CVE-2025-9141 demonstrates that the review controls meant to catch dangerous code changes can be overridden in practice: an automated warning was raised and the change was merged anyway, pointing to a process failure in vendor security governance that enterprise procurement teams cannot assume has been corrected without verification.
- ·Organizations running self-hosted open-weight models at scale face a loss-of-control scenario that existing AI incident response plans were not designed to address, because the threat originates from the model's interaction with its own runtime rather than from a network-based attacker or a misbehaving output.
Governance controls affected
What to do now
- ☐Audit all self-hosted inference engine deployments (vLLM, SGLang, and equivalents) to identify whether CVE-2025-9141 or related eval()-class vulnerabilities are present in your current versions and apply available patches immediately.
- ☐Add inference engines to your AI software bill of materials and subject them to the same vulnerability scanning, patch SLA, and update notification requirements applied to other critical infrastructure dependencies.
- ☐Implement host-level isolation between the GPU inference process and any component that parses or acts on model output, treating model-generated text as untrusted input at every stage of the processing pipeline.
- ☐Update your open-source model intake policy to require a security review of the inference engine and serving stack, not just the model weights, before any self-hosted deployment is approved for production.
- ☐Review your AI incident response playbook to add a containment scenario covering host-level code execution originating from the inference layer, and assign clear ownership for infrastructure-level AI security incidents.
What to watch next
Compliance teams should monitor the vLLM and SGLang project release histories for additional disclosures in the tool-parser and output-processing components, as the CVE-2025-9141 class of vulnerability is unlikely to be isolated to a single instance. Regulatory guidance on AI infrastructure security is still nascent, but the NIST AI Risk Management Framework Playbook and emerging supply chain controls signal that regulators will increasingly expect documented vulnerability management for the full AI runtime stack, not just the model artifact. The pattern of automated security warnings being overridden during code review, documented here, also warrants attention from teams evaluating open-source inference engine vendors, as it suggests that vendor security process maturity cannot be assumed from project popularity alone.
Stay ahead of stories like this
Get every Global AI governance development like this one, plus the rest of the week's developments. Every Thursday.