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.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7c3f1d2e-9a54-4b61-8f27-0d5a6e3b91c4
- Severity
- Medium
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).