CVE-2026-27893: vLLM's hardcoded trust_remote_code=True in NemotronVL and KimiK25 bypasses user security opt-out

Published Mar 26, 2026
·
Updated

Summary

Two model implementation files hardcode trustremotecode=True when loading sub-components, bypassing the user's explicit --trust-remote-code=False security opt-out. This enables remote code execution via malicious model repositories even when the user has explicitly disabled remote code trust.

### Details

Affected files (latest main branch):

1. vllm/modelexecutor/models/nemotronvl.py:430 python visionmodel = AutoModel.fromconfig(config.visionconfig, trustremotecode=True)

2. vllm/modelexecutor/models/kimik25.py:177 python cachedgetimageprocessor(self.ctx.modelconfig.model, trustremotecode=True)

Both pass a hardcoded trustremotecode=True to HuggingFace API calls, overriding the user's global --trust-remote-code=False setting.

Relation to prior CVEs: - CVE-2025-66448 fixed automap resolution in vllm/transformersutils/config.py (config loading path) - CVE-2026-22807 fixed broader automap at startup - Both fixes are present in the current code. These hardcoded instances in model files survived both patches — different code paths.

Impact

Remote code execution. An attacker can craft a malicious model repository that executes arbitrary Python code when loaded by vLLM, even when the user has explicitly set --trust-remote-code=False. This undermines the security guarantee that trustremotecode=False is intended to provide.

Remediation: Replace hardcoded trustremotecode=True with self.config.modelconfig.trustremotecode in both files. Raise a clear error if the model component requires remote code but the user hasn't opted in.

Other sources

vLLM is an inference and serving engine for large language models (LLMs). Starting in version 0.10.1 and prior to version 0.18.0, two model implementation files hardcode trustremotecode=True when loading sub-components, bypassing the user's explicit --trust-remote-code=False security opt-out. This enables remote code execution via malicious model repositories even when the user has explicitly disabled remote code trust. Version 0.18.0 patches the issue.

MITRE

Affected Software

3 affected componentsFixes available
pypi/vllm>=0.10.1<0.18.0
pip/vllm>=0.10.1<0.18.0
0.18.0
vllm vllm>=0.10.1<0.18.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/vllm to a version that resolves this vulnerability.

    Fixed in 0.18.0
  2. Upgrade

    Upgrade vllm to a version that resolves this vulnerability.

    Fixed in 0.18.0
  3. Configuration

    In vllm/model_executor/models/nemotron_vl.py at the cached_get_image_processor call (currently uses trust_remote_code=True), replace the hardcoded trust_remote_code=True with self.config.model_config.trust_remote_code (i.e., use the user/config-provided setting so --trust-remote-code=False is respected).

    vLLM model loading (NemotronVL) trust_remote_code = self.ctx.model_config.model_config.trust_remote_code
  4. Configuration

    In vllm/model_executor/models/kimi_k25.py at the AutoModel.from_config call (currently uses trust_remote_code=True), replace the hardcoded trust_remote_code=True with self.config.model_config.trust_remote_code (so the user's --trust-remote-code=False is enforced).

    vLLM model loading (KimiK25) trust_remote_code = self.config.model_config.trust_remote_code
  5. Compensating control

    Add logic to raise a clear error when the model component requires remote code but the user hasn't opted in (per the described intended behavior in the remediation).

Event History

Mar 26, 2026
CVE Published
via MITRE·11:56 PM
Data Sourced
via MITRE·11:56 PM
DescriptionSeverityWeakness
Mar 27, 2026
Data Sourced
via Red Hat·12:02 AM
DescriptionSeverityAffected Software
Data Sourced
via NVD·12:16 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·12:16 AM
RemedyAffected Software
Advisory Published
via GitHub·03:27 PM
Data Sourced
via GitHub·03:27 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-27893?

CVE-2026-27893 has a medium severity due to the hardcoded trust_remote_code=True, which could lead to security risks.

2

How do I fix CVE-2026-27893?

To fix CVE-2026-27893, update vLLM to version 0.18.0 or later, where the hardcoded setting has been removed.

3

Which versions of vLLM are affected by CVE-2026-27893?

vLLM versions from 0.10.1 to 0.18.0 are affected by CVE-2026-27893.

4

What impact does CVE-2026-27893 have on security?

CVE-2026-27893 allows untrusted remote code execution, which poses a significant security risk for applications utilizing vulnerable vLLM versions.

5

Can I still use vLLM if I can't update to a safe version due to compatibility issues related to CVE-2026-27893?

If you cannot update vLLM, consider disabling the functionality that relies on remote code execution to mitigate the risks associated with CVE-2026-27893.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203