CVE-2026-14450: Kritisk hul i MaaS API og Kuadrant

CVE-2026-14450 er en fejl i MaaS API’et (Model-as-a-Service), der bruges til at styre adgang til AI-modeller i Kubernetes-klynger via Kuadrant AuthPolicy, en gateway der skal godkende og afgrænse adgang mellem forskellige kunder (tenants) i samme klynge. Fejlen skyldes, at gatewayen stoler blindt på to HTTP-headere, X-MaaS-Username og X-MaaS-Group, uden at kontrollere, om de er ægte. Enhver pod, altså en kørende arbejdsbelastning, inde i klyngen kan derfor selv sætte disse headere og udgive sig for at være en anden bruger eller gruppe. Det svarer til at lade en dørmand acceptere et navneskilt uden at tjekke id.

Sårbarheden rammer organisationer, der kører en MaaS-platform på Kubernetes med Kuadrant som adgangsstyring, typisk it-driftsleverandører, offentlige institutioner og virksomheder, der stiller AI-modeller til rådighed for flere kunder eller afdelinger i samme klynge. Det er særligt relevant for jer, der deler infrastruktur mellem flere tenants, fx en kommune, der drifter fælles AI-tjenester for flere forvaltninger, eller en it-leverandør, der hoster AI-modeller for flere kunder på samme klynge.

En angriber, der allerede har adgang til en pod i klyngen, fx via en anden sårbarhed eller en kompromitteret container, kan forfalske headerne og optræde som administrator i en helt anden kundes namespace. Det giver mulighed for at udstede nye Kubernetes ServiceAccount-tokens (adgangsnøgler til klyngen) i andre tenants’ namespaces, tilbagekalde andre kunders API-nøgler og hente følsomme konfigurationer for, hvilke AI-modeller kunderne har adgang til. I praksis kan én kompromitteret arbejdsbelastning bruges som springbræt til at overtage hele den delte platform.

CVSS-scoren er 9,9 ud af 10, kritisk. Angrebet kræver netværksadgang og lav kompleksitet, men kræver, at angriberen allerede har en form for lav-privilegeret adgang til klyngen, fx via en pod. Der kræves ingen handling fra en bruger, og konsekvensen rækker ud over den sårbare komponent selv, fordi andre tenants’ data og adgang kan blive kompromitteret. Fortrolighed, integritet og tilgængelighed er alle vurderet til høj påvirkning. Der er ingen oplysninger om, at sårbarheden aktivt udnyttes, men der findes heller ikke offentlig dokumentation for en officiel rettelse.

Det vigtigste er at stoppe gatewayen i at stole på headere, der kommer fra podden selv.

1. Konfigurér Kuadrant AuthPolicy og netværkspolitikker, så X-MaaS-Username og X-MaaS-Group altid fjernes eller overskrives, før trafikken når gatewayen, og kun sættes af en betroet autentificeringstjeneste.
2. Gennemgå, hvilke pods og namespaces der har netværksadgang til MaaS API’et, og begræns adgangen med Kubernetes NetworkPolicies, så kun betroede komponenter kan kommunikere med gatewayen.
3. Tjek logs for uventede ServiceAccount-tokens udstedt i andre namespaces end forventet, og tilbagekald tokens, I ikke kan forklare.
4. Følg Kuadrant-projektets og jeres leverandørs sikkerhedsmeddelelser for en officiel rettelse, og opdatér, så snart den er tilgængelig.
5. Er I i tvivl om, hvordan I afgrænser adgang mellem tenants i jeres Kubernetes-klynge, bør I hente ekstern hjælp til at gennemgå adgangsstyringen, før flere kunder rammes.