CVE-2026-27893 - vLLM trust_remote_code bypass

vLLM versions starting at 0.10.1 and before 0.18.0 contain model-loading paths that hardcode trust_remote_code=True for NemotronVL and KimiK25 sub-components. That overrides an operator’s explicit --trust-remote-code=False setting and can execute Python code from a malicious or compromised model repository when the affected model architecture is loaded.

This recipe is for repositories that package, deploy, or configure vLLM inference services. It is not enough to search for trust_remote_code=True in application code; the dangerous value is inside the vulnerable vLLM package.

When to use it

  • A repository installs, builds, packages, or deploys vLLM inference services in Python environments, containers, Helm charts, notebooks, or CI images.
  • Operators rely on --trust-remote-code=False or trust_remote_code=False while model IDs can come from users, tenants, experiments, registries, mirrors, or agent workflows.
  • NemotronVL or KimiK25 model paths are allowed, cached, mirrored, or selected by configuration.
  • You need a bounded PR or triage note that upgrades vLLM and proves model provenance controls survive package, image, and deployment refreshes.

Inputs

  • Python manifests, lockfiles, Dockerfiles, images, Helm/K8s/Compose/Terraform artifacts, model-serving scripts, notebooks, SBOMs, generated manifests, and runbooks.
  • Resolved vLLM version, model source allow-list, pinned revisions, Hugging Face mirror policy, remote-code exceptions, model cache ownership, inference secrets, and token rotation policy.
  • Available dependency install, trusted-local-model tests, config policy checks, image build, deployment render, SBOM, and dependency/security scans.

Affected versions

  • Vulnerable: vllm >=0.10.1, <0.18.0
  • Fixed: vllm 0.18.0+
  • Affected model paths: NemotronVL and KimiK25 sub-component loading
  • Related earlier fixes: CVE-2025-66448 and CVE-2026-22807 fixed different auto_map paths; this CVE survived those fixes.

Indicator-of-exposure

  • The repository installs, builds, or deploys vllm in the affected range.
  • Model-serving commands, Helm values, compose files, container images, CI images, notebooks, or runbooks rely on --trust-remote-code=False as a security boundary.
  • Model sources can be supplied by users, tenants, experiments, registry metadata, remote Hugging Face repositories, mirrored model stores, or agent workflows.
  • The runtime has access to GPU hosts, model caches, cloud credentials, inference tokens, vector stores, customer prompts, or internal network routes.

Quick checks:

rg -n "vllm|trust_remote_code|trust-remote-code|Nemotron|Kimi|model[-_ ]?(id|name|repo)|hf_hub|huggingface|MODEL|VLLM" .
python -m pip show vllm
python -m pip freeze | rg '^vllm=='
docker image ls | rg 'vllm|inference|llm'

Windows:

rg -n "vllm|trust_remote_code|trust-remote-code|Nemotron|Kimi|model[-_ ]?(id|name|repo)|hf_hub|huggingface|MODEL|VLLM" .
python -m pip show vllm
python -m pip freeze | rg '^vllm=='
docker image ls | rg 'vllm|inference|llm'

Do not load untrusted model repositories, enable remote-code trust, or run model-loading probes that fetch attacker-controlled code during triage.

Remediation strategy

  • Upgrade every repository-controlled vLLM package, image, lockfile, and deployment artifact to 0.18.0+.
  • Keep transformers, model loader adapters, CUDA image tags, and lockfiles compatible with the selected vLLM release.
  • Gate model sources: require an allow-list, pinned revision, signed mirror, or reviewed model promotion process for any model that reaches production inference.
  • Preserve --trust-remote-code=False as the default. Require explicit review before any model path opts into remote code.
  • If upgrade is blocked, contain by disabling NemotronVL and KimiK25 model loading, restricting model sources to an internal reviewed mirror, and isolating the serving runtime from sensitive credentials until upgrade lands.
  • Rotate tokens and clear model caches if an affected service loaded untrusted or tenant-controlled NemotronVL/KimiK25 model repositories.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-27893 / GHSA-7972-pg2x-xr59, a vLLM model-loading
bug where hardcoded trust_remote_code=True bypasses an explicit
--trust-remote-code=False setting for NemotronVL and KimiK25 paths. Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades vLLM to a fixed version,
  preserves the intended no-remote-code trust boundary, adds safe model-source
  checks, refreshes generated artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not own an affected vLLM runtime or cannot
  safely patch the affected model-serving environment.

## Rules

- Scope only CVE-2026-27893 / GHSA-7972-pg2x-xr59 and directly related vLLM
  model-loading trust boundaries.
- Treat model repositories, model-cache contents, inference tokens, cloud
  credentials, customer prompts, embeddings, logs, and generated completions as
  sensitive.
- Do not load untrusted model repositories, enable remote-code trust, run
  proof-of-concept model code, fetch attacker-controlled model files, or print
  secret-bearing inference environment values.
- Do not remove model provenance checks, model allow-lists, sandboxing,
  authentication, authorization, audit logging, or tests to silence the alert.
- Do not auto-merge.

## Steps

1. Inventory every vLLM runtime controlled by this repository: Python
   manifests, lockfiles, Dockerfiles, base images, Helm charts, compose files,
   Kubernetes manifests, Terraform, notebooks, CI images, model-serving
   scripts, SBOMs, and generated dependency reports.
2. Determine every resolved `vllm` version. A target is vulnerable if it
   resolves to `>=0.10.1, <0.18.0`.
3. Search model-loading configuration for trust and source controls:
   `--trust-remote-code`, `trust_remote_code`, model IDs, model registries,
   Hugging Face mirrors, pinned revisions, allow-lists, tenant-controlled model
   inputs, Nemotron, Kimi, and model promotion workflows.
4. If the repository only calls an externally owned inference endpoint, stop
   with `TRIAGE.md` naming the owner, checked files, and required fixed vLLM
   version.
5. Upgrade every affected vLLM runtime to `0.18.0+`. Refresh lockfiles,
   container tags or digests, generated manifests, SBOMs, dependency reports,
   image metadata, and deployment docs.
6. Preserve or add safe defaults:
   - keep `--trust-remote-code=False` unless an explicit reviewed exception
     exists;
   - require pinned model revisions or trusted internal mirrors for production;
   - reject tenant-controlled model identifiers unless a separate approval path
     validates them;
   - document every remaining remote-code-trust exception with owner and
     expiration.
7. If upgrade cannot land immediately, add containment where this repo owns it:
   - disable NemotronVL and KimiK25 model deployments;
   - restrict model sources to an internal reviewed mirror;
   - isolate model-serving hosts from cloud credentials and privileged network
     routes;
   - schedule an owner and follow-up date because containment is not the fix.
8. Add safe regression checks that do not load attacker-controlled code:
   - resolved `vllm` is `0.18.0+`;
   - production configs default `trust_remote_code` to false;
   - model IDs resolve only from allow-listed sources or pinned revisions;
   - logs and validation output do not expose tokens or prompt data.
9. Add a PR body section named `CVE-2026-27893 operator actions` that states:
   - affected vLLM versions before and after;
   - where vLLM runs and which model sources are allowed;
   - whether NemotronVL or KimiK25 models were in use;
   - whether `trust_remote_code` remains enabled anywhere and who approved it;
   - whether model caches, Hugging Face tokens, cloud credentials, or inference
     keys require rotation;
   - which validation commands passed.
10. Run available validation: dependency install, lockfile integrity,
    unit/integration tests that use trusted local models only, image build,
    deployment rendering, SBOM refresh, dependency/security scans, and config
    policy checks.
11. Use PR title:
    `fix(sec): remediate CVE-2026-27893 in vLLM`.

## Stop conditions

- No affected vLLM package, model-serving image, or deployment artifact is
  controlled by this repository.
- A fixed vLLM version cannot be consumed without a broader inference-platform
  migration.
- Verification would require loading untrusted model repositories, enabling
  remote code, using production prompts, or exposing live secrets.
- The only affected runtime is supplied by another platform owner; document the
  owner, required fixed version, and current exposure assumptions in TRIAGE.md.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No repository-controlled manifest, lockfile, image, SBOM, or generated dependency report resolves vllm >=0.10.1, <0.18.0.
  • Production model-serving configs keep remote-code trust disabled unless a reviewed exception is present.
  • Model sources are allow-listed, mirrored, or pinned by revision for sensitive environments.
  • Regression checks do not fetch or execute untrusted model code.
  • Operator notes cover model-cache cleanup and token rotation when untrusted models could have been loaded on vulnerable runtimes.

Output contract

  • Reviewer-ready PR upgrading every controlled vLLM runtime to 0.18.0+ with refreshed locks, images, generated manifests, SBOMs, reports, and docs.
  • Production model-source policy requiring trusted mirrors, pinned revisions, allow-listed model IDs, and reviewed exceptions for any remote-code trust.
  • Safe regression checks for fixed vLLM resolution, default remote-code disablement, model-source validation, and secret-safe logs using trusted local fixtures only.
  • TRIAGE.md when model-serving runtime, model promotion, image ownership, or inference credential cleanup is outside this repository.

Watch for

  • Updating Python manifests while Docker images or Helm values still install the vulnerable vLLM package.
  • Assuming --trust-remote-code=False is protective before vLLM is upgraded.
  • Missing generated assets such as SBOMs, deployment manifests, or pinned image digests.
  • Treating model IDs as harmless configuration when users or tenants can influence them.
  • Regression tests that prove inference still works but never assert the trust boundary or model-source policy.

References