From the Red Hat edition of October 29, 2026
vLLM advisory GHSA-h3rc-6mm3-gc2m: request-controlled code_revision allows remote code execution
vLLM project (open-source upstream of Red Hat AI Inference Server) · Inference serving security: upstream open-source advisory · Global (open-source software)
- Publisher
- GitHub (vllm-project/vllm security advisories)
- Original publication
- GitHub Security Advisory, Oct. 6, 2026
- Source retrieved
- 2026-10-30
- Event date
- 2026-10-06
What happened
The vLLM project published a High (8.1) advisory on Oct. 6, 2026 affecting vllm >=0.7.3 and <0.31.0, patched in 0.31.0, with no CVE assigned. An untrusted multimodal request can set mm_processor_kwargs.code_revision and make vLLM import processor Python code from another revision of the served model repository. This is arbitrary code execution in the API/renderer process. It applies only when the operator has enabled trust_remote_code, the model processor uses dynamic auto_map code, and an attacker can control a revision in that repository. The default trust_remote_code=False is not affected. The advisory also notes that /tokenize is not covered by vLLM's API-key middleware unless an external proxy protects it.
Why it matters
VLLM is the inference engine inside Red Hat AI Inference Server and OpenShift AI model serving. State, local and university teams that serve community multimodal models with trust_remote_code enabled, or expose vLLM endpoints directly to campus or agency networks, carry this class of risk. Whether a given Red Hat build is affected depends on its bundled vLLM version, which this edition did not verify.
Evidence and measured results
Read the full GitHub advisory: affected and patched versions, preconditions, request path analysis, the reporter-suggested CVSS 9.8 versus the published 8.1 score with high attack complexity, and remediation guidance. The advisory includes an offline proof of concept. It was not reproduced. No Red Hat errata mapping to this advisory was opened.
Limitations and uncertainty
Red Hat engineers are major contributors to vLLM, so this upstream source is not fully independent of the vendor. The CVSS 8.1 rating assumes a specific non-default configuration. Mapping to Red Hat product versions was not verified.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-30; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Teams self-hosting open models lack visibility into inference-engine vulnerabilities and risky configuration flags.
- Stakeholders
- Research computing director
- CISO
- AI platform engineers
- Data science leads
- Discovery questions
- Where are you running vLLM today, and on which versions?
- Do any served models require trust_remote_code?
- Are inference endpoints reachable without a gateway?
- How do you track upstream open-source advisories?
- Value hypothesis
- A supported inference stack with a gateway and patch stream reduces exposure from upstream advisories compared with unmanaged deployments.
- Potential engagement
- Inference endpoint security review and migration to supported, gateway-fronted serving.
- Unsupported claims
- That Red Hat builds were or were not affected
- Any exploitation in the wild
- That gateways alone fully mitigate the issue
Pre-sales engineering
Role takeaway
- Fit
- Applies to any vLLM-based serving, including Red Hat AI Inference Server and OpenShift AI runtimes.
- Architecture and integration
- Gateway in front of vLLM covering all paths; internal model mirror; revision pinning; version inventory.
- Prerequisites
- Inventory of vLLM deployments and versions
- Gateway or proxy with authentication
- Internal model registry or mirror
- Constraints
- Version mapping to Red Hat builds not verified here
- Some multimodal models require remote code
- Advisory has no CVE, which may limit scanner coverage
- Security
- Disable trust_remote_code by default, pin revisions, authenticate every path including /tokenize, and upgrade to patched versions.
- Proof of value
- Show an unauthenticated /tokenize request is rejected at the gateway
- Show deployed vLLM versions are at or above the patched release
- Show models requiring remote code are mirrored and reviewed
Delivery
Role takeaway
- Work
- Inventory, upgrade and gateway-protect inference endpoints; add model onboarding controls.
- Dependencies
- Red Hat image release cadence
- Model owner cooperation
- Gateway availability
- Ownership
- AI platform team, with security operations tracking advisories.
- Skills and adoption
- Train platform staff to map upstream advisories to vendor builds and configuration flags.
- Governance checkpoints
- Approval required to enable trust_remote_code
- Advisory triage within the agency SLA
- Release checklist for each model deployment
- Acceptance criteria
- Proposed: all endpoints behind authenticated gateway
- Proposed: no unapproved trust_remote_code deployments
- Proposed: deployed vLLM versions patched
- Risks
- Shadow vLLM deployments outside inventory
- Scanner gaps for advisories without CVEs
- Model owners bypassing onboarding controls
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Front vLLM endpoints with an authenticating gateway that covers every path, including /tokenize. Pin model and code revisions, and avoid trust_remote_code unless reviewed. Confirm the vLLM version bundled in Red Hat AI Inference Server or OpenShift AI images.
Governance
Who approves, reviews and stays accountable for outcomes?
Model onboarding should record whether trust_remote_code is required and who approved it. Upstream advisories need tracking alongside Red Hat errata.
Security and privacy
What data, permissions and controls need testing?
Code execution in the serving process could expose prompts, documents and credentials handled by the model server. The risk is conditional on non-default configuration and attacker control of a model repository revision.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Requires staff who can read upstream advisories and map them to vendor builds, a skill gap in many SLED IT shops.
Procurement
What should contracts, pricing and exit terms secure?
Support contracts should state how quickly upstream vLLM fixes reach supported Red Hat images and how customers are notified.
Operating model
Which teams own the service once it runs?
Self-hosted inference creates a supply-chain monitoring duty across upstream projects, vendor builds and model repositories.
Publication history
- 2026-10-29Red Hat · Issue 018 resources
Stable resource ID: vllm-ghsa-h3rc-code-revision-rce-advisory-20261006