Red Hat AI Inference 3.5.3 ships Critical fixes for 60 CVEs, including vLLM code-execution and SSRF flaws, while 'fast' images remain Affected

Red Hat Product Security · AI inference software used by public and private sectors (Red Hat AI Inference Server / vLLM) · Global product advisory; applies to any US SLED deployment of Red Hat AI Inference 3.5

Red Hat

Publisher: Red Hat Customer Portal (errata)
Original publication: RHSA-2026:94702, 94709, 94717, 94721 and 94738 issued Nov. 3, 2026; underlying CVEs public Aug.-Oct. 2026
Source retrieved: 2026-11-05
Event date: 2026-11-03

Read original source

What happened

Vendor record: on Nov. 3, 2026 Red Hat issued five Critical advisories for Red Hat AI Inference 3.5.3 covering CUDA, CPU, ROCm, Spyre and Gaudi (Tech Preview) builds, each listing the same 60 CVEs. The vLLM fixes include remote code execution through a crafted code_revision when trust-remote-code is enabled (CVE-2026-114053), SSRF through the X-Request-Id header (CVE-2026-116176), unsafe image-format handling (CVE-2026-115915) and denial-of-service flaws. Red Hat's security data, checked the evening of Nov. 4, still lists the rhaii-fast vLLM images as Affected, and marks some older rhaiis images 'Will not fix' for two DoS flaws. An independent advisory entry confirms the ReDoS gap stayed open in one backend after an earlier fix. Interpretation: inference endpoints exposed to campus or agency users should move to 3.5.3 now.

Why it matters

State agencies, universities and research computing centers that self-host open models on Red Hat AI Inference or vLLM behind chat assistants, document tools or student-facing services face network-reachable flaws, some unauthenticated. Self-hosting is often chosen for data residency, so patch ownership sits with the agency or campus, not a SaaS provider.

Evidence and measured results

Read RHSA-2026:94738 and RHSA-2026:94702 in full and checked titles and CVE counts for 94709, 94717 and 94721; Red Hat security data JSON for CVE-2026-114053, CVE-2026-116176, CVE-2026-73556 and CVE-2026-93592; GitLab advisory entry for CVE-2026-73556.

Limitations and uncertainty

Vendor advisories are terse; no exploitation evidence found (no vLLM entries in CISA KEV as checked Nov. 4); package states observed once; severity differs between Red Hat and third-party scoring.

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: Self-hosted AI inference endpoints carry network-reachable vLLM flaws that need prompt, owned patching.
Stakeholders: Agency or campus CISO
AI platform owner
Research computing director
Discovery questions: Which Red Hat AI Inference channel and version do you run?
Are any inference endpoints reachable without authentication?
Who owns patching for model-serving images?
Value hypothesis: A short runtime review can reduce exposure windows on self-hosted AI; benefit is unquantified.
Potential engagement: Bounded AI inference patch and configuration health check for one environment.
Unsupported claims: Active exploitation of these vLLM flaws
Any SLED customer incident
Guaranteed risk reduction or savings

Pre-sales engineering

Role takeaway

Fit: Sites serving models with Red Hat AI Inference 3.5 on CPU, CUDA, ROCm, Spyre or Gaudi.
Architecture and integration: Replace serving images with 3.5.3 digests in OpenShift or RHEL deployments; review gateway authentication in front of vLLM endpoints.
Prerequisites: Image inventory by channel
Digest-pinned manifests
Test environment for model regression
Constraints: rhaii-fast images still Affected
Some older rhaiis images marked Will not fix
Gaudi build is Tech Preview
Security: Disable trust-remote-code unless required; restrict media input types; authenticate inference endpoints.
Proof of value: Verify deployed digests match RHSA-2026:94738 or companion builds
Confirm trust-remote-code disabled
Re-check package_state for fast-channel fixes

Delivery

Role takeaway

Work: Roll inference workloads to 3.5.3, validate, and document exceptions for unfixed channels.
Dependencies: Change window
Model regression tests
Vendor fixes for fast channel
Ownership: AI platform team with security operations oversight.
Skills and adoption: Train platform staff on Red Hat AI image channels and security data API checks.
Governance checkpoints: Critical-patch window review
Exception approval for Affected channels
Post-deployment verification
Acceptance criteria: Proposed: all production endpoints on fixed digests
Proposed: zero unauthenticated inference endpoints
Proposed: exceptions closed within 30 days
Risks: Model behavior regression after upgrade
Overlooked fast-channel deployments
Assuming default config is in use

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?

Fixes reach production only when serving deployments are redeployed on 3.5.3 images. Sites on the 'fast' channel or older rhaiis images need a separate plan, since those are still Affected or marked Will not fix. Trust-remote-code and multimodal endpoints widen exposure.

Governance

Who approves, reviews and stays accountable for outcomes?

Five Critical advisories on one day give an auditable patch trigger. Exceptions for still-Affected channels should be documented and time-boxed.

Security and privacy

What data, permissions and controls need testing?

Red Hat describes possible code execution, SSRF-driven information disclosure and denial of service. In public-sector inference services, that could expose prompts, retrieved documents or internal network endpoints. Red Hat notes trust-remote-code is disabled by default, which lowers but does not remove risk.

Accessibility and workforce

Who is affected, and what skills or accommodations follow?

Requires staff who can track AI runtime channels and redeploy model servers. Smaller campus or county teams may need partner support.

Procurement

What should contracts, pricing and exit terms secure?

Contracts for self-hosted AI should spell out patch SLAs per image channel and how 'Will not fix' decisions are communicated.

Operating model

Which teams own the service once it runs?

Moves AI runtime patching into routine vulnerability management with named owners per image channel.

Publication history

2026-11-04Red Hat · Issue 062 resources

Read preserved resource versions (JSON)

Stable resource ID: redhat-ai-inference-353-vllm-60-cve-batch-20261103