Red Hat OpenShift AI model gateway injects another tenant's provider API keys when a request names their model (CVE-2026-117574, 9.1); no fix listed

View raw markdownEdit on GitHub ↗

TL;DR

Red Hat's CVE-2026-117574 (published 2026-10-28, public 2026-10-27, reported 2026-06-17): the ai-gateway-payload-processing service in OpenShift AI's model-serving gateway reads a tenant and credential from a model identifier the caller supplies and does not check that the caller may use it, so an authenticated user who names another tenant's model gets that tenant's provider API keys injected into the request and spends their LLM quota. Red Hat labels it Important and scores it 9.1 as CNA, and lists the production image as Affected with no fixed build as of 2026-11-01; until one ships, treat the gateway as shared-credential infrastructure and scope and meter every key it holds.

What happened

The Red Hat CNA record describes the flaw in one paragraph: "An authenticated remote attacker can exploit this vulnerability by submitting a request specifying another tenant's model identifier in the request body or header. Because the service does not verify authorization before retrieving credentials from the shared store, it injects the target tenant's application programming interface (API) keys into the request. This flaw allows an attacker to perform unauthorized requests and consume another tenant's large language model (LLM) resources and quotas." The record's title adds where the identifier comes from: "tenant/credential selection from client-controlled url path with no in-process authorization". CWE-639, authorization bypass through a user-controlled key.

Facts from the record and Red Hat's CVE page, both read 2026-11-01:

  • Timeline. Reported to Red Hat 2026-06-17; made public 2026-10-27 12:42 UTC; CVE record published 2026-10-28 20:02 UTC. Four months between report and disclosure, and no erratum at disclosure.
  • Score. CVSS 3.1 9.1, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L, assigned by Red Hat as CNA. Red Hat's own severity label is Important, not Critical; its statement says the flaw "requires valid user credentials to interact with the model serving gateway, limiting unauthenticated remote exploitation." The GitHub Advisory Database carries the same 9.1 as an unreviewed Critical row (GHSA-4c29-j43w-vg8g, 2026-10-28). This file's severity is critical, following the numeric score the vendor assigned as CNA rather than its qualitative label: the two disagree, the 9.1 is the vendor's own assessment, and the impact is another tenant's provider keys with no fix available.
  • Affected. rhoai/odh-ai-gateway-payload-processing-rhel9 in Red Hat OpenShift AI, fix state "Affected"; rhoai/odh-ai-gateway-payload-processing-e2e-rhel9 "Not affected". No affected or fixed version numbers are given, no workaround is listed, and the record's references are Red Hat's CVE page and Bugzilla 2494861.

Why it is here: a self-hosted AI gateway is the one component that holds every provider key for every team behind it, which is why the corpus already tracks gateway flaws in LiteLLM and OmniRoute. OpenShift AI's model-as-a-service gateway is the same shape in an enterprise wrapper: tenants share a credential store, and the lookup key was the caller's to choose.

Am I affected?

  • You run Red Hat OpenShift AI with the model-serving gateway (the odh-ai-gateway-payload-processing image) in front of more than one tenant, team or project, and provider credentials are stored per tenant in the gateway.
  • Any user who can authenticate to the gateway is in scope as an attacker. Check provider-side usage logs per key for requests whose model, tenant or source does not match the key's owner.
  • Single-tenant deployments where every caller may already use every key are exposed only to the extent your billing attribution matters.

If you are affected

  1. Watch Red Hat's CVE page for the erratum; the state was "Affected, no fix" on 2026-11-01.
  2. Until then, limit who can reach the gateway, set per-key spend limits and alerts at each provider, and give each tenant keys you can revoke independently.
  3. If provider usage shows cross-tenant requests, rotate the affected tenant's provider keys at the issuer and follow rotating cloud credentials.

Prevention

  • Keys that a gateway holds for others should be short-lived and scoped, with provider-side limits, so a lookup bug costs one tenant's quota rather than the organisation's. See credential hygiene.
  • Prefer gateways that bind the credential to the authenticated identity server-side and never accept a tenant or credential selector from the request.

Sources

  • CVE Services — CVE-2026-117574 — queried 2026-11-01: Red Hat CNA, published 2026-10-28 20:02 UTC, datePublic 2026-10-27, the description and title quoted above, CVSS 3.1 9.1 with vector, the two affected entries with fix states, timeline entries "Reported to Red Hat" (2026-06-17) and "Made public", references.
  • Red Hat Customer Portal — CVE-2026-117574 — fetched 2026-11-01 (the page redirects; the security-data API at access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-117574.json returned the record): public date 2026-10-27, the Bugzilla title, the two package states, the Important statement quoted above.
  • GitHub Advisory Database — GHSA-4c29-j43w-vg8g — fetched 2026-11-01: unreviewed, Critical 9.1 with the same vector, published 2026-10-28, CWE-639, references to the Red Hat page and Bugzilla 2494861. Single source for the flaw: the vendor, as CNA.