CVE-2026-41523 Overview
CVE-2026-41523 is a code injection vulnerability [CWE-94] in vLLM, an inference and serving engine for large language models (LLMs). Versions prior to 0.22.0 rely on an assert statement to validate activation function names during model loading. When vLLM runs in Python optimized mode (python -O or PYTHONOPTIMIZE=1), the interpreter strips assert statements, removing the security check entirely. An unauthenticated attacker can publish a malicious HuggingFace model that triggers arbitrary code execution on any server that loads it. The issue is fixed in vLLM 0.22.0.
Critical Impact
Unauthenticated remote code execution on vLLM inference servers running in Python optimized mode through malicious model loading.
Affected Products
- vLLM versions prior to 0.22.0
- Deployments running with python -O or PYTHONOPTIMIZE=1
- Inference servers loading untrusted HuggingFace models
Discovery Timeline
- 2026-06-22 - CVE-2026-41523 published to NVD
- 2026-06-24 - Last updated in NVD database
Technical Details for CVE-2026-41523
Vulnerability Analysis
The vulnerability resides in vLLM's activation function loader within vllm/model_executor/layers/pooler/activations.py. The loader resolves an activation function name supplied by the model configuration through resolve_obj_by_qualname(), which performs dynamic attribute resolution on an arbitrary qualified name. To restrict loading to safe torch.nn.modules.* classes, the code uses an assert statement to verify the function name prefix.
Python's optimized execution mode removes all assert statements at compile time. When operators launch vLLM with python -O or set PYTHONOPTIMIZE=1, the prefix check disappears and any qualified name resolves and executes. An attacker can set sbert_ce_default_activation_function in a HuggingFace model configuration to reference an arbitrary callable, achieving code execution when the model loads.
Root Cause
The root cause is the use of assert for security-critical input validation. Assertions are intended for development-time invariants, not authorization decisions. Combined with dynamic attribute resolution through resolve_obj_by_qualname(), the stripped check allows attacker-controlled strings to invoke arbitrary Python callables.
Attack Vector
An attacker publishes a malicious model to HuggingFace with a crafted configuration field referencing a dangerous callable. When a vLLM server running in optimized mode loads the model, the loader instantiates the attacker-specified object, executing code in the server process context. User interaction is limited to triggering the model load.
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"
- )
+ if not function_name.startswith("torch.nn.modules."):
+ raise ValueError(
+ "Loading of activation functions is restricted to "
+ "torch.nn.modules for security reasons"
+ )
fn = resolve_obj_by_qualname(function_name)()
return PoolerActivation.wraps(fn)
Source: vLLM security patch commit b3c7ffc
Detection Methods for CVE-2026-41523
Indicators of Compromise
- Python processes for vLLM launched with -O flag or with PYTHONOPTIMIZE=1 set in the environment.
- Unexpected child processes or outbound network connections originating from vLLM worker processes after model load.
- HuggingFace model configurations containing sbert_ce_default_activation_function values that do not start with torch.nn.modules..
- Loading of models from untrusted or newly published HuggingFace repositories without provenance review.
Detection Strategies
- Inspect process command lines and environment variables for -O or PYTHONOPTIMIZE settings on hosts running vLLM.
- Audit downloaded model configuration files for activation function references outside the torch.nn.modules namespace.
- Monitor for vLLM processes spawning shells, package managers, or compilers, which indicates code execution beyond inference workloads.
Monitoring Recommendations
- Alert on file integrity changes to vllm/model_executor/layers/pooler/activations.py and the installed vLLM package version.
- Log all HuggingFace model downloads with the source repository, revision hash, and loading user identity.
- Track network egress from inference hosts to non-allowlisted destinations after model load events.
How to Mitigate CVE-2026-41523
Immediate Actions Required
- Upgrade vLLM to version 0.22.0 or later on all inference hosts.
- Stop running vLLM with python -O or PYTHONOPTIMIZE=1 until patching is complete.
- Restrict model loading to a vetted allowlist of HuggingFace repositories and pin specific revisions.
- Isolate vLLM workers in dedicated containers or accounts with minimal filesystem and network privileges.
Patch Information
The fix replaces the assert statement with an explicit if check that raises a ValueError, ensuring the prefix validation survives Python optimized mode. The same pattern is applied across additional validation points such as vllm/pooling_params.py. Apply the upstream release 0.22.0 or cherry-pick commit b3c7ffcab82c2439726f8cb213800f6f38c023d3. See the vLLM GitHub Security Advisory GHSA-q8gq-377p-jq3r and the Huntr Bounty Report for additional context.
Workarounds
- Unset PYTHONOPTIMIZE and remove -O flags from vLLM service definitions and container entrypoints.
- Load only models from trusted, internally mirrored repositories and validate model configuration files before deployment.
- Run vLLM processes under a dedicated unprivileged user with seccomp or AppArmor profiles restricting process and network capabilities.
# Verify vLLM version and runtime configuration
pip install --upgrade "vllm>=0.22.0"
# Ensure optimized mode is disabled in service environment
unset PYTHONOPTIMIZE
systemctl cat vllm.service | grep -E 'PYTHONOPTIMIZE|python .* -O'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

