From the Red Hat edition of November 10, 2026
RHSA-2026:96333: Critical-rated RHEL AI 3.5.3 container image update lists 60 CVEs, including the vLLM multimodal RCE CVE-2026-114053
Red Hat Product Security · AI platform vendor security advisory · Global product
- Publisher
- Red Hat Customer Portal errata
- Original publication
- 2026-11-09
- Source retrieved
- 2026-11-11
- Event date
- 2026-11-09
What happened
Red Hat issued RHSA-2026:96333 on 2026-11-09, rated Critical, providing updated RHEL AI 3.5.3 container images. The advisory lists 60 CVE identifiers, including CVE-2026-114053 (the vLLM multimodal remote-code-execution flaw archived on 21 Oct, when RHEL AI was listed as Affected), CVE-2026-115915 and CVE-2026-93592. The 'Fixes' field reads '(none)', and the advisory points to RHEL AI release notes for changes. On retrieval, the CVE-2026-114053 record (last changed 4 Nov) did not yet reference this advisory, so per-CVE fix status for RHEL AI could not be confirmed from that record.
Why it matters
Agencies and universities running RHEL AI for on-premises model serving (often chosen to keep sensitive data local) need to track this image update. Critical-rated AI-stack advisories with dozens of CVEs show the patch cadence such deployments must resource.
Evidence and measured results
Opened the advisory page and counted the 60 CVE IDs it lists. I also opened the CVE-2026-114053 record to check cross-references: it lists five other RHSAs but not 96333. I did not inspect individual CVE details beyond those already archived.
Limitations and uncertainty
An advisory lists CVEs but does not by itself state exploitability in a given configuration. The cross-reference between advisory and CVE record was inconsistent at retrieval. I did not check NVD.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-10; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- SLED teams running on-premises RHEL AI must absorb Critical, high-volume AI-stack patch bundles.
- Stakeholders
- AI platform owner
- Vulnerability management lead
- Research computing operations
- Change manager
- Discovery questions
- Where is RHEL AI 3.5 deployed, and are any hosts disconnected?
- What is your critical-patch window for AI-serving images?
- Are inference endpoints exposed beyond trusted clients?
- Value hypothesis
- Bounded: automated image updates reduce exposure windows; value depends on local process.
- Potential engagement
- A patch-readiness review and image-update automation for RHEL AI hosts.
- Unsupported claims
- That every listed CVE is fixed for every configuration
- That on-premises AI removes security maintenance
Pre-sales engineering
Role takeaway
- Fit
- Directly relevant to any RHEL AI 3.5 deployment.
- Architecture and integration
- Container image update from registry.redhat.io; mirror for disconnected environments.
- Prerequisites
- RHEL AI 3.5 inventory
- Registry access or mirror
- Model regression tests
- Constraints
- Advisory and CVE record cross-references inconsistent at retrieval
- Disconnected sites need mirroring
- Security
- Restrict inference endpoints to trusted clients until updated; verify image digests.
- Proof of value
- Confirm 3.5.3 image digests on all hosts
- Verify CVE-2026-114053 status per CVE record once updated
- Model output regression check after update
Delivery
Role takeaway
- Work
- Plan and apply the RHEL AI 3.5.3 image update across hosts.
- Dependencies
- Change approval
- Image mirroring
- Test datasets for regression
- Ownership
- AI platform owner with vulnerability management oversight.
- Skills and adoption
- Automate image tracking; train operators on advisory and CVE reconciliation.
- Governance checkpoints
- Change approval before update
- Post-update regression sign-off
- Acceptance criteria
- Proposed: 100% of RHEL AI hosts on 3.5.3 images within the critical-patch window
- Proposed: regression tests pass on agreed model prompts
- Risks
- Update breaking model behavior
- Missed disconnected hosts
- Assuming fixes not yet confirmed
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?
RHEL AI deployments pull updated container images from registry.redhat.io. Disconnected sites need mirroring workflows to apply them promptly.
Governance
Who approves, reviews and stays accountable for outcomes?
Patch SLAs for AI-serving images should follow the agency's critical-vulnerability timelines. Advisory and CVE records may lag one another, so reconcile both.
Security and privacy
What data, permissions and controls need testing?
The bundle includes CVE IDs this archive already covers as vLLM flaws (114053 code execution; 115915). Until updated images are deployed, internet- or tenant-exposed inference endpoints remain at risk.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Small teams running RHEL AI need automated image update and rebuild pipelines, because manual tracking of 60-CVE bundles is impractical.
Procurement
What should contracts, pricing and exit terms secure?
Support contracts and managed-service agreements for on-premises AI should define patch timelines for AI-serving images, not only the base OS.
Operating model
Which teams own the service once it runs?
AI platform owners need a recurring image-update cadence with regression testing of model behavior after each update.
Publication history
- 2026-11-10Red Hat · Issue 116 resources
Stable resource ID: rhsa-2026-96333-rhel-ai-3-5-3-critical-60-cves-20261109