vLLM Can Execute Malicious Model Code Despite trust_remote_code=False

• The Mess: vLLM contains a critical flaw that can ignore trust_remote_code=False when loading certain multimodal models. A malicious model can therefore reach Python code execution inside the vLLM process.
• The Damage: Downloading an untrusted AI model can become a remote-code-execution event instead of a simple model-loading operation.
• The Fix: Upgrade vLLM to 0.28.0 or later and treat third-party model files as executable input.

AI infrastructure has a dangerous assumption baked into it:

The model is data.

Sometimes it isn’t.

CVE-2026-90553 affects vLLM, a popular inference engine used to serve large language models. The vulnerability allows attacker-controlled code to execute during model loading because a code path for the LlavaOnevision2 architecture fails to properly honor the trust_remote_code security setting.

The vulnerable versions are vLLM before 0.28.0.

The bug was assigned CVSS 9.8 Critical.

And the attack doesn’t require convincing a user to click a malicious executable.

The model itself is the delivery mechanism.

The security switch that wasn’t enough

vLLM supports trust_remote_code=False for a reason.

AI models hosted on public repositories can contain custom Python code required by some architectures.

Allowing that code to execute automatically is dangerous.

So administrators can explicitly disable remote code execution:

trust_remote_code=False

The expectation is straightforward:

Untrusted model
      ↓
Model loader
      ↓
trust_remote_code=False
      ↓
No remote Python execution

CVE-2026-90553 breaks that assumption.

For the affected LlavaOnevision2 loader, the security control isn’t properly respected.

The vulnerable path

The flaw is located in the model-loading logic associated with LlavaOnevision2.

Instead of consistently passing the administrator’s security preference through the entire loading path, the vulnerable code can invoke functionality that permits attacker-controlled model code to execute.

That means the effective chain becomes:

Malicious model
      ↓
vLLM model loader
      ↓
LlavaOnevision2
      ↓
trust_remote_code ignored
      ↓
attacker-controlled Python
      ↓
vLLM process

At that point, the attacker isn’t exploiting the neural network.

They’re exploiting the software around the neural network.

That’s an important distinction.

This isn’t prompt injection

Don’t confuse this with prompt injection.

Prompt injection attempts to manipulate an already-running AI system through its input.

CVE-2026-90553 operates much earlier.

The attacker doesn’t need to persuade the model to do something.

The attacker supplies a malicious model artifact.

The inference server loads it.

The vulnerable loader executes code.

The attack therefore happens at the model supply-chain layer.

Prompt injection:
user input
   ↓
model
   ↓
malicious instructions

CVE-2026-90553:
model artifact
   ↓
loader
   ↓
Python execution

Those are completely different threat models.

Why model repositories matter

Modern AI infrastructure often pulls models from public repositories.

An administrator may think the operation is equivalent to downloading:

model.safetensors

and loading numerical weights.

But modern model ecosystems can contain much more than static tensors.

They may include:

• configuration files;
• tokenizer implementations;
• custom Python modules;
• architecture-specific code;
• preprocessing logic;
• plugin-like components.

That creates a software supply chain around the model.

And that supply chain has the same basic security problem as npm, PyPI or container images:

the artifact is not automatically trustworthy because it is called a model.

The dangerous assumption

The most dangerous assumption is:

“I disabled remote code execution.”

If the application has multiple model-loading paths, that statement is meaningless unless every path actually enforces the policy.

Security controls are only as strong as their weakest loader.

That’s what makes this vulnerability interesting.

The configuration option existed.

The administrator could set it.

The application simply didn’t consistently respect it.

What does the attacker get?

The practical impact depends on how vLLM is deployed.

A compromised vLLM process can potentially access anything available to that process.

That may include:

• model files;
• local configuration;
• environment variables;
• API credentials;
• mounted volumes;
• network services;
• cloud credentials;
• other internal resources.

If vLLM runs inside a container with excessive privileges, the impact can become much worse.

If it runs directly on a host with access to sensitive infrastructure, the attacker inherits that access.

The vulnerability therefore shouldn’t be evaluated solely as:

“The attacker can execute Python.”

The real question is:

What can the vLLM process access?

Containers don’t magically fix it

Running vLLM in Docker or Kubernetes is a useful containment layer.

It is not a substitute for patching.

A compromised inference container may still have access to:

environment variables
      ↓
API keys
      ↓
mounted model storage
      ↓
internal services
      ↓
cloud metadata

A badly configured Kubernetes deployment can make the problem substantially worse.

Examples include:

• privileged containers;
• host filesystem mounts;
• service-account tokens with excessive permissions;
• access to cloud metadata;
• broad network egress;
• shared persistent volumes.

AI infrastructure needs the same principle as any other service:

minimum privileges, minimum connectivity, minimum secrets.

The supply-chain angle

CVE-2026-90553 belongs to a growing class of vulnerabilities where the AI model itself becomes executable supply-chain input.

That changes how security teams should review model acquisition.

The old workflow looked like:

download model
↓
verify model
↓
run inference

A safer workflow is closer to:

identify source
↓
pin model version
↓
verify provenance
↓
inspect model contents
↓
sandbox loading
↓
run with minimal privileges
↓
monitor runtime

The model repository is effectively another package registry.

Treat it accordingly.

What should administrators do?

The immediate fix is simple:

Upgrade vLLM to 0.28.0 or later.

But patching is only the first step.

Organizations should also review how models reach production.

At minimum:

Pin model versions

Don’t automatically consume whatever the repository currently serves.

Control model sources

Prefer approved registries and internal mirrors.

Scan model artifacts

Inspect unexpected Python files and custom modules.

Minimize vLLM privileges

The inference service should not have access to secrets it doesn’t need.

Restrict outbound network access

A compromised inference process shouldn’t have unrestricted Internet access.

Audit environment variables

Never expose broad cloud credentials to the model-serving process.

Monitor model-loading events

Unexpected model downloads or architecture changes deserve investigation.

If you already loaded an untrusted model

Patching vLLM doesn’t answer whether the system was previously compromised.

If a vulnerable vLLM instance loaded an untrusted LlavaOnevision2 model, investigate it.

Review:

• process creation;
• outbound connections;
• filesystem changes;
• shell execution;
• newly created Python files;
• environment-variable access;
• credential usage;
• container activity;
• Kubernetes API calls.

And if the process had access to credentials, rotate them.

Don’t assume that a clean-looking container means the host or external credentials are clean.

The bigger problem with AI infrastructure

The AI security industry spends enormous amounts of time discussing:

• prompt injection;
• jailbreaks;
• model poisoning;
• data leakage;
• agentic attacks.

Those are real problems.

But CVE-2026-90553 highlights something less glamorous:

ordinary software vulnerabilities inside the AI stack can completely bypass the model’s supposed security boundaries.

The model doesn’t have to be malicious.

The loader can be.

The registry can be compromised.

The serialization format can be abused.

The preprocessing code can be vulnerable.

The inference server can be exploitable.

AI doesn’t remove traditional application security.

It adds another layer.

Bugstoday’s take

The most dangerous line in this story is not trust_remote_code=False.

It’s the assumption behind it:

“The application will respect my security setting.”

CVE-2026-90553 shows why configuration flags are not security boundaries by themselves.

If one model-loading path ignores the policy, an attacker can turn a supposedly passive model artifact into executable code.

For AI infrastructure, the lesson is brutally simple:

A model is an untrusted software supply-chain artifact until proven otherwise.

Patch vLLM.

Sandbox model loading.

Reduce privileges.

And stop treating AI models like harmless files.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Red Hat — CVE-2026-90553 vulnerability record and affected software information.
• vLLM — official project repository and release history for the fixed 0.28.0 release.
• NVD — CVE-2026-90553 vulnerability record and severity information.