Die Ursache liegt laut F5 in der Skript-Engine von nginx, also in dem Code, der zur Laufzeit von Anfragen Zeichenketten aus Direktiven zusammensetzt. Sichtbar wird der Fehler nur unter einer speziellen Konstellation: wenn eine regex-basierte map verwendet wird und deren Ausgabevariable in einem String-Ausdruck referenziert wird, nachdem zuvor ein Capture aus einem früheren Regex-Treffer erfolgt ist.

Nach Darstellung des Herstellers gerät dabei die zweistufige Auswertung der Engine aus dem Takt. Im ersten Durchlauf wird der Speicherbedarf ermittelt und ein entsprechend großer Puffer reserviert, im zweiten werden die Bytes hineingeschrieben. Beide Schritte greifen auf denselben gemeinsam genutzten Capture-Zustand zu. Wird zwischen beiden Durchläufen die Regex der map ausgewertet, überschreibt sie diesen Zustand.

Die Folge: Der erste Durchlauf dimensioniert den Puffer für das ursprüngliche Capture, etwa eine Referenz wie $1 aus einem location-Treffer, während der zweite Durchlauf mit einem anderen, vom Angreifer beeinflussbaren Capture schreibt. Der Puffer ist dann zu klein; sowohl die Länge als auch der Inhalt des Überlaufs kommen direkt aus der Anfrage.

F5 bewertet CVE-2026-42533 mit 9,2 nach CVSS v4 und mit 8,1 nach CVSS v3.1. Die Angriffskomplexität stuft der Hersteller als hoch ein. Verwundbar sind laut F5 alle nginx-Versionen von 0.9.6 bis 1.31.2. Diese Spanne reicht bis 2011 zurück, als map Unterstützung für reguläre Ausdrücke erhielt.

Gemeldet wurde die Schwachstelle F5 zufolge unabhängig voneinander von mehr als einem Dutzend Forschern. Im Changelog von nginx werden Mufeed VH von Winfunc Research und der Maintainer Maxim Dounin für den Fix genannt. Einer der Melder, Stan Shaw, der unter dem Namen cyberstan veröffentlicht, legte eine deutlich ausführlichere Analyse vor als der Herstellerhinweis.

Shaw widerspricht insbesondere der Einordnung, die Code-Ausführung nur unter deaktiviertem oder umgehbarem ASLR für realistisch hält. Gegenüber The Hacker News sagte er, die Schwachstelle liefere den nötigen ASLR-Bypass selbst. Wenn das überschriebene Capture kleiner sei als das ursprüngliche, gebe der zu große Puffer nicht initialisierte Heap-Daten zurück. Auf einem Standard-Build von Ubuntu 24.04 reiche eine einzige nicht authentifizierte GET-Anfrage aus, um die für eine Nutzlast benötigten Adressen zu gewinnen.

Shaw erklärte: „Ein Leser des F5-Hinweises könnte vernünftigerweise zu dem Schluss kommen, dass dies auf Standardsystemen nur ein Denial-of-Service ist. Das ist nicht so.“ Das ist eine weitergehende Behauptung als die von F5. Nach eigenen Angaben erzielte er in seinen Tests eine Trefferquote von 10 von 10, veröffentlicht Details zur Ausnutzung und einen Proof of Concept aber vorerst nicht, sodass sich das bislang nicht unabhängig überprüfen lässt.

Als vollständige Abhilfe nennt F5 ausschließlich das Upgrade auf nginx 1.30.4 oder 1.31.3 beziehungsweise NGINX Plus 37.0.3.1. Wer nicht sofort patchen kann, soll laut Hersteller betroffene regex-maps vorübergehend auf benannte Captures umstellen. Shaw sagt, das schließe den Hauptpfad und decke die meisten Konfigurationen ab, lasse aber einen engeren Alternativpfad offen: Definiert eine map dieselbe benannte Gruppe wie die location-Regex, lasse sich derselbe Overflow über einen zweiten Codepfad erreichen. Dies habe er mit AddressSanitizer bestätigt; im F5-Hinweis werde diese Variante nicht erwähnt.

Die verwundbare Konfiguration ist laut Shaw eng umrissen: eine regex-basierte map, deren Variable in einem String-Ausdruck gemeinsam mit einem nummerierten Capture wie $1 oder $2 aus einer früheren Regex auftaucht, wobei das Capture vor der map-Variable steht. Sein eigener Scanner prüft Konfigurationen automatisiert, verfolgt Includes und markiert nur die ausnutzbare Reihenfolge; ausnutzen soll das Werkzeug nichts.

CVE-2026-42533 ist bereits der dritte offengelegte Heap-Overflow in der Ausdrucksauswertung von nginx innerhalb von rund zwei Monaten. Zuvor wurden Rift unter CVE-2026-42945 im Mai und wenige Tage später ein Fehler mit überlappenden Captures im rewrite-Modul unter CVE-2026-9256 bekannt. Laut dem Forscher gehören alle drei zur selben Fehlerklasse: Die zweistufige Skript-Engine misst einen Puffer in einem Durchlauf und schreibt im nächsten hinein, wobei der Schreibvorgang jeweils über die zuvor ermittelte Größe hinausgeht.

Stand 20. Juli war CVE-2026-42533 nicht im Katalog der Known Exploited Vulnerabilities von CISA aufgeführt, und öffentlicher Exploit-Code war noch nicht erschienen. Shaw kündigte an, seinen Proof of Concept 21 Tage nach dem Patch zu veröffentlichen. The Hacker News fragte F5 zudem, ob die Umstellung auf benannte Captures die Lücke angesichts der von Shaw dokumentierten Variante vollständig schließt und wann korrigierte Builds für die betroffenen nachgelagerten Produkte erscheinen. Eine Antwort lag bei Veröffentlichung nicht vor.