Executive Summary
CVE-2026-14450 is a critical authentication bypass vulnerability (CVSS 9.9) in the MaaS API affecting Kubernetes-based deployments. The flaw allows any pod within the cluster to impersonate arbitrary users or groups by injecting forged HTTP headers — specifically X-MaaS-Username and X-MaaS-Group — which the MaaS API trusts without first-party verification. This completely bypasses the Kuadrant AuthPolicy gateway and enables an attacker to gain unauthorized access to MaaS API resources and operations.
CVSS Score: 9.9 (Critical)
Vulnerability Details
Root Cause
The MaaS API in Kubernetes environments uses the HTTP headers X-MaaS-Username and X-MaaS-Group to identify the calling user and their group membership. The critical flaw is that these headers are accepted verbatim without any cryptographic verification or first-party authentication of their origin.
The Kuadrant AuthPolicy gateway — intended to enforce access control — is bypassed entirely because the MaaS API trusts headers it receives, regardless of whether they originate from a legitimately authenticated source.
| Attribute | Details |
|---|---|
| CVE ID | CVE-2026-14450 |
| CVSS Score | 9.9 (Critical) |
| Attack Vector | Network — within the Kubernetes cluster |
| Attack Complexity | Low |
| Privileges Required | Low (any pod execution within the cluster) |
| User Interaction | None |
| Scope | Changed |
| Impact | Complete confidentiality, integrity, and availability compromise of MaaS API |
Exploitation Scenario
- An attacker gains execution within any pod inside the Kubernetes cluster (e.g., via a compromised container image, supply chain attack, or initial-access vulnerability in another service)
- From that pod, the attacker crafts an HTTP request to the MaaS API with forged headers:
GET /api/v1/machines HTTP/1.1 Host: maas-api.svc.cluster.local X-MaaS-Username: admin X-MaaS-Group: administrators - The MaaS API accepts the headers without verification, treating the request as coming from the
adminuser in theadministratorsgroup - The Kuadrant AuthPolicy policy is bypassed entirely
- The attacker now has full administrative access to the MaaS API
This allows:
- Enumerating and controlling physical/virtual machines managed by MaaS
- Deploying, decommissioning, or modifying infrastructure
- Extracting sensitive configuration and credentials
- Pivoting further into managed infrastructure
Affected Versions
This vulnerability affects MaaS API deployments configured to run within Kubernetes clusters that use HTTP header-based identity propagation. Consult the MaaS project's security advisory for specific affected versions and fix details.
Immediate Remediation
1. Apply Available Patches
Review the upstream MaaS project for patches addressing CVE-2026-14450 and apply them as soon as available.
2. Enforce Header Stripping at the Gateway
As an immediate mitigation, configure your ingress controller or service mesh to strip X-MaaS-Username and X-MaaS-Group headers from inbound requests before they reach the MaaS API:
# Nginx Ingress Controller — strip auth headers from client requests
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_set_header X-MaaS-Username "";
proxy_set_header X-MaaS-Group "";For Envoy-based service meshes (Istio, Linkerd):
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
spec:
configPatches:
- applyTo: HTTP_FILTER
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.header_mutation
typed_config:
mutations:
request_mutations:
- remove: "x-maas-username"
- remove: "x-maas-group"3. Network Policy Restriction
Use Kubernetes NetworkPolicy to restrict which pods can reach the MaaS API service:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-maas-api-access
namespace: maas
spec:
podSelector:
matchLabels:
app: maas-api
ingress:
- from:
- podSelector:
matchLabels:
maas-api-client: "true"
policyTypes:
- IngressLabel only explicitly trusted pods with maas-api-client: "true".
4. Implement First-Party Authentication
Long-term, ensure the MaaS API implements cryptographically verified identity (e.g., mTLS client certificates, signed JWT tokens) rather than relying on plain HTTP headers for identity claims.
Detection
Look for Anomalous API Calls
Audit MaaS API access logs for requests containing X-MaaS-Username or X-MaaS-Group headers from unexpected source pod IPs:
# If MaaS API logs are available in your log aggregator
kubectl logs -n maas deployment/maas-api | \
grep -E "X-MaaS-(Username|Group)" | \
awk '{print $0}' | sort | uniq -c | sort -rnMonitor for Privilege Escalation Patterns
Alert on:
- API calls to administrative MaaS endpoints from pods that are not explicitly authorized MaaS clients
- Machine deployment or decommission events outside of expected change windows
- Unusual RBAC policy queries within the cluster
CVSS 9.9 Context
A CVSS score of 9.9 places this vulnerability at the top of the critical range. The near-perfect score reflects:
- Zero authentication required beyond cluster pod execution
- Complete scope change (attacker pivots from pod to full MaaS API control)
- Full impact on confidentiality, integrity, and availability of managed infrastructure
Any organization running MaaS in a Kubernetes environment should treat this as an emergency-level finding.