From the Red Hat edition of October 31, 2026
Red Hat triage of the vLLM 0.32.0 security advisories: two Important flaws listed as Affected and five lower-severity flaws as Fix deferred across OpenShift AI, RHEL AI and AI Inference Server
Red Hat Product Security · AI model serving platforms used across public and private sectors (Red Hat AI Inference Server 3, RHEL AI 3, Red Hat OpenShift AI) · Global product advisory; applies to any US SLED deployment of these products
- Publisher
- Red Hat Customer Portal (CVE database)
- Original publication
- Red Hat CVE records made public Oct. 26, 2026; upstream GitHub advisories published Oct. 28, 2026; fix status observed Oct. 31, 2026
- Source retrieved
- 2026-11-01
- Event date
- 2026-10-28
What happened
Vendor record: Red Hat's security data, checked Oct. 31, 2026, covers seven of the eight vLLM advisories fixed upstream in vLLM 0.32.0 (CVE-2026-115911 to -115918; Red Hat's data API returned no record for CVE-2026-115913). Two are rated Important: CVE-2026-115915 (CVSS 8.1, draft; image bytes reach Pillow without a format allowlist, so an EPS payload can reach a vulnerable Ghostscript) and CVE-2026-115912 (CVSS 7.5; forged shared-memory handles reach pickle.loads in scale-out multimodal caching). Both are listed as Affected, with no fix yet, for AI Inference Server 3, RHEL AI 3 and most OpenShift AI serving images; two AI Inference Server images (rhaii/vllm-neuron-rhel9 and rhaii/vllm-tpu-rhel9) are marked Will not fix for CVE-2026-115915. The five Moderate or Low flaws (denial of service via unbounded or untrusted chat templates, crafted OCR images and out-of-bounds prompt token IDs, plus a Low-rated CORS information disclosure) are marked Fix deferred for all three products. Red Hat says text-only models, or endpoints behind authenticated network boundaries, are not exposed to CVE-2026-115915, and recommends NetworkPolicy, removing Ghostscript and rejecting EPS at the gateway.
Why it matters
Agencies, universities and research centers that self-host models on OpenShift AI, RHEL AI or AI Inference Server for data-residency reasons own the patch gap themselves. Multimodal workloads such as document intake, permit or claims image processing and research vision models are the exposed configuration. Text-only, gateway-protected deployments carry much less exposure according to Red Hat. This is a status signal for security and platform teams, not evidence of exploitation.
Evidence and measured results
Read the CVE-2026-115915 and CVE-2026-115912 pages and pulled Red Hat's security data records for all eight CVE numbers (public dates, severity, package fix states, statements, mitigations). Cross-checked against AI Security Wire's Oct. 29 analysis, which reports that GitHub published the eight advisories Oct. 28, that NVD's own scores are higher for CVE-2026-115912 (8.8) and CVE-2026-115915 (9.8), and that none appeared in the CISA KEV feed as of Oct. 29. Fix states are a point-in-time observation and may change at any time.
Limitations and uncertainty
Vendor self-assessment; Red Hat CVSS for CVE-2026-115915 is marked draft. Fix states were observed once, on Oct. 31, 2026, and may change. Red Hat had no record for CVE-2026-115913 at retrieval. No exploitation evidence was found in the sources read; the reporters describe lab reproductions. Older than the last run by publication date; included because the downstream fix status, five days after disclosure, is current information not previously covered.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-01; 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 and campuses self-hosting models on Red Hat AI products face two Important vLLM flaws with no downstream fix yet and five deferred fixes.
- Stakeholders
- Agency or campus CISO
- AI platform owner
- Research computing director
- Vendor management / contracts office
- Discovery questions
- Which of your served models accept image or document input?
- Are inference endpoints reachable only through an authenticating gateway?
- Do you run scale-out serving with shared-memory multimodal caching?
- How do you record risk acceptance for vendor Fix deferred items?
- Value hypothesis
- A focused configuration review can show whether a deployment is exposed and apply documented mitigations until fixed images ship (interpretation).
- Potential engagement
- Two- to three-day exposure review and mitigation of existing Red Hat AI serving deployments, with a written CVE-by-CVE status record.
- Unsupported claims
- That Red Hat AI products are already patched for these CVEs
- That any deployment has been exploited
- That text-only deployments are free of all eight flaws
Pre-sales engineering
Role takeaway
- Fit
- Applies to any deployment of AI Inference Server 3, RHEL AI 3 or OpenShift AI model serving that bundles vLLM below 0.32.0.
- Architecture and integration
- Mitigations sit at the network and gateway layer (NetworkPolicy, authenticating gateway, content-type filtering) and in the image build (removing Ghostscript).
- Prerequisites
- Inventory of serving runtimes and image tags
- Knowledge of which models are multimodal
- Access to build or rebuild serving images
- Constraints
- Downstream fixes not yet available for the Important CVEs as of Oct. 31, 2026
- Image rebuilds and network changes require pod restarts
- CVE-2026-115913 had no Red Hat record at retrieval
- Security
- Red Hat scores CVE-2026-115915 at 8.1 (draft) and CVE-2026-115912 at 7.5; NVD's primary scores are higher (9.8 and 8.8) according to AI Security Wire.
- Proof of value
- Send a request without credentials to each endpoint and confirm the gateway rejects it
- Submit an EPS-labelled image in a test namespace and confirm it is rejected before vLLM
- Confirm Ghostscript is absent from serving images
Delivery
Role takeaway
- Work
- Inventory deployed Red Hat AI serving images, map each to Red Hat fix states, apply compensating controls and track fixed builds.
- Dependencies
- Red Hat fixed images
- Gateway or service-mesh configuration
- Security office approval for risk acceptance
- Ownership
- AI platform team, with the agency or campus security office owning risk acceptance.
- Skills and adoption
- Platform engineers need to read Red Hat package-level fix states and maintain NetworkPolicy; a short runbook helps.
- Governance checkpoints
- Documented exception for each Fix deferred CVE
- Security sign-off on compensating controls
- Weekly re-check of Red Hat records until fixed
- Acceptance criteria
- Proposed: 100% of serving endpoints reject unauthenticated requests in negative tests
- Proposed: fixed images deployed within an agreed number of days of Red Hat release
- Proposed: no serving image contains Ghostscript
- Risks
- Fix states change without notice
- Mitigations break legitimate image formats
- Shadow deployments missing from the inventory
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?
Exposure depends on configuration: multimodal image input, shared-memory multimodal caching in scale-out serving, and whether inference endpoints sit behind an authenticating gateway. Teams should inventory which serving runtimes and images (KServe, llm-d KV cache, vLLM CUDA/ROCm images) are deployed and which accept image input.
Governance
Who approves, reviews and stays accountable for outcomes?
A Fix deferred status shifts risk acceptance to the customer. Agencies need a documented exception or compensating control for each deferred CVE, plus a check that the vendor's statement matches their real configuration.
Security and privacy
What data, permissions and controls need testing?
Code execution inside a model-serving container could expose prompts, documents and model artifacts processed by that replica. Upstream analysis notes vLLM does no authentication unless an API key is set, so exposed endpoints are reachable by any client that can connect.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Requires platform engineers who can read package-level fix states, build or patch container images and write Kubernetes NetworkPolicy. Smaller SLED IT shops may need partner or Red Hat support to do this quickly.
Procurement
What should contracts, pricing and exit terms secure?
Support agreements for self-hosted AI platforms should state patch timelines for Important flaws in bundled open source engines, and how deferred fixes are communicated. The gap between upstream fix (vLLM 0.32.0) and downstream product fix is a contract question.
Operating model
Which teams own the service once it runs?
Self-hosting AI moves vulnerability management for the inference engine to the agency or campus. That needs a standing process to track upstream vLLM releases against the downstream product cadence.
Publication history
- 2026-10-31Red Hat · Issue 033 resources
Stable resource ID: redhat-vllm-032-advisories-openshift-ai-rhel-ai-inference-server-fix-status-20261026