EUVD-2026-55808
GHSA-6vf6-rmwh-84qg
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
PR:L for the required in-cluster pod foothold, AC:L because forging two static headers is trivial, and S:C because the header-trust bypass breaks isolation into other tenants' namespaces with full C/I/A impact.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
2DescriptionCVE.org
A flaw was found in the MaaS API. This vulnerability allows any pod within the cluster to bypass the Kuadrant AuthPolicy gateway by forging HTTP headers, specifically X-MaaS-Username and X-MaaS-Group, which are trusted verbatim. This lack of first-party authentication enables an attacker to gain unauthorized access and escalate privileges. The concrete consequences include the ability to mint Kubernetes ServiceAccount tokens in other tenants' namespaces, revoke API keys, and exfiltrate sensitive model access configuration.
Articles & Coverage 2
AnalysisAI
Authentication bypass in the Models-as-a-Service (MaaS) API component of Red Hat OpenShift AI (RHOAI) lets any pod already running in the cluster impersonate arbitrary users by forging the X-MaaS-Username and X-MaaS-Group HTTP headers, which the service trusts without independent verification. Because the MaaS API performs no first-party authentication and defers entirely to a Kuadrant AuthPolicy gateway that can be circumvented, a low-privileged workload can mint Kubernetes ServiceAccount tokens in other tenants' namespaces, revoke API keys, and exfiltrate model-access configuration - a full cross-tenant privilege escalation. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV, but the 9.9 CVSS reflects near-total impact.
Technical ContextAI
The affected component is the MaaS (Models-as-a-Service) API within Red Hat OpenShift AI, which fronts model-serving endpoints in a multi-tenant Kubernetes/OpenShift environment. Authentication is intended to be enforced at the edge by Kuadrant's AuthPolicy (an Envoy/Gateway-API-based external authorization layer), which after validating a caller injects identity context downstream as HTTP headers. The flaw is a classic CWE-290 (Authentication Bypass by Spoofing): the MaaS API trusts the X-MaaS-Username and X-MaaS-Group headers verbatim as identity assertions, without re-verifying that they originated from the trusted gateway rather than from an arbitrary in-cluster client. Because pod-to-pod traffic inside the cluster can reach the service directly (bypassing the gateway) and set those headers freely, the identity model collapses. The downstream privilege - minting ServiceAccount tokens via the Kubernetes TokenRequest API in other namespaces - indicates the MaaS backend holds broad, cross-tenant Kubernetes RBAC that it exposes on behalf of the (spoofable) header identity.
RemediationAI
Apply the Red Hat-provided fix once the erratum is published; the reference https://access.redhat.com/security/cve/CVE-2026-14450 is the canonical source for the fixed RHOAI/MaaS component version, which is not enumerated in the supplied data (Patch available per vendor advisory; exact fixed version not independently confirmed here). The durable fix is for the MaaS API to stop trusting X-MaaS-Username and X-MaaS-Group verbatim - the identity must be re-derived from a cryptographically verifiable signal (a signed token from Kuadrant, or mTLS-authenticated gateway identity). As compensating controls until patched: enforce a Kubernetes NetworkPolicy so that only the Kuadrant gateway pods can reach the MaaS API service, preventing direct pod-to-service header forgery (side effect: any legitimate direct callers break and must route through the gateway); strip or overwrite the X-MaaS-Username and X-MaaS-Group headers at the gateway/Envoy layer so client-supplied values are never honored (side effect: none if the gateway is the sole legitimate injector); and tighten the RBAC granted to the MaaS backend ServiceAccount to remove cross-namespace TokenRequest and key-management permissions where feasible (side effect: may disable legitimate cross-tenant provisioning features). Also rotate any API keys and audit for unexpected ServiceAccount token issuance across tenant namespaces.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same weakness CWE-290 – Authentication Bypass by Spoofing
View allSame technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today