In het ontwikkelde Kubernetes ingress-controller project ingress-nginx zijn vier kwetsbaarheden ontdekt die in staat zijn om de uitvoering van eigen code op servers van cloudsystemen die het Kubernetes-platform gebruiken te bereiken, en om volledige geprivilegieerde toegang tot het Kubernetes-cluster te verkrijgen. De problemen hebben een kritieke risicoscore gekregen (9.8 uit 10). De onderzoekers die de problemen hebben ontdekt, hebben de kwetsbaarheden de codenaam IngressNightmare gegeven en opgemerkt dat ze ongeveer 43% van cloudomgevingen raken. De kwetsbaarheden zijn verholpen in de versies ingress-nginx 1.11.5 en 1.12.1. <\/p>\n
De ingress-controller fungeert als een poort en wordt in Kubernetes gebruikt om toegang van extern naar de diensten binnen het cluster te organiseren. De ingress-nginx-controller is de meest populaire en maakt gebruik van server<\/a> NGINX voor het doorsturen van verzoeken naar het cluster, het routeren van externe aanvragen en het balanceren van de belasting. Het Kubernetes-project biedt basis ingress-controllers voor AWS, GCE en nginx, waarvan de laatste niet gerelateerd is aan de kubernetes-ingress-controller, die wordt onderhouden door F5\/NGINX (de besproken kwetsbaarheden betreffen geen projecten ontwikkeld door NGINX-ontwikkelaars, de vermelding van nginx in de naam ingress-nginx is alleen gerelateerd aan het gebruik van nginx als proxy). <\/p>\n De kwetsbaarheden stellen een niet-geauthenticeerde aanvaller in staat om eigen code uit te voeren in de context van de ingress-nginx-controller, met de mogelijkheid om een verzoek naar de webverwerker Admission te sturen. Tijdens netwerkscans zijn meer dan 6500 kwetsbare Kubernetes-clusters ontdekt die gebruikmaken van openbare kwetsbare controllers met een open Admission-verwerker voor externe verzoeken. <\/p>\n In de standaardconfiguratie kan de door de aanvaller uitgerunde code toegang krijgen tot de instellingen van het Ingress-object, waarin onder andere de referenties voor toegang tot de Kubernetes-servers zijn opgeslagen. Dit stelt hen in staat om geprivilegieerde toegang tot het gehele cluster te verkrijgen. Als een omweg voor bescherming wordt aanbevolen om de functie «Validating Admission Controller» in ingress-nginx uit te schakelen. <\/p>\n De Admission-controller draait in een aparte pod-omgeving en voert de validatie van inkomende ingress-objecten uit voordat ze worden ingezet. Standaard accepteert de Admission-webhandler verzoeken zonder authenticatie vanuit het publieke netwerk. Tijdens de validatie maakt de Admission-controller een configuratie voor de http-server nginx op basis van de inhoud van het ontvangen ingress-object en controleert het de correctheid ervan. <\/p>\n De ontdekte kwetsbaarheden maken het mogelijk om eigen instellingen in nginx te injecteren via het direct indienen van een speciaal gevormd ingress-object in de Admission-controller. Onderzoekers ontdekten dat sommige eigenschappen van controleverzoeken die in het veld «.request.object.annotations» zijn ingesteld, direct in de nginx-configuratie worden ingevoegd. De gegenereerde configuratie wordt daarbij niet toegepast, maar alleen getest door het uitvoeren van het uitvoerbare bestand «nginx» met de optie «-t». <\/p>\n In het bijzonder wordt de injectie van externe gegevens in de configuratie uitgevoerd voor de parameters «mirror-target», «mirror-host» (CVE-2025-1098), «auth-tls-match-cn» (CVE-2025-1097) en «auth-url» (CVE-2025-24514). Bijvoorbeeld, in de configuratielijn «set $target {{ $externalAuth.URL }};» wordt in plaats van «{{ $externalAuth.URL }}» de URL ingevoegd die in de parameter «auth-url» is opgegeven. Daarbij wordt de correctheid van de URL niet gecontroleerd. Dienovereenkomstig kan de aanvaller een URL zoals «http:\/\/example.com\/#;\ninstellingen» doorgeven en zijn eigen instellingen in het configuratiebestand invoegen. <\/p>\n Om willekeurige code uit te voeren tijdens het controleren van de configuratie met het commando «nginx -t», maakten onderzoekers gebruik van het feit dat naast het controleren van de syntaxis nginx ook bibliotheken met modules laadt en bestanden opent die in de configuratie zijn genoemd, om hun beschikbaarheid te beoordelen. Onder andere wordt bij het verwerken van de ssl_engine-directive de gedeelde bibliotheek die in de directive is opgegeven geladen voor SSL<\/a>-de engine. <\/p>\n Om hun bibliotheek op de Kubernetes-server te uploaden, maakten onderzoekers gebruik van (CVE-2025-1974) het feit dat nginx bij het verwerken van grote aanvragen de body van de aanvraag opslaat in een tijdelijk bestand, dat onmiddellijk wordt verwijderd, maar in het bestandssysteem \u00ab\/proc\u00bb blijft er een open bestandsdescriptor voor dit bestand. Op deze manier kunnen gelijktijdig verzoeken worden verzonden om het tijdelijke bestand op te slaan en de configuratiecontrole te starten, waarin het pad naar de descriptor in het bestandssysteem \u00ab\/proc\u00bb is opgegeven in de directive \u00abssl_engine\u00bb. <\/p>\n Om ervoor te zorgen dat de bestandsdescriptor gedurende langere tijd toegankelijk blijft, kan de waarde \u00abContent-Length\u00bb in het verzoek opzettelijk groter worden opgegeven dan de daadwerkelijk verzonden gegevens (de server zal wachten op de ontvangst van de resterende gegevens). Een extra complicatie is de noodzaak om de PID van het proces en het nummer van de bestandsdescriptor, die is gekoppeld aan de geladen gedeelde bibliotheek, te raden, maar omdat er meestal een minimaal aantal actieve processen in de container wordt gebruikt, kunnen de benodigde waarden door middel van brute force worden geraden met een paar pogingen. Bij succes en het uploaden van de vervangende gedeelde bibliotheek, kan de aanvaller toegang krijgen tot de parameters die binnen het pod-ecosysteem zijn opgeslagen, wat voldoende is voor het beheer van de hele cluster.