Lighthouse AdvisorySLED AI Adoption Intelligence

Strategic PartnersIssue 085 records

Red Hat

A Data Science Pipelines isolation and control-coverage day for Red Hat AI. Red Hat’s Nov. 5 CVE-2026-88984 (Important) and CVE-2026-88985 (Moderate) map shared-pipeline RBAC bypass and cross-namespace list disclosure to OpenShift AI odh-ml-pipelines images still Under investigation. Independently, upstreambeat covers Open Data Hub 3.6’s modular llm-d/OGX/AI-gateway packaging, while Checkable AI’s 4 Nov OpenShift AI check still marks tamper-proof AI audit and MCP provenance Not addressed. IBM Think’s 6 Nov Lightwell piece centers Red Hat in AI-assisted open-source backport remediation—supply-chain capacity, not a substitute for waiting on RHOAI errata.

Evidence records
5
Cross-source patterns
2
Evidence classes
2 vendor claim2 independent reporting1 independent research
Outcomes
2 cautionary2 emerging1 mixed
Source freshness
5 new this fortnight
Research completed
2026-11-07

Choose a role to see its takeaway beside every record in the ledger.

Patterns across the evidence

Synthesis · Lighthouse Advisory interpretation

2 patterns, each supported by at least two sources

  1. Multi-tenant OpenShift AI Data Science Pipelines still fails basic shared-object isolation

    CVE-2026-88984 (Important shared-pipeline RBAC bypass) and CVE-2026-88985 (Moderate cross-namespace list disclosure) published together on 2026-11-05 both map to OpenShift AI odh-ml-pipelines packages still Under investigation. Shared DSP control planes need compensating tenancy controls before the next RHSA.

    Operating questionBefore onboarding another agency or research group onto a shared OpenShift AI DSP, have you proven that users without edit roles cannot mutate shared pipelines or read other namespaces’ pipeline records?

    Supporting evidenceCVE-2026-88984: Important Kubeflow Pipelines RBAC bypass on shared pipelines in Red Hat OpenShift AICVE-2026-88985: Moderate Kubeflow Pipelines pagination-token disclosure across namespaces in OpenShift AI

  2. Upstream modular AI serving expands while independent control checks still show audit and MCP gaps

    ODH 3.6 packages llm-d, OGX and AI-gateway as operator modules, while Checkable AI’s 4 Nov OpenShift AI check still marks tamper-proof AI audit, runtime assurance and MCP provenance Not addressed. SLED enablement of new modules should drag compensating controls, not trail them.

    Operating questionFor each new llm-d/OGX/MCP module you plan to enable, which Checkable-style control gaps already have a named compensating owner?

    Supporting evidenceupstreambeat.aiCheckable AI

Evidence ledger

Full record · every source keeps its link and limitations

5 records
  1. Vendor claimCautionaryNew this fortnight

    CVE-2026-88984: Important Kubeflow Pipelines RBAC bypass on shared pipelines in Red Hat OpenShift AI

    On 2026-11-05 Red Hat published CVE-2026-88984 (Important, CVSS 8.1) for Kubeflow Pipelines: in multi-user deployments the API server fails to enforce authorization on shared/global pipelines with an empty namespace, so an authenticated user can modify or delete shared pipeline definitions without required RBAC. Red Hat states the issue affects Red Hat OpenShift AI Data Science Pipelines packages (odh-ml-pipelines-*), with fix_state Under investigation and no product advisory yet. Upstream fixed in Kubeflow Pipelines 2.16.1; Red Hat lists no easy mitigation meeting its criteria, while 2026-11-06 CME guidance recommends restricting API-server access and auditing shared pipeline changes until patched.

    Red Hat Product SecurityUnited States / global product2026-11-05

    Why it matters, evidence and limitations
    Why it matters
    SLED OpenShift AI estates that share Data Science Pipelines across projects or tenants face integrity and availability risk to common training/inference workflows. Multi-tenant university research clusters and state shared-services AI platforms are the primary exposure pattern; single-user DSP deployments are out of scope per Red Hat. Relevance is operational security, not a measured SLED outage.
    Evidence and measured results
    Red Hat CVE details, Important statement naming OpenShift AI shared Kubeflow Pipelines, CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H), package_state Under investigation for five rhoai/odh-ml-pipelines-* images, empty affected_release/advisory list, mitigation text with CME guidance 2026-11-06, upstream references to GHSA-ghgh-57qv-h687 and pipelines 2.16.1.
    Limitations and uncertainty
    Vendor CNA assessment, not an independent exploit write-up. Packages remain Under investigation—no Red Hat errata at inspection time. CME mitigation block is AI-assisted courtesy guidance Red Hat says customers must evaluate themselves. Transferability depends on whether the estate uses multi-user shared pipelines.
    Vendor CVE record: Important severity, RHOAI packages Under investigation, no official mitigation meeting RH criteria Role takeaways & implementation
  2. Vendor claimCautionaryNew this fortnight

    CVE-2026-88985: Moderate Kubeflow Pipelines pagination-token disclosure across namespaces in OpenShift AI

    Also public 2026-11-05, CVE-2026-88985 (Moderate, CVSS 6.5) covers Kubeflow Pipelines list APIs that trust decoded pagination-token fields when building database queries, allowing authenticated users who can list pipelines/runs to read records across namespaces. Red Hat explicitly maps the flaw to OpenShift AI multi-tenant Data Science Pipelines and notes it breaks application-level tenant data boundaries without enabling alteration or full system compromise. Same RHOAI odh-ml-pipelines-* packages show Under investigation; upstream references point to pipelines 2.17.0.

    Red Hat Product SecurityUnited States / global product2026-11-05

    Why it matters, evidence and limitations
    Why it matters
    Reinforces that OpenShift AI shared research or agency MLOps platforms can leak pipeline/run metadata across departmental namespaces even when cluster RBAC looks correct. Especially relevant for higher-ed and state shared AI hubs that co-locate projects on one DSP control plane.
    Evidence and measured results
    Red Hat details/statement naming OpenShift AI, Moderate rating, CVSS 6.5 confidentiality-high, package_state Under investigation for odh-ml-pipelines-* images, references to GHSA-r4mx-2gr2-8277 and pipelines 2.17.0, no RHSA at inspection.
    Limitations and uncertainty
    Vendor assessment; Under investigation without errata. Does not claim cluster-admin escalation. Severity Moderate—pair with Important CVE-2026-88984 rather than treating alone as the headline.
    Vendor CVE record: Moderate information disclosure via crafted pagination tokens on pipeline list APIs Role takeaways & implementation
  3. Independent reportingEmergingNew this fortnight

    Open Data Hub 3.6 turns the next AI serving stack into operator modules (llm-d, OGX, AI gateway)

    Independent coverage dated Nov. 5, 2026 describes Open Data Hub 3.6.0 as reorganizing the upstream stack behind Red Hat’s AI platform around independently managed modules: llm-d routing, asynchronous inference, KV cache, batch-gateway, an OGX module handler, and expanded AI-gateway integration. The GitHub v3.6.0 operator release (published 2026-11-03) lists matching component tags. Signal is platform packaging and lifecycle modularization, not a measured SLED deployment outcome.

    upstreambeat.aiGlobal open-source / applicable to Red Hat OpenShift AI downstream2026-11-05

    Why it matters, evidence and limitations
    Why it matters
    SLED teams tracking OpenShift AI roadmaps should treat ODH 3.6 as the upstream shape of distributed inference and agent/OGX plumbing they will eventually consume. Useful for architecture planning; does not itself prove production readiness or FedRAMP posture.
    Evidence and measured results
    upstreambeat article body on ODH 3.6.0 module manifest; cross-opened GitHub opendatahub-operator release v3.6.0 (2026-11-03) listing llm-d router/async/kv-cache, batch gateway, dashboard, TrustyAI, KServe.
    Limitations and uncertainty
    Trade reporting summarizing upstream release notes—not a benchmark or government evaluation. ODH timing ≠ supported OpenShift AI channel timing. No SLED customer outcomes measured.
    Independent reporting on Open Data Hub 3.6.0 modular llm-d / OGX / AI-gateway packaging Role takeaways & implementation
  4. Independent researchMixedNew this fortnight

    Checkable AI: Red Hat OpenShift AI security controls assessment (42 findings, last checked 4 Nov 2026)

    Checkable AI’s OpenShift AI stack check (last checked 4 November 2026) reports 42 documentation-based control findings across identity, authorisation, runtime, mediation, observability, agentic MLSecOps and governance. Multiple high-interest gaps are marked Not addressed, including agent identity tied to an owner/release record, tamper-proof administrative audit beyond kube-apiserver config changes, runtime assurance/attestation of inference containers, and SBOM/provenance for MCP servers. The research notes AgentRuntime/OpenShell and MCP gateway capabilities as Developer/Technology Preview and states findings reflect public vendor docs, not a live penetration test. Newly relevant alongside the Nov. 5 OpenShift AI pipeline CVE batch because it frames control debt around the same expanding agent/MCP surface.

    Checkable AIGlobal product assessment (US/EU/AU frameworks referenced)2026-11-04

    Why it matters, evidence and limitations
    Why it matters
    Gives SLED architects an independent checklist when justifying OpenShift AI for regulated workloads: which controls are documented GA versus Preview/not addressed. Does not replace agency ATO testing.
    Evidence and measured results
    Page states 42 findings, last checked 4 November 2026; area tallies; detailed Not addressed notes on Administrative Audit (no tamper-proof record; MLflow/OGX logs not tamper-proof), Runtime Assurance, Agent ID, MCP SBOM/provenance; scope covers OpenShift AI 3.5, Red Hat AI Inference, OGX, Connectivity Link MCP gateway.
    Limitations and uncertainty
    Documentation review, not a live deployment test. Last checked 4 Nov—one day before this edition’s pipeline CVE wave, so those CVEs are not integrated into the check. Independent site; verify against current Red Hat release notes before contractual use.
    Independent documentation-based AI Stack Check of OpenShift AI 3.5 / Inference / OGX / MCP gateway controls Role takeaways & implementation
  5. Independent reportingEmergingNew this fortnight

    IBM Think: IBM and Red Hat use Lightwell AI-assisted remediation against open-source vulnerability backlog

    Published 06 November 2026, IBM Think reports that IBM and Red Hat’s Lightwell initiative uses AI plus human engineers to find and fix open-source flaws, citing the October announcement of more than 400 previously unknown Java vulnerabilities remediated, private customer reporting with de-identification, backporting to versions already in use, Clearinghouse priority requests, and Red Hat plans to expand beyond Java/Python toward JavaScript. Red Hat is central as co-operator of Lightwell, not a peripheral mention. This is operational supply-chain remediation capacity, not an OpenShift AI product feature release.

    IBM ThinkGlobal / enterprise open-source supply chain2026-11-06

    Why it matters, evidence and limitations
    Why it matters
    SLED organizations drowning in open-source CVE backlogs—including those running Red Hat AI/OpenShift stacks—may care about backport-oriented remediation and Clearinghouse access. Applicability depends on customer eligibility and package coverage; article does not prove agency onboarding outcomes.
    Evidence and measured results
    IBM Think byline Sascha Brodsky, Published 06 November 2026; descriptions of Lightwell AI+human workflow, 400+ Java fixes announcement reference, Clearinghouse expansion, backporting, private reporting, Red Hat expansion plans to JavaScript.
    Limitations and uncertainty
    Corporate journalism summarizing vendor initiative; quantitative 400+ figure originates in prior IBM/Red Hat announcement, not independently audited here. Broader IBM watsonx content remains out of stream scope—this item is included because Red Hat co-runs Lightwell. No measured SLED deployment metrics.
    Attributed IBM Think article (06 November 2026) on Lightwell AI+human remediation and Clearinghouse access Role takeaways & implementation

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.
Independent research
Research conducted outside the implementing organization.