Der er identificeret fire s\u00e5rbarheder i det under udvikling Kubernetes ingress-controller, ingress-nginx, som muligg\u00f8r, at ondsindet kode kan eksekveres p\u00e5 servere i cloud-systemer, der benytter Kubernetes-platformen, og f\u00e5 fuld privilegeret adgang til Kubernetes-klyngen. Problemerne er angivet med en kritisk faregrad (9,8 ud af 10). De forskere, der opdagede problemerne, har givet s\u00e5rbarhederne kodeordet IngressNightmare og bem\u00e6rket, at s\u00e5rbarhederne p\u00e5virker ca. 43% af cloud-milj\u00f8erne. S\u00e5rbarhederne er blevet rettet i versionerne ingress-nginx 1.11.5 og 1.12.1. <\/p>\n
Ingress-controlleren fungerer som en gateway og anvendes i Kubernetes til at organisere adgang fra det eksterne netv\u00e6rk til tjenester inde i klyngen. Controlleren ingress-nginx er den mest popul\u00e6re og anvender server<\/a> NGINX til at videresende anmodninger til klyngen, rute eksterne foresp\u00f8rgsler og balancere belastningen. Kubernetes-projektet leverer grundl\u00e6ggende ingress-controllere for AWS, GCE og nginx, sidstn\u00e6vnte har ikke noget at g\u00f8re med kubernetes-ingress-controllere, som vedligeholdes af F5\/NGINX (de s\u00e5rbarheder, der diskuteres, ber\u00f8rer ikke projekter udviklet af NGINX-udviklerne, og n\u00e6vnelsen af nginx i navnet ingress-nginx er udelukkende relateret til brugen af nginx som proxy). <\/p>\n S\u00e5rbarhederne giver en ikke-godkendt angriber mulighed for at eksekvere sin kode i konteksten af ingress-nginx-controlleren, n\u00e5r der sendes en anmodning til Admission-webhandleren. Under netv\u00e6rksscanning er over 6500 s\u00e5rbare Kubernetes-klynger blevet identificeret, som anvender offentligt tilg\u00e6ngelige s\u00e5rbare controllere med Admission-handleren \u00e5ben for eksterne foresp\u00f8rgsler. <\/p>\n I standardkonfigurationen kan ondsindet kode f\u00e5 adgang til indstillingerne for objektet Ingress, hvor blandt andet legitimationsoplysninger til Kubernetes-servere opbevares, hvilket muligg\u00f8r privilegeret adgang til hele klyngen. Som en sikkerhedsforanstaltning anbefales det at deaktivere funktionen «Validating Admission Controller» i ingress-nginx. <\/p>\n Admission-controlleren k\u00f8res i et separat pod-milj\u00f8 og udf\u00f8rer en kontrol af indg\u00e5ende ingress-objekter f\u00f8r deres implementering. Som standard accepterer web-handleren Admission anmodninger uden autentificering fra det offentlige netv\u00e6rk. Under kontrolprocessen opretter Admission-controlleren en konfiguration til http-serveren nginx baseret p\u00e5 indholdet af det modtagne ingress-objekt og verificerer, at det er korrekt. <\/p>\n De identificerede s\u00e5rbarheder muligg\u00f8r inds\u00e6ttelse af egne indstillinger i nginx ved at sende et specielt formateret ingress-objekt direkte til Admission-controlleren. Forskerne har opdaget, at visse egenskaber fra kontrolanmodninger, der er angivet i feltet «.request.object.annotations», direkte inds\u00e6ttes i nginx-konfigurationen. Den genererede konfiguration anvendes dog ikke; den testes blot ved at k\u00f8re eksekverbar fil «nginx» med valgmuligheden «-t». <\/p>\n Specifikt udf\u00f8res inds\u00e6ttelse af eksterne data i konfigurationen for parametre som «mirror-target», «mirror-host» (CVE-2025-1098), «auth-tls-match-cn» (CVE-2025-1097) og «auth-url» (CVE-2025-24514). For eksempel, i konfigurationslinjen «set $target {{ $externalAuth.URL }};» inds\u00e6ttes den URL, der er angivet i parameteren «auth-url», i stedet for «{{ $externalAuth.URL }}». Desuden kontrolleres URL'en ikke for korrekthed. F\u00f8lgelig kan en angriber overf\u00f8re en URL som «http:\/\/example.com\/#;\nindstillinger» og inds\u00e6tte sine egne indstillinger i konfigurationsfilen. <\/p>\n For at udf\u00f8re vilk\u00e5rlig kode under konfigurationskontrollen med kommandoen «nginx -t» udnyttede forskerne, at nginx ud over at kontrollere syntaksen ogs\u00e5 indl\u00e6ser biblioteker med moduler og \u00e5bner filer n\u00e6vnt i konfigurationen for at vurdere deres tilg\u00e6ngelighed. Blandt andet under behandlingen af direktivet ssl_engine indl\u00e6ses den delte biblioteksfil, der er angivet i direktivet. SSL<\/a>-motor. <\/p>\n For uploading their library to the Kubernetes server, researchers exploited (CVE-2025-1974) the fact that when handling large requests, nginx saves the request body in a temporary file that is immediately deleted, but an open file descriptor for this file remains in the 'proc' filesystem. Thus, it is possible to simultaneously send requests to save the temporary file and initiate a configuration check where the 'ssl_engine' directive points to the descriptor in the 'proc' filesystem. <\/p>\n To ensure that the file descriptor remains accessible for a long time, the value of 'Content-Length' in the request can be specified as deliberately larger than the actual data being sent (the server will wait for the remaining data). An additional complexity is the need to guess the PID of the process and the number of the file descriptor associated with the loaded shared library, but since typically only a minimal number of processes run in the container, the required values can be guessed through a few attempts. If successful and the substituted shared library is loaded, the attacker can access stored parameters within the pod environment that are sufficient for controlling the entire cluster.