Kuadrant MaaS API Header Trust Authentication Bypass

Technical Analysis

The vulnerability stems from a missing authentication boundary in the MaaS API's integration with the Kuadrant AuthPolicy gateway: identity-asserting headers (X-MaaS-Username, X-MaaS-Group) are accepted at face value from internal pod-to-pod traffic rather than being cryptographically signed or verified against an authenticated identity provider. Because any workload co-located in the cluster can craft these headers, the flaw effectively collapses tenant isolation, permitting lateral privilege escalation from a low-privilege pod to cluster-wide administrative capabilities over the MaaS control plane. The concrete blast radius includes minting Kubernetes ServiceAccount tokens in arbitrary tenant namespaces, revoking legitimate API keys (denial of service), and exfiltrating model access configuration—likely including model endpoints, routing policies, and credentials used to reach backend inference services. Given a CVSS score of 9.9, this is a network-exploitable, low-complexity, high-impact vulnerability requiring no special privileges and no user interaction. Organizations running AI agents, RAG pipelines, or multi-tenant LLM inference gateways on Kubernetes clusters using this MaaS/Kuadrant stack are directly exposed: exfiltrated model access configuration and forged ServiceAccount tokens could let an attacker hijack agent-to-model API calls, steal LLM provider credentials, or redirect agent inference traffic to malicious endpoints, making this highly agent-relevant.

Affected Systems

Kubernetes clusters running MaaS (Model-as-a-Service) API gateways integrated with Kuadrant AuthPolicy for multi-tenant model access control; any deployment where X-MaaS-Username/X-MaaS-Group headers are used as trust boundaries without independent verification.

Indicators of Compromise

• No specific file hashes, IPs, or domains published; detection should focus on anomalous X-MaaS-Username/X-MaaS-Group header values originating from unexpected source pods, unexpected ServiceAccount token minting events across tenant namespaces, and unauthorized API key revocation events in MaaS audit logs.

Remediation Steps

1. 1

   Apply vendor patch

   Upgrade Kuadrant AuthPolicy and MaaS API components to the patched version that enforces first-party authentication and rejects client-supplied identity headers from untrusted sources.

2. 2

   Enforce header stripping at ingress

   Configure the gateway/mesh (Envoy, Istio, etc.) to strip or overwrite X-MaaS-Username and X-MaaS-Group headers on ingress from any non-trusted internal source before they reach the MaaS API.

3. 3

   Implement mutual TLS and signed identity assertions

   Replace verbatim header trust with cryptographically signed tokens (e.g., mTLS client certs or signed JWTs validated against an OIDC provider) for pod-to-pod identity propagation.

4. 4

   Enforce network policies for tenant isolation

   Apply Kubernetes NetworkPolicies to restrict which pods can communicate directly with the MaaS API, reducing the pool of workloads capable of forging headers.

5. 5

   Audit and rotate exposed credentials

   Rotate all API keys and ServiceAccount tokens associated with the MaaS platform and review audit logs for signs of prior exploitation, including unauthorized token minting or configuration exfiltration.

6. 6

   Monitor for anomalous cross-tenant activity

   Deploy detection rules for ServiceAccount token creation events outside expected namespaces and unexpected API key revocation patterns.