al-ice.ai

Your Tenant ID, Their API Key: RHOAI Gateway Flaw Let One Tenant Spend Another LLM Quota

AI Vulnerabilities & CVEs by al-ice.ai Editorial

NVD published CVE-2026-117574 on 28 October 2026 with a CVSS 3.1 score of 9.1, and the shape of the flaw should worry anyone running multi-tenant LLM infrastructure. In Red Hat OpenShift AI ai-gateway-payload-processing, an authenticated remote attacker could submit a request specifying another tenant model identifier in the request body or header. Because the service retrieved credentials from the shared store without verifying authorization, it injected the target tenant application programming interface keys into the request — letting the caller make unauthorized requests and consume another tenant large language model resources and quotas. Red Hat bug tracker titles the issue even more bluntly: tenant and credential selection from a client-controlled URL path with no in-process authorization (CWE-639, authorization bypass through user-controlled key). Scope changes under CVSS (S:C) because the vulnerable component and the impacted component are different tenants. We read the NVD JSON record and the Red Hat Security Data record first-hand.

The gateway knew whose key it was handing out — and handed it out anyway

Strip away the enterprise packaging and this is the oldest multi-tenancy failure there is: the request carries a tenant selector, the server trusts it, and the credential store obeys. The attacker needs valid credentials of their own (PR:L) and no user interaction, over the network — the standard position of any legitimate tenant in a shared AI platform, which is precisely what makes the 9.1 land. The compromised asset is not the attacker tenant, it is the victim bill: API keys that unlock a third-party model provider meter, and quotas that gate expensive inference. In a platform where tenants bring their own provider keys, cross-tenant key injection converts one customer subscription into every customer compute budget.

The remediation status is the uncomfortable part. Red Hat package state, as retrieved, lists rhoai/odh-ai-gateway-payload-processing-rhel9 as Affected with no fixed release recorded and no mitigation published; only the end-to-end test package is marked not affected. In other words, at the time of this briefing the vendor record describes a known-affected gateway component with no shipped fix and no workaround — the exact window in which tenant isolation cannot simply be assumed. Teams should read that status directly rather than infer patch availability from the CVE existence.

This is the enterprise twin of a pattern this site keeps documenting in the open-source gateway world. The Check Point LiteLLM chains showed what happens when gateway admin surfaces skip authorization — file read, admin takeover, RCE. The LiteLLM master-key chain traced a poisoning back to one unscoped credential. Here the credential store itself is intact and the check in front of it is missing: no stolen secret required, just a tenant identifier that was never yours. Gateways concentrate every tenant keys in one process; any selector the client controls and the server does not authorize is a cross-tenant read waiting for a CVE number.

What to do

  • Check your RHOAI gateway version against the Red Hat CVE record now. odh-ai-gateway-payload-processing-rhel9 is listed affected with no fixed release; track the record for the fix rather than assuming a quiet backport, and restrict gateway access to trusted tenants until it lands.
  • Bind credential selection to the authenticated session, never to request data. Tenant identifiers in bodies, headers, or URL paths are display hints, not authorization decisions. Resolve the tenant server-side from authentication, then authorize the model access explicitly before touching the shared credential store.
  • Alert on cross-tenant key usage, not just failed auth. This attack authenticates successfully — as the attacker — so login monitoring misses it. Log which tenant key material serves which authenticated principal on every request, and page on any mismatch.
  • Scope provider keys and quotas per tenant with hard ceilings. Per-tenant keys with independent rate limits and spend alerts convert a key-injection flaw from an open tab into a bounded incident. A single shared pool with per-tenant honor-system selectors is the architecture this CVE punishes.
  • Inventory every client-controlled selector in your own gateways. Model IDs, tenant slugs, workspace names, project paths — any value the client supplies that chooses whose credentials or quota a request spends needs an authorization check in-process, before the store lookup, not after.

Our verification was read-only: we read the NVD JSON record for CVE-2026-117574 first-hand (28 October 2026 publication, 9.1 CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C, CWE-639, description of cross-tenant model-identifier submission with unauthorized credential retrieval and quota consumption) and the Red Hat Security Data record first-hand (bug title on client-controlled tenant/credential selection with no in-process authorization, odh-ai-gateway-payload-processing-rhel9 affected, no fixed release or mitigation listed). The related LiteLLM gateway history is from this site own prior briefings. We accessed no Red Hat system, held no tenant credential, and contacted no party.

Sources: