From the Red Hat edition of October 29, 2026
RHSA-2026:86891: Critical security advisory with updated images for Red Hat OpenShift AI 3.5.2
Red Hat Product Security · Strategic partner platform: OpenShift AI security maintenance · Global (self-managed OpenShift AI customers)
- Publisher
- Red Hat Customer Portal
- Original publication
- Red Hat Customer Portal errata, issued Oct. 21, 2026
- Source retrieved
- 2026-10-30
- Event date
- 2026-10-21
What happened
Red Hat issued RHSA-2026:86891 on Oct. 21, 2026, rated Critical, providing updated container images for Red Hat OpenShift AI 3.5.2. The advisory lists many CVEs (including CVE-2024-14029 and numerous 2026 CVEs) and updated images for components including the AI gateway, AutoRAG, AutoML, EvalHub, dashboard, data science pipelines and Feast operators. Customers are directed to the OpenShift AI upgrade documentation to fully apply the errata.
Why it matters
State, local and university teams running self-managed OpenShift AI own patching. A Critical rating on the current 3.5.x line, spanning the components marketed for governed RAG and agents, means AI platform operations must follow the same vulnerability-management SLAs as other critical infrastructure.
Evidence and measured results
Opened the errata page and read the summary, severity, issued and updated dates (both 2026-10-21), the affected-product description, the CVE list and the image list. Individual CVE details were not opened, so which CVEs drive the Critical rating, and whether they are exploitable in typical configurations, is not established here.
Limitations and uncertainty
A vendor advisory states severity and fixed images but not exploitability in specific deployments. CVE-level details were not reviewed for this edition.
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
- Agencies adopting self-managed AI platforms underestimate the ongoing patching and upgrade workload.
- Stakeholders
- IT operations manager
- CISO / vulnerability management
- Platform engineering lead
- Procurement / contract manager
- Discovery questions
- Which OpenShift AI version and update channel are you on?
- What is your patch SLA for Critical advisories on platform software?
- Do you have staff experienced with OpenShift operator upgrades?
- Are your clusters disconnected, requiring image mirroring?
- Value hypothesis
- A defined patch runbook or managed operations can shorten time-to-patch for Critical AI platform advisories.
- Potential engagement
- OpenShift AI upgrade readiness review and patch runbook for one environment.
- Unsupported claims
- That the listed CVEs are exploitable in a given deployment
- That upgrading resolves all AI-specific risks
- Any specific time savings from managed services
Pre-sales engineering
Role takeaway
- Fit
- Applies to self-managed OpenShift AI deployments on the 3.5.x line.
- Architecture and integration
- Operator-managed image updates through OpenShift; mirror registry for disconnected installs; regression tests for serving and RAG.
- Prerequisites
- Current subscription with errata access
- Mirror registry for disconnected clusters
- Test environment matching production
- Constraints
- CVE-level exploitability not assessed here
- Upgrade may require maintenance windows
- Disconnected sites need mirroring before upgrade
- Security
- Prioritize patching multi-tenant or broadly reachable AI gateway and RAG components; document compensating controls if patching is delayed.
- Proof of value
- Upgrade a test cluster to 3.5.2 and pass serving and RAG smoke tests
- Measure time from advisory to production patch
- Confirm image digests match the advisory after upgrade
Delivery
Role takeaway
- Work
- Create and execute an OpenShift AI patch runbook including mirroring, upgrade, testing and rollback.
- Dependencies
- Maintenance window approval
- Mirror registry capacity
- Application owner test sign-off
- Ownership
- IT operations / platform engineering, with vulnerability management tracking.
- Skills and adoption
- Operator upgrade and image mirroring training for operations staff.
- Governance checkpoints
- Change advisory board approval for upgrade
- Post-upgrade security verification
- Monthly patch latency report
- Acceptance criteria
- Proposed: Critical OpenShift AI advisories applied in production within the agency's Critical SLA
- Proposed: rollback tested before production upgrade
- Proposed: serving and RAG smoke tests pass after upgrade
- Risks
- Upgrade breaks custom pipelines or workbenches
- Patch delays due to staffing
- Disconnected sites lag behind connected ones
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?
OpenShift AI is delivered as many operator-managed images, so applying the fix requires an operator-driven upgrade, not a single package update. Disconnected (air-gapped) installs need image mirroring before upgrade.
Governance
Who approves, reviews and stays accountable for outcomes?
AI platforms should be in the agency's vulnerability-management scope with defined patch windows. Upgrade and rollback testing belongs in change control.
Security and privacy
What data, permissions and controls need testing?
The breadth of updated images (gateway, RAG, evaluation, pipelines) means unpatched clusters expose the components that handle prompts, documents and model access.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Teams need OpenShift operator upgrade skills; small SLED IT shops may need managed services or partner support.
Procurement
What should contracts, pricing and exit terms secure?
Subscription and support terms should include errata access and upgrade assistance. Managed-service contracts should specify patch SLAs for AI platform components.
Operating model
Which teams own the service once it runs?
Self-managed AI platforms add a recurring operations burden comparable to other Kubernetes platforms. Budget staff time for it.
Publication history
- 2026-10-29Red Hat · Issue 018 resources
Stable resource ID: rhsa-2026-86891-openshift-ai-352-critical-images-20261021