Every CVE Search/ Get API key

CVE-2026-41523

vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution

7.5 HighFix available

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, 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). This vulnerability is fixed in 0.22.0.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
None
User interaction
Required

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
High

Exploit likelihood

0.91%Up 0.9 points since Jun 14, 2026
90%50%10%1%

What each source reports

CVE List Score used 7.5

vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, 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). This vulnerability is fixed in 0.22.0.

Record
CVE-2026-41523
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Weakness
CWE-94, CWE-617, CWE-617
Updated
2026-11-02
EUVDEUVD-2026-38406 7.5

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, 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). This vulnerability is fixed in 0.22.0.

Record
EUVD-2026-38406
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Updated
2026-11-02
GitHub AdvisoriesGHSA-q8gq-377p-jq3r 7.5

vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution

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:

  1. Victim loads a malicious model from HuggingFace (user interaction)
  2. vLLM runs under python -O or PYTHONOPTIMIZE=1 (documented in production use)
  3. 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…

Record
GHSA-q8gq-377p-jq3r
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Weakness
CWE-94, CWE-617
Updated
2026-11-02
NVD 7.5

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, 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). This vulnerability is fixed in 0.22.0.

Record
CVE-2026-41523
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Weakness
CWE-94, CWE-617
Updated
2026-11-02
OSV 7.5

vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, 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). This vulnerability is fixed in 0.22.0.

Record
CVE-2026-41523
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Weakness
CWE-617, CWE-94
Updated
2026-11-02
OSVGHSA-q8gq-377p-jq3r 7.5

vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution

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:

  1. Victim loads a malicious model from HuggingFace (user interaction)
  2. vLLM runs under python -O or PYTHONOPTIMIZE=1 (documented in production use)
  3. 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…

Record
GHSA-q8gq-377p-jq3r
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Weakness
CWE-617, CWE-94
Updated
2026-11-02
OSVPYSEC-2026-2300 7.5

vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.22.0, 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). This vulnerability is fixed in 0.22.0.

Record
PYSEC-2026-2300
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
vllm
PyPI
before 0.22.0
0.22.0
vllm
PyPI
before 0.22.0, plus listed versions
0.0.10.1.00.1.10.1.20.1.3
Show 45 moreShow less
0.1.40.1.50.1.60.1.70.10.00.10.10.10.1.10.10.20.11.00.11.10.11.20.12.00.13.00.14.00.14.10.15.00.15.10.16.00.17.00.17.10.18.00.18.10.19.00.19.10.2.00.2.10.2.1.post10.2.20.2.30.2.40.2.50.2.60.2.70.20.00.20.10.20.20.21.00.3.00.3.10.3.20.3.30.4.00.4.0.post10.4.10.4.2
0.22.0

History

History
RecordedChangedSources
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-41523 is a high vulnerability (CVSS 7.5) in Vllm, published June 16, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.91%, the 60th percentile. Fixed in vllm 0.22.0.

References

Show 19 moreShow less
This page doesn't list everything

Left out here: 36 versions and the rest of 2 source descriptions. The JSON record has them.

MoveEnter Open