vLLM Assert-Stripped Activation Function Load

vLLM is an inference server for running large language models. It has an internal safety check that stops a model's config file from pointing at arbitrary Python code, but that check only exists as a Python assert statement. If vLLM is started with assertions turned off, the check silently disappears, and a malicious model config can then run arbitrary code on the server.

How the attack works

An attacker prepares a HuggingFace-style model config.json with an activation-function field pointing at a dangerous Python function such as os.system, subprocess.*, or pty.spawn. Separately, the vLLM server must be started with Python optimizations enabled — via python -O, -OO, or PYTHONOPTIMIZE — which strips out the assert that normally blocks unapproved activation function names. With that check gone, vLLM loads the attacker's config and passes the field straight into an import-and-call mechanism, executing the attacker's chosen code with the privileges of the vLLM process. The rule watches for both signs independently: a vLLM process starting with assertions disabled, and a vLLM process whose command line already carries a known code-execution gadget as its activation function.

Why it matters

Successful exploitation gives arbitrary code execution on the machine running the model server, at whatever privilege level vLLM runs with — potentially exposing model weights, API keys, other tenants' data, or the underlying host.

What you can do

Never run production vLLM instances with python -O, -OO, or PYTHONOPTIMIZE set — treat that as a hard requirement, not a performance tuning choice.
Check container base images and startup scripts for a global PYTHONOPTIMIZE=1 that silently disables assertions for every process, including vLLM.
Only load model configs (config.json) from sources you trust and control; treat activation_fn/sbert_ce_default_activation_function fields as untrusted input.
Run inference servers with least-privilege service accounts so that code execution inside vLLM doesn't translate directly into broader host or network access.

Known benign look-alikes

Deliberate performance tuning — an operator running a vLLM inference server under python -O or PYTHONOPTIMIZE=1 with only locally built, trusted model weights. This is the dominant benign case and the reason the rule reports rather than blocks.
Container base images that export PYTHONOPTIMIZE=1 globally, so every vLLM process spawned inside them inherits the flag on its command line.
Security researchers or platform engineers reproducing this advisory in a sandbox; the launch is indistinguishable from the real exploit by design.
Benchmark and profiling scripts (vllm bench, custom throughput harnesses) that intentionally disable assertions to remove check overhead.
An internal serving wrapper that legitimately passes a custom activation callable through --hf-overrides whose module path happens to contain one of the gadget tokens (e.g. a package named ctypes_ops).