SECURITYCRITICALCVE-2026-14450

CVE-2026-14450: MaaS API Auth Bypass via Forged HTTP Headers

A critical CVSS 9.9 flaw in the MaaS API allows any pod within a Kubernetes cluster to bypass the Kuadrant AuthPolicy gateway by forging X-MaaS-Username...

Dylan H.

Security Team

August 11, 2026
4 min read
CVE-2026-14450: MaaS API Auth Bypass via Forged HTTP Headers

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • MaaS API (Kubernetes-based deployments)
  • Kuadrant AuthPolicy gateway

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.

AttributeDetails
CVE IDCVE-2026-14450
CVSS Score9.9 (Critical)
Attack VectorNetwork — within the Kubernetes cluster
Attack ComplexityLow
Privileges RequiredLow (any pod execution within the cluster)
User InteractionNone
ScopeChanged
ImpactComplete confidentiality, integrity, and availability compromise of MaaS API

Exploitation Scenario

  1. 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)
  2. 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
  3. The MaaS API accepts the headers without verification, treating the request as coming from the admin user in the administrators group
  4. The Kuadrant AuthPolicy policy is bypassed entirely
  5. 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:
    - Ingress

Label 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 -rn

Monitor 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.


References