Strategic PartnersIssue 033 records
Red Hat
A quiet weekend for Red Hat AI news, so this edition covers operational status rather than announcements. Red Hat's own records show that two Important vLLM flaws fixed upstream in vLLM 0.32.0 remain listed as Affected, and five lower-severity ones as Fix deferred, across OpenShift AI, RHEL AI and AI Inference Server. Red Hat says text-only, gateway-protected deployments carry little exposure, and recommends network and image mitigations. A Red Hat field team posted a setup guide for an unreleased operator that adds token metering, budgets and GPU reservations to OpenShift AI's model service; by its own account the guide has not been tested end to end. An independent analysis of llm-d 1.0, the serving layer Red Hat ships, finds useful tenant-priority controls but unfinished request failover and cost-saving claims that rest on narrow assumptions. No new US SLED deployment was found.
- Evidence records
- 3
- Cross-source patterns
- 1
- Evidence classes
- 2 vendor claim1 independent reporting
- Outcomes
- 1 cautionary1 emerging1 mixed
- Source freshness
- 3 new this fortnight
- Research completed
- 2026-11-02
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Evidence ledger
Full record · every source keeps its link and limitations
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
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, evidence and limitations
- 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.
Red Hat AI Americas field build: platform-billing-operator adds token metering, prepaid wallets, budgets and GPU reservations to OpenShift AI Models-as-a-Service, with an untested setup guide
Vendor field build: a Red Hat-copyrighted, Apache-2.0 Kubernetes operator that adds billing, metering and FinOps to OpenShift AI Models-as-a-Service. It compiles billing Plans into Kuadrant enforcement policies, meters per-request token usage, manages prepaid wallets, supports Stripe, applies budget actions (Notify, Throttle, Freeze) and offers Guaranteed or Preemptible GPU reservations through Kueue. The guide added on Oct. 30, 2026 calls itself a first draft that nobody has followed end to end on a fresh cluster, marks several OpenShift steps unverified, and lists a tested stack of Connectivity Link 1.4.2, OpenShift AI 3.4.2 (vLLM 0.13.0+rhai19) and Service Mesh 3.1.0. It warns that some OpenShift AI 3.x versions ship a conflicting Authorino version. The repository has no releases. The OperatorHub community bundle (v0.0.1, alpha) is not from a verified publisher, and Artifact Hub's Oct. 31 image scan reports 37 high, 71 medium, 19 low and 4 unknown findings (no critical).
Why it matters, evidence and limitations
- Why it matters
- State IT shared-services agencies, county consolidated IT and university research-computing centers increasingly run one GPU pool for many departments or labs. Chargeback, quotas and reserved capacity are what turn that pool into a governed service. This build shows one Red Hat-aligned way to do it on OpenShift AI. It is a prototype, and public-sector chargeback usually runs through internal journal entries rather than card payments, so the Stripe path has limited relevance.
- Evidence and measured results
- Read the setup guide and README in the repository, checked the GitHub repository metadata and commit history (guide added Oct. 30, 2026 15:42 UTC; zero stars; no releases), and pulled the Artifact Hub package record (version 0.0.1, alpha channel, unverified publisher, security scan summary). Also read the upstreambeat.ai Oct. 30 write-up, which agrees the project is a field reference implementation rather than a supported product. No usage, cost or accuracy results are published.
- Limitations and uncertainty
- Prototype with no releases; setup guide untested end to end by its own account; Artifact Hub scan findings on the alpha community bundle; no published outcomes. Committed the morning of Oct. 30, before the 10-30 run started, but not in the archive.
Independent analysis of llm-d 1.0, the distributed inference layer Red Hat ships in Red Hat AI Inference: new tenant-priority and upgrade controls, but request failover unfinished and cost claims narrower than headlines
Independent reporting: llm-d 1.0 (Oct. 20, 2026) adds stable interfaces, tenant and priority queues that can hold or reject lower-priority requests, coordinated prefill/decode upgrades and a hot-standby router. Red Hat distributes it through Red Hat AI Inference on OpenShift AI and other Kubernetes environments. The article finds that priority policies must be enabled (defaults approximate first-come-first-served), that the project tracker leaves request failover and migration unchecked, that release notes say not all planned work was accomplished, and that documents disagree on active-active router support. Upgrades require LeaderWorkerSet 0.11.1 or newer and remove a legacy API group. Cited efficiency results (IBM: 544 H100 GPUs, 85.2% of input tokens from cache, 6.05 million tokens per minute at 2,500 agents) predate 1.0 and do not isolate its benefit. Cost claims of five to ten times lower than API pricing use cloud rental rates and exclude storage, egress, engineering, support and taxes.
Why it matters, evidence and limitations
- Why it matters
- State and campus teams weighing self-hosted open models against managed APIs often see llm-d cost headlines in Red Hat material. This analysis shows what those figures do and do not establish, and that multi-tenant priority controls require explicit policy choices, which matters when agencies or labs share one serving fleet. No SLED deployment is cited.
- Evidence and measured results
- Read the full article and compared it with the llm-d project's own v1.0 blog and Red Hat's Oct. 20 CTO blog. The cost framing differs by source for what appears to be the same IBM deployment: Red Hat's blog says five to ten times lower than proprietary options, the llm-d blog says around 11.5 times lower, and Magica stresses the rental-rate basis and excluded costs. The article's tracker and release-note observations were not checked independently against the llm-d repositories.
- Limitations and uncertainty
- Secondary reporting; tracker and release-note claims not independently verified here; underlying performance and cost figures are company-reported; non-SLED deployments. Published before the last run; included because it is the only independent scrutiny of the Red Hat-distributed serving layer found, it is not in the archive, and its page was modified Oct. 31 (substance of the change not determinable).
How to read this edition
Source findings, measured results and limitations come from the cited publications. Patterns, operating questions, role takeaways and implementation considerations are Lighthouse Advisory interpretation, stated as questions to validate locally rather than guaranteed outcomes. Vendor and operator claims are labeled as claims. Full research method.
- Vendor claim
- A supplier-provided assertion that has not been upgraded to independent evidence.
- Independent reporting
- Independent reporting with attributable sources but without a formal evaluation design.