Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-10T21:17:19.487Z",
  "pubdate": "2026-08-10T21:17:19.487Z",
  "executiveSummary": "A critical security flaw has been identified in the MaaS API that permits arbitrary pods within a Kubernetes cluster to completely bypass the Kuadrant AuthPolicy gateway mechanism. The vulnerability stems from the blind trust placed in specific incoming HTTP headers, namely X-MaaS-Username and X-MaaS-Group, without adequate cryptographic verification or first-party authentication enforcement.\nThis absence of robust identity validation allows malicious actors or compromised workloads to successfully execute privilege escalation attacks and achieve unauthorized cross-tenant access. An attacker operating an intra-cluster pod can forge these trusted routing headers to impersonate administrative entities or users belonging to other tenants.\nThe resulting impact is severe, encompassing the ability to maliciously mint Kubernetes ServiceAccount tokens across foreign namespaces, systematically revoke active API keys, and exfiltrate highly sensitive model access configurations and internal infrastructure secrets.\nSuccessful exploitation requires cluster-level network access to route requests through the MaaS API gateway, coupled with the capability to deploy or compromise a containerized workload capable of manipulating outbound HTTP headers. Given the breadth of potential damage to multi-tenant isolation, this vulnerability presents an extreme risk to cloud-native deployments utilizing the affected components.",
  "technicalDetails": "The root cause of this vulnerability lies in the architectural deficiency of the MaaS API authentication pipeline, specifically within the handling of upstream identity propagation behind the Kuadrant AuthPolicy gateway. Instead of validating a cryptographically signed JSON Web Token (JWT) or mutually authenticated mTLS identity, the application logic exhibits insecure design by blindly trusting proxy-injected headers supplied in incoming HTTP requests.\nThe vulnerable components are the MaaS API endpoint handlers and the associated Kuadrant AuthPolicy configuration rules that fail to enforce strict boundary checks and cryptographic assertion of the X-MaaS-Username and X-MaaS-Group parameters. Because these headers are treated as authoritative by the backend services, any entity capable of injecting or spoofing them successfully circumvents the intended authorization checks.\nThe attack flow proceeds as follows. First, an attacker establishes execution capability within any pod inside the target Kubernetes cluster. Leveraging this internal network position, the attacker crafts a malicious HTTP request directed at the MaaS API. Inside this request payload, the attacker explicitly injects arbitrary values into the X-MaaS-Username and X-MaaS-Group headers, substituting the intended caller identity with that of a privileged administrator or a distinct tenant.\nUpon receipt, the Kuadrant AuthPolicy gateway and downstream MaaS API services accept the forged headers verbatim without performing secondary validation against a trusted identity provider or token store. Consequently, the access control layer maps the request context to the attacker-supplied username and group, granting full authorization to protected operational paths.\nWith unauthorized elevated privileges established, the attacker executes post-exploitation activities. These include issuing API calls to mint unauthorized Kubernetes ServiceAccount tokens in arbitrary foreign namespaces, sending destructive requests to revoke legitimate client API keys, and reading sensitive model access configurations stored within the control plane scope. Network exposure is restricted to the internal cluster perimeter, but any compromised pod or internal malicious actor can weaponize the flaw to subvert multi-tenant segregation boundaries."
}