Am 15. Juli kam ein Fix für Code aus dem Jahr 2011

Am 15. Juli 2026 veröffentlichte das nginx-Projekt die Versionen 1.30.4 und 1.31.3. Das Release schloss einen Heap-Pufferüberlauf, der in jeder Version bis zurück zu 0.9.6 erreichbar war. Diese Version stammt aus dem Jahr 2011. Die Schwachstelle wird als CVE-2026-42533 geführt und mit 9,2 auf der CVSS-Skala Version 4.0 bewertet. F5 veröffentlichte für NGINX-Plus-Kunden das Advisory K000162097, behoben in 37.0.3.1.

Die Liste der Melder ist ungewöhnlich. Mehr als ein Dutzend Forscher meldeten dasselbe Problem unabhängig voneinander, darunter Mufeed VH von Winfunc Research, und der langjährige Maintainer Maxim Dounin übernahm die Behebung. Wenn eine Lücke von so vielen Menschen gleichzeitig gefunden wird, liegt die Annahme nahe, dass sie nicht schwer zu finden war und dass andere sie ohne Meldung gefunden haben.

Was in Ihrer Konfiguration stehen muss, damit es zählt

Der Fehler sitzt in der Skript-Engine, die jene String-Ausdrücke auswertet, die nginx zur Laufzeit einer Anfrage bildet. Diese Auswertung läuft in zwei Durchgängen. Der erste misst, wie groß ein Puffer sein muss, und nutzt dafür den Erfassungsstand in diesem Moment. Der zweite schreibt in diesen Puffer mit Erfassungsdaten, die die Anfrage beeinflussen kann. Weichen beide Durchgänge voneinander ab, ist der Schreibvorgang größer als der reservierte Platz.

Der Auslöser ist enger, als es der Versionsbereich vermuten lässt. Nötig ist eine regex-basierte map-Direktive, deren Ausgabevariable nach einer Erfassung aus einem früheren Regex-Treffer in einem String-Ausdruck referenziert wird, also die nummerierten Erfassungen Dollar-eins und Dollar-zwei. Enthält Ihre Konfiguration keine Regex-Map dieser Form, setzt die Versionsnummer allein Sie nicht auf die Liste der Betroffenen. Das ist die nützlichste Tatsache dieser Veröffentlichung.

Ohne Anmeldung erreichbar, aber noch nicht bewaffnet

Wo das Muster vorliegt, braucht die auslösende Anfrage keinerlei Zugangsdaten. Eine präparierte HTTP-Anfrage von irgendwo im Internet genügt. Das verlässliche Ergebnis ist der Absturz und Neustart eines Worker-Prozesses, also eine Dienstblockade vor der Eingangstür dessen, was der Server ausliefert. Codeausführung aus der Ferne ist der schwierigere Fall, möglich dort, wo die Speicherverwürfelung deaktiviert ist oder umgangen werden kann. Der Forscher Stan Shaw argumentiert, die Lücke liefere ihren eigenen Weg um diesen Schutz herum.

Zum 20. Juli gibt es keinen öffentlichen Exploit-Code, und die CVE steht nicht im US-Katalog bekannter ausgenutzter Schwachstellen. Das ist der aktuelle Stand, keine Prognose. Shaw hat angekündigt, 21 Tage nach Erscheinen des Patches einen Proof of Concept zu veröffentlichen, was in die erste Augustwoche fällt. Eine nicht ausgenutzte kritische Lücke mit einem veröffentlichten Datum ist ein anderes Planungsproblem als eine ohne.

Drei Überläufe in einem Teilsystem in zwei Monaten

CVE-2026-42533 steht nicht allein. Es ist der dritte Heap-Überlauf im Auswertungscode von nginx innerhalb von rund zwei Monaten, nach CVE-2026-42945 im Mai und CVE-2026-9256 kurz danach. Drei Funde in einem Teilsystem in einem Quartal sind ein Muster und kein Zufall, und das Muster besagt, dass die Zwei-Durchgang-Konstruktion gerade von Leuten durchgesehen wird, die inzwischen wissen, wo sie suchen müssen.

Die Folge für die Planung ist eindeutig. Wer dies als einzelnen Versionssprung behandelt und abhakt, hat eine spürbar von null verschiedene Wahrscheinlichkeit, im selben Quartal erneut hier zu stehen. Auf die Beobachtungsliste gehört das Teilsystem, nicht die CVE-Nummer, und dauerhaft reduzieren lassen sich die Konfigurationsformen, die es erreichen.

Die Prüfung vor dem Anruf beim Hoster

Die meisten kritischen Webserver-Veröffentlichungen machen einen Unternehmer von anderen abhängig. Diese nicht, denn der Auslöser ist in einer Datei lesbar, die Sie öffnen können. Fragen Sie nach Ihrer nginx-Version und danach, ob ein map-Block in der Konfiguration einen regulären Ausdruck verwendet und eine Variable speist, die später zusammen mit nummerierten Erfassungen in einen String einfließt. Zwei Fragen, eine Antwort, und Sie wissen, ob Anfang August eine Frist oder eine Notiz ist.

Für Unternehmen im Anwendungsbereich der Richtlinie über Netz- und Informationssicherheit in der Europäischen Union, und für jene, die den entsprechenden britischen Leitlinien folgen, zählt die Dokumentation ebenso wie der Patch. Halten Sie fest, auf welcher Version Sie standen, wann Sie die Konfiguration geprüft haben und welche Minderung Sie angewandt haben. Eine Aufsichtsbehörde, die nach einer im Juli veröffentlichten kritischen Lücke fragt, will das Datum Ihrer Bewertung, nicht nur das Datum des späteren Upgrades.

Weiterlesen: Vier Coding-Agenten entkamen, ohne auszubrechen  |  ServiceNow patchte die eigene Cloud zuerst, Sie 103 Tage später