Summary
An assert-based security check in vLLM's activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (python -O or PYTHONOPTIMIZE=1).
Details
vLLM uses an assert statement at vllm/model_executor/layers/pooler/activations.py:48 as its sole security control to restrict which activation functions can be loaded from a HuggingFace model's config.json:
# vllm/model_executor/layers/pooler/activations.py:35-53
function_name: str | None = None
if (
hasattr(config, "sentence_transformers")
and "activation_fn" in config.sentence_transformers
):
function_name = config.sentence_transformers["activation_fn"]
elif (
hasattr(config, "sbert_ce_default_activation_function")
and config.sbert_ce_default_activation_function is not None
):
function_name = config.sbert_ce_default_activation_function
if function_name is not None:
assert function_name.startswith("torch.nn.modules."), (
"Loading of activation functions is restricted to "
"torch.nn.modules for security reasons"
)
fn = resolve_obj_by_qualname(function_name)()
Python's assert statements are stripped at compile time when running in optimized mode (python -O or PYTHONOPTIMIZE=1). When the assert is absent, the attacker-controlled function_name from the model's config.json is passed directly to resolve_obj_by_qualname() — an unrestricted import gadget:
def resolve_obj_by_qualname(qualname: str) -> Any:
module_name, obj_name = qualname.rsplit(".", 1)
module = importlib.import_module(module_name)
return getattr(module, obj_name)
This is the same vulnerability class as CVE-2017-1000433 (pysaml2 assert-based auth bypass), flagged by Bandit B101 and Ruff S101, and the reason Django proactively replaced all assert-based security checks (ticket #32508).
Attacker-controlled input sources:
config.sentence_transformers["activation_fn"] (line 40)
config.sbert_ce_default_activation_function (line 45)
Affected call sites — get_act_fn() is called via resolve_classifier_act_fn() from:
vllm/model_executor/layers/pooler/seqwise/poolers.py:122 — SequencePooler
vllm/model_executor/layers/pooler/tokwise/poolers.py:130 — TokenPooler
Broader systemic risk: resolve_obj_by_qualname is called from ~20 locations across the codebase with no validation of its own. Any future caller feeding user-controlled input to it without validation creates the same vulnerability class.
Suggested fix: Replace the assert with an explicit conditional raise:
if not function_name.startswith("torch.nn.modules."):
raise ValueError(
"Loading of activation functions is restricted to "
"torch.nn.modules for security reasons"
)
Impact
Arbitrary code execution. A malicious model author publishes a HuggingFace model with a crafted config.json. When a victim loads this model with vLLM running under python -O or PYTHONOPTIMIZE=1, arbitrary code executes during model initialization with the privileges of the vLLM process.
The attack requires:
- Victim loads a malicious model from HuggingFace (user interaction)
- vLLM runs under
python -O or PYTHONOPTIMIZE=1 (documented in production use)
- Model uses a cross-encoder architecture (e.g. BERT or RoBERTa with sequence classification)
Coordinated disclosure note: This vulnerability was also reported via huntr.com on April 2, 2026 (https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c). A GitHub Security Advisory was also filed because it is vLLM's stated preferred disclosure channel per SECURITY.md.
Fix
A fix for this was introduced in this commit: vllm-project/vllm@b3c7ffc
References
Summary
An
assert-based security check in vLLM's activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (python -OorPYTHONOPTIMIZE=1).Details
vLLM uses an
assertstatement atvllm/model_executor/layers/pooler/activations.py:48as its sole security control to restrict which activation functions can be loaded from a HuggingFace model'sconfig.json:Python's
assertstatements are stripped at compile time when running in optimized mode (python -OorPYTHONOPTIMIZE=1). When the assert is absent, the attacker-controlledfunction_namefrom the model'sconfig.jsonis passed directly toresolve_obj_by_qualname()— an unrestricted import gadget:This is the same vulnerability class as CVE-2017-1000433 (pysaml2 assert-based auth bypass), flagged by Bandit B101 and Ruff S101, and the reason Django proactively replaced all assert-based security checks (ticket #32508).
Attacker-controlled input sources:
config.sentence_transformers["activation_fn"](line 40)config.sbert_ce_default_activation_function(line 45)Affected call sites —
get_act_fn()is called viaresolve_classifier_act_fn()from:vllm/model_executor/layers/pooler/seqwise/poolers.py:122— SequencePoolervllm/model_executor/layers/pooler/tokwise/poolers.py:130— TokenPoolerBroader systemic risk:
resolve_obj_by_qualnameis called from ~20 locations across the codebase with no validation of its own. Any future caller feeding user-controlled input to it without validation creates the same vulnerability class.Suggested fix: Replace the
assertwith an explicit conditional raise:Impact
Arbitrary code execution. A malicious model author publishes a HuggingFace model with a crafted
config.json. When a victim loads this model with vLLM running underpython -OorPYTHONOPTIMIZE=1, arbitrary code executes during model initialization with the privileges of the vLLM process.The attack requires:
python -OorPYTHONOPTIMIZE=1(documented in production use)Coordinated disclosure note: This vulnerability was also reported via huntr.com on April 2, 2026 (https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c). A GitHub Security Advisory was also filed because it is vLLM's stated preferred disclosure channel per SECURITY.md.
Fix
A fix for this was introduced in this commit: vllm-project/vllm@b3c7ffc
References