The Pulse
Red Hat AI Gateway Flaw Can Inject Another Tenant’s API Keys
An authorization flaw in Red Hat OpenShift AI’s model-serving gateway can let an authenticated user trigger requests with another tenant’s provider credentials. Red Hat rates the vulnerability Important and gives it a preliminary CVSS 3.1 s
AI.info Team · Written with AI · fact-checked ·
A model name crosses the tenant boundary
Glexia’s vulnerability timeline records a Red Hat source event marked “Made public” on October 27, 2026; the CVE record was published on October 28. The flaw affects ai-gateway-payload-processing, a component used in multi-tenant Red Hat OpenShift AI environments. A user with valid credentials can submit a request that names another tenant’s model in its body or header. The component retrieves credentials from a shared store without checking that the requester may use that model, then injects the other tenant’s API keys into the request.
The advisory says the resulting requests can use another project’s large language model resources and quota. That is not the same as a demonstrated attack that lets someone simply read or download stored keys: Red Hat describes credentials being injected into gateway requests, enabling unauthorized use of a provider account. The flaw therefore puts both service access and the affected tenant’s consumption limits at risk.
Red Hat rates it Important, with a 9.1 score
Red Hat labels the vulnerability “Important,” while assigning it a preliminary CVSS 3.1 base score of 9.1. The score reflects network reachability, low attack complexity, low privileges required and high confidentiality impact; Red Hat cautions that the metrics remain subject to review. Its own explanation says the issue requires valid user credentials to interact with the model-serving gateway, so the advisory does not describe an unauthenticated attacker exploiting it from nowhere.
The difference between the rating and the numerical score matters for readers triaging alerts. Red Hat says scores can vary by vendor because the product version, build and platform affect how a flaw applies. The advisory’s narrative rating is “Important”; it should not be silently replaced with a different vendor’s severity label.
The selector changed, but the authorization gap remained
Red Hat’s technical explanation records a change to the vulnerable mechanism. The earlier path-based lookup was removed, but the revised implementation still chooses credentials using a model name supplied by the client, either in the request body or the x-gateway-model-name header. Red Hat’s CVSS v3 score explanation states:
“The path-based lookup (segments/) originally described was removed in commit bac9fb5, but credential selection now resolves purely from the client-supplied body model field / x-gateway-model-name header, via a flat cluster-wide model-name map with still no in-process identity check.”
The advisory says the gateway’s authorization and subscription checks derive model identity from the URL path, while credential injection uses the separate body or header value. That mismatch allows a caller who is authenticated for their own tenant’s route to specify a different tenant’s model name. Red Hat says the score was re-evaluated on October 27 after confirming the changed mechanism remained vulnerable.
What OpenShift AI operators should take from the notice
The disclosed weakness concerns cross-tenant authorization inside the model-serving gateway, not a general flaw in every Red Hat AI product. Red Hat’s statement specifically describes a multi-tenant OpenShift AI environment and says the attacker needs valid credentials for the gateway. The advisory identifies the issue as CWE-639, an authorization bypass through a user-controlled key.
For operators, the practical concern is whether a user authorized for one tenant can cause requests to use another tenant’s provider credentials. Teams should consult the live CVE entry for affected-product and remediation updates rather than infer that the component’s prior path-based behavior describes its current state.