Die Ursache der Schwachstelle liegt laut Depthfirst in einem zweistufigen Verfahren der Skript-Engine: Im ersten Durchlauf wird die benötigte Puffergröße berechnet, im zweiten werden die Daten kopiert. Zwischen beiden Durchläufen ändert sich der interne Zustand der Engine.
Enthält eine Rewrite-Ersetzung ein Fragezeichen („?"), sorgt ein nicht weitergereichtes Flag für die Reservierung eines zu kleinen Puffers. In der Folge werden vom Angreifer kontrollierte, maskierte URI-Daten über die Grenze des Heap-Speichers hinaus geschrieben.
Depthfirst beschreibt das Vorgehen so: Indem die angefragte URI mit Pluszeichen aufgefüllt wird, lässt sich die Maskierungsfunktion zwingen, jedes Byte auf drei Bytes auszudehnen und damit den zugewiesenen Speicherblock zu überlaufen. Die Größe des Überlaufs liege vollständig in der Hand des Angreifers und richte sich nach der Zahl der maskierbaren Zeichen.
Da sich für den Überlauf keine Null-Bytes verwenden lassen, ist RCE deutlich aufwendiger: Nach Darstellung des Sicherheitsunternehmens müssen alle Felder im NGINX-Speicherpool bis zum Zielzeiger überschrieben und der Pool unmittelbar nach der Korruption des Pool-Headers zerstört werden, ohne dass der Worker-Prozess abstürzt.
Konkret nutzt der Angriff laut Depthfirst eine über mehrere Anfragen verteilte Heap-Manipulation („cross-request heap feng shui"), um den cleanup-Zeiger eines benachbarten ngx_pool_t zu korrumpieren. Da URI-Bytes keine Null-Bytes enthalten dürfen, werden die nötigen Daten über POST-Bodies eingeschleust. Der manipulierte Zeiger verweist anschließend auf eine gefälschte ngx_pool_cleanup_s-Struktur, die beim Zerstören des Pools die Funktion system() aufruft.
F5 hat die Lücke in NGINX Plus in den Versionen 37.0.0, R36 P4 und R32 P6 behoben sowie in der quelloffenen Variante in den Versionen 1.31.0 und 1.30.1.