vLLM Assert Bypass - Optimized Mode Model Load RCE

How the attack works

An operator or an automated deployment starts vLLM with Python's -O or -OO flag, a combined flag like -uO, or the PYTHONOPTIMIZE environment variable set to a non-zero value. This causes Python to strip all assert statements from the running code, including the check vLLM uses to validate a model's declared activation function. Once that check is gone, a model hosted on HuggingFace can name any callable as its 'activation function.' When that model is loaded, the callable runs inside the vLLM worker process with no authentication required. The rule fires the moment both a vLLM entrypoint and an optimized-mode flag appear together in the same launch command — before any model is even loaded.

Netzilo detection

Why it matters

An attacker who can get their model loaded by an exposed vLLM instance running in optimized mode gets arbitrary code execution inside the worker process, with no authentication needed. This can lead to data theft, lateral movement, or full compromise of the host running the model.

What you can do

• →Never start vLLM with -O, -OO, or PYTHONOPTIMIZE set to a non-zero value; run it in standard debug mode so built-in safety asserts stay active.
• →Check base container images and startup scripts for a global PYTHONOPTIMIZE=1 setting that could silently apply to vLLM containers.
• →Upgrade to vLLM 0.22.0 or later, where the activation-function check is not solely dependent on assert statements.
• →Restrict which models can be loaded by vLLM instances to a vetted, trusted source rather than accepting arbitrary HuggingFace model names.

Known benign look-alikes

• ML platform teams benchmarking vLLM throughput deliberately under python -O; the finding is still a real exposure but is an accepted internal configuration.
• Base container images that export PYTHONOPTIMIZE=1 for every Python service and happen to start a vLLM server from the same command line.
• A command line that passes -O to an unrelated Python script while also referencing a wheel, image or path whose name matches a vLLM entrypoint pattern.
• Shell one-liners that print, grep or document the vulnerable invocation rather than run it - suppressed by filter_inspection_tool.
• curl -O / wget -O downloading a vLLM artifact in the same shell line, where the -O is an output-file flag and not a Python flag - suppressed by filter_download_output_flag.
• Lint, type-check and test harness invocations over a vLLM source tree - suppressed by filter_test_harness.
• --help / --version probes of the vLLM CLI - suppressed by filter_help_or_version.

References

• https://github.com/vllm-project/vllm/security/advisories
• https://docs.python.org/3/using/cmdline.html#cmdoption-O
• https://attack.mitre.org/techniques/T1195/001/
• https://attack.mitre.org/techniques/T1059/006/

Related threats