Lighthouse AdvisorySLED AI Adoption Intelligence
← Back to results

From the Red Hat edition of November 10, 2026

Vendor claimCautionaryNew this fortnight

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
Read original source

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

  1. 2026-11-10Red Hat · Issue 116 resources
Read preserved resource versions (JSON)

Stable resource ID: rhsa-2026-96333-rhel-ai-3-5-3-critical-60-cves-20261109