Database/AI/ML frameworks & serving
OpenShift AI MaaS API: any in-cluster pod forges identity headers to impersonate tenants
Impact
The MaaS API trusts the X-MaaS-Username and X-MaaS-Group HTTP headers verbatim and performs no first-party authentication of its own, so anything that can reach the service directly bypasses the Kuadrant AuthPolicy gateway that is supposed to be the only auth boundary. Red Hat states the concrete consequences: minting Kubernetes ServiceAccount tokens in other tenants' namespaces, revoking other tenants' API keys, and exfiltrating model access configuration. On a shared GPU cluster this is cross-tenant compromise reachable from any workload pod - one tenant's training job can take over the model-serving control plane and pivot into other namespaces. The CVSS scope change to 9.9 reflects exactly that escape from the pod into cluster-wide credentials.
Who can reach it
Any pod inside the cluster that can open a network connection to the MaaS API service. No credentials are needed - the forged headers are the whole attack.
What to do
Apply the Red Hat errata for OpenShift AI 3.4 (RHSA-2026:53262, RHSA-2026:60520); the operator rolls the affected deployments, so the cost is a restart of the MaaS API pods rather than a node drain. Until patched, restrict pod-to-service reachability with a NetworkPolicy so only the Kuadrant gateway can talk to the MaaS API, and treat any ServiceAccount token issued through it during the exposure window as compromised.
References
Related entries
- NVIDIA OpenShell: incomplete input denylist in the sandbox provisioning API allows code executionCVE-2026-65083 · NVIDIA OpenShell (sandbox provisioning API)Critical
- NVIDIA OpenShell: sandbox escape lets confined code run outside the sandboxCVE-2026-65093 · NVIDIA OpenShell (agent sandbox confinement)Critical
- scikit-learn / joblib: `joblib.load()` executes commands from an untrusted file via `__reduce__`CVE-2020-13092 · scikit-learn / joblibCritical
- PyTorch (`torch.jit.annotations.parse_type_line`): Arbitrary code execution via unsafe `eval` in TorchScript typeCVE-2022-45907 · PyTorch (`torch.jit.annotations.parse_type_line`)Critical
- MLflow: Path traversal prior to 2.3.1CVE-2023-2780 · MLflowCritical
- LangChain (`LLMMathChain`): Prompt injectionCVE-2023-29374 · LangChain (`LLMMathChain`)Critical
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.