From the Red Hat edition of November 5, 2026
Red Hat CVE-2026-114053: Important vLLM multimodal RCE when trust_remote_code is on; AI Inference 3.5.3 fixes some images while 'fast', RHEL AI and several OpenShift AI packages stay Affected
Red Hat Product Security · Enterprise AI inference / OpenShift AI / RHEL AI security · Global product security record (applies to U.S. SLED operators of Red Hat AI)
- Publisher
- Red Hat Customer Portal CVE database
- Original publication
- CVE public date October 21, 2026; affected releases recorded November 3, 2026
- Source retrieved
- 2026-11-06
- Event date
- 2026-11-03
What happened
Why now: after the Nov. 3 Red Hat AI Inference 3.5.3 wave already covered in the Nov. 4 edition, this CVE record remains the operator-facing statement of exploit conditions and residual Affected packages. CVE-2026-114053 (Important) describes unauthenticated RCE via attacker-controlled multimodal processor code_revision when trust_remote_code is enabled (vLLM 0.7.3 before 0.31.0). Red Hat rates it Important, not Critical, because exploitation needs non-default settings; the statement says Red Hat AI deployments disable remote code execution by default. Affected releases list Nov. 3 fixes under RHSA-2026:94702/94709/94717/94721/94738 for several rhaii/vllm-* images, while package_state still marks numerous rhaii-fast/* images, multiple RHEL AI 3 bootc images, and several OpenShift AI odh-vllm/kserve/llm-d packages Affected.
Why it matters
State, local and education operators running OpenShift AI, RHEL AI or Red Hat AI Inference must treat trust_remote_code enablement—including flags copied from day-0 model blogs—as a privileged change, and must track which image streams remain Affected after the Nov. 3 advisories. Federal KEV-style urgency does not automatically apply, but public-sector IR playbooks still need a clear default-deny posture for dynamic processor loading.
Evidence and measured results
Red Hat Security Data JSON and portal page for CVE-2026-114053: threat_severity Important; statement on default-disabled remote code; details on /tokenize multimodal code_revision path; affected_release entries dated 2026-11-03; package_state rows showing Affected for fast-channel and several RHOAI/RHEL AI packages. This is vendor security status, not an independent exploit write-up.
Limitations and uncertainty
CVE public date is Oct. 21; included now because residual Affected state and the default-deny statement are newly actionable beside Nov. 4–5 day-0 model guidance. No evidence of in-the-wild exploitation against SLED tenants is provided.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-05; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- After a large AI Inference CVE batch, buyers still need clarity on residual Affected images and whether day-0 model flags reopen the RCE path.
- Stakeholders
- CISO
- AI platform owner
- IR / vulnerability management
- Discovery questions
- Which clusters still pull rhaii-fast or unfixed odh-vllm digests?
- Where is trust_remote_code set today?
- Are tokenize endpoints exposed without auth?
- Value hypothesis
- A residual-exposure review can shrink the window where Affected images or remote-code flags remain; reduction size depends on estate inventory quality.
- Potential engagement
- One-week Red Hat AI image and trust_remote_code policy review tied to CVE-2026-114053 package_state.
- Unsupported claims
- All Red Hat AI images are fixed
- The flaw is Critical on Red Hat AI defaults
- No further operator action is needed after RHSA-2026:94738
Pre-sales engineering
Role takeaway
- Fit
- Applies to any OpenShift AI, RHEL AI or Red Hat AI Inference deployment that serves vLLM, especially multimodal models.
- Architecture and integration
- Pin fixed rhaii/vllm digests; keep fast channel off production; gate ServingRuntime flags through GitOps policy.
- Prerequisites
- Access to cluster image inventory
- Errata digests for fixed streams
- Policy mechanism to block trust_remote_code
- Constraints
- Several package_state rows remain Affected
- Lab day-0 guides may conflict with hardened defaults
- Multimodal features may pressure teams to enable remote code
- Security
- Default-deny remote code; authenticate tokenize/inference; monitor for flag drift.
- Proof of value
- Inventory shows no production fast-channel Affected digests without exception
- Config search finds zero trust_remote_code in prod overlays
- Tokenize endpoint requires auth in a smoke test
Delivery
Role takeaway
- Work
- Inventory images against package_state, patch where fixed, document residual Affected, codify remote-code deny, and retest serving.
- Dependencies
- Security advisory process
- GitOps owners for ServingRuntime templates
- App teams using multimodal models
- Ownership
- Platform engineering owns image pins; security owns exception process; app teams own temporary lab exceptions.
- Skills and adoption
- Operators need errata literacy, ServingRuntime/Helm flag review and basic authn verification.
- Governance checkpoints
- Exception board for any trust_remote_code enablement
- Post-patch package_state re-check
- IR playbook update referencing this CVE
- Acceptance criteria
- Written inventory of Affected vs fixed streams
- Production configs deny trust_remote_code
- Smoke test shows authenticated tokenize/inference
- Risks
- Teams assume RHSA-2026:94738 cleared all images
- Day-0 blogs silently reintroduce remote code
- Unauthenticated tokenize left exposed on internal networks
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?
Prefer fixed Red Hat AI Inference 3.5.3+ digests over fast-channel images while those remain Affected; keep tokenize/inference APIs authenticated; separate any lab profile that needs trust_remote_code from production serving.
Governance
Who approves, reviews and stays accountable for outcomes?
Require change tickets for trust_remote_code, model-repo integrity checks and residual Affected-package review after each AI errata batch—not only operator upgrades.
Security and privacy
What data, permissions and controls need testing?
Unauthenticated callers plus trust_remote_code plus attacker-influenced model revision equals process RCE. Default-deny remote code is the primary control Red Hat documents; patching alone is incomplete while package_state still lists Affected images.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
No direct accessibility finding; security patching workload falls on already stretched SLED platform teams.
Procurement
What should contracts, pricing and exit terms secure?
Ask vendors and integrators which image channel (stable vs fast) and remote-code posture they ship; require digest pins in contracts for managed AI Inference.
Operating model
Which teams own the service once it runs?
Treat AI runtime flags as controlled configuration with the same rigor as firewall changes; separate lab profiles from production serving.
Publication history
- 2026-11-05Red Hat · Issue 074 resources
Stable resource ID: redhat-cve-2026-114053-vllm-trust-remote-code-rce-status