# vLLM Assert-Stripped Activation Function Load

- **Severity:** Medium
- **Signature ID:** `7c3f1d2e-9a54-4b61-8f27-0d5a6e3b91c4`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)
- **OWASP:** LLM03 (Supply Chain)

## Summary

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).

## References

- https://docs.python.org/3/using/cmdline.html#cmdoption-O
- https://docs.python.org/3/using/cmdline.html#envvar-PYTHONOPTIMIZE
- https://attack.mitre.org/techniques/T1059/006/
- https://atlas.mitre.org/techniques/AML.T0010
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

---
Source: https://www.netzilo.com/threats/vllm-optimized-mode-assert-bypass