w5m1n9/nginx-ngx_http_rewrite_module-heap-buffer-overflow-cve-2026-9256Proof-of-Concept-Exploit für CVE-2026-9256, einen Heap-Pufferüberlauf im NGINX ngx_http_rewrite_module. Bestätigt den Absturz eines entfernten Workers durch eine präparierte URI mit Sonderzeichen, mit mehrstufiger Keep-Alive-Sonde für zuverlässige Erkennung.
Anwendungsbereich: Nur für lokale Testumgebungen, autorisierte Replikationsumgebungen, Schwachstellenverifizierung und Analyse von Schutzregeln. Nicht gegen nicht autorisierte Ziele verwenden. Die PoC-Strategie in diesem Dokument verifiziert nur das aus der Ferne sichtbare Verhalten eines NGINX-Worker-Crashs, enthält keine RCE, ASLR-Umgehung oder stabile Exploit-Kette.
CVE-2026-9256 ist eine Heap-basierte Pufferüberlauf-Schwachstelle im NGINX ngx_http_rewrite_module. Die Schwachstelle wird nicht einfach durch den Zugriff auf eine bestimmte URI ausgelöst, sondern hängt von einem spezifischen Rewrite-Konfigurationsmuster ab: Es gibt sich überschneidende PCRE-Erfassungsgruppen im Rewrite-Regex, und der Replacement-Teil referenziert mehrere Erfassungsvariablen, wie z. B. $1, $2.
Wenn ein Angreifer eine spezielle URI konstruiert, die die Rewrite-Logik in den relevanten Pfad führt, kann es bei der Verarbeitung des erfassten Inhalts, der Verkettung des Rewrite-Ergebnisses oder der URI/Parameter-Escape zu einer Diskrepanz zwischen der berechneten Länge und dem tatsächlichen Schreibvorgang kommen, was letztendlich zur Zerstörung des Heap-Speichers des Worker-Prozesses führt.
Daher liegt der Schlüssel dieser Schwachstelle nicht im Pfad /api selbst, sondern darin, ob in der Ziel-NGINX-Konfiguration eine anfällige Rewrite-Regel existiert, die durch eine Anfrage getroffen werden kann. Der im PoC standardmäßig verwendete /api-Pfad ist nur ein Beispielpfad in der aktuellen Replikationsumgebung. Bei tatsächlichen Tests muss der Anforderungspfad basierend auf der Rewrite-Regel in der NGINX-Konfiguration angepasst werden, die sich überschneidende Erfassungsgruppen enthält und mehrere Erfassungsvariablen referenziert.
Das aktuelle Ziel des PoC ist die Verifizierung des Worker-Crashs / Denial-of-Service-Verhaltens. Es wird nicht versucht, ein präzises Heap-Layout zu konstruieren, Rücksprungadressen oder Funktionszeiger zu überschreiben oder eine Remotecodeausführung nachzuweisen. Das auf der entfernten Seite stabil beobachtbare Indiz ist hauptsächlich: Die Trigger-Anforderungsverbindung wird abnormal getrennt, danach nimmt der NGINX-Dienst die Antwort wieder auf, und die Keep-Alive-Verbindung wird nach dem Auslösen durch den Worker-Crash unterbrochen.
Nach dem Auslösen dieser Schwachstelle zeigt sich nicht zwangsläufig ein fester HTTP-Statuscode wie 500, 502 oder 400. Der Grund ist das Master-Worker-Modell von NGINX: Wenn ein Worker-Prozess abstürzt, startet der Master einen neuen Worker. Was der Angreifer auf der entfernten Seite sieht, ist normalerweise nicht, dass der gesamte Dienst vollständig unerreichbar ist, sondern dass eine bestimmte Verbindung plötzlich getrennt wird, ein Lese-Timeout auftritt, die Verbindung zurückgesetzt wird, und ein erneuter Zugriff auf / wieder eine normale Antwort liefert.
Daher kann der PoC nicht allein anhand des HTTP-Statuscodes einer einzelnen Anfrage entscheiden, ob die Schwachstelle existiert. Wenn nur eine lange URI gesendet wird, die Verbindung getrennt wird und dann direkt "Schwachstelle vorhanden" gefolgert wird, ist das Fehlalarmrisiko hoch. Eine getrennte Verbindung kann auch von Netzwerkfluktuationen, Proxy-Zeitüberschreitungen, Abfangen durch ein Zwischengerät, serverseitigem Rate-Limiting oder aktivem Schließen der Verbindung durch den Server herrühren.
Daher muss der PoC als mehrstufige Verifikation ausgelegt sein:
Nur wenn "Trigger-Verbindungsanomalie + anschließende Dienstwiederherstellung + mehrfacher Keep-Alive-Ausfall" gleichzeitig auftreten, kann zuverlässiger auf das Vorhandensein eines CVE-2026-9256-artigen Worker-Crash-Verhaltens geschlossen werden.
Der zentrale Trigger-Pfad des aktuellen PoC ist:
GET /api/++++++++++++++++++++++++++++++++... HTTP/1.1
Host: 127.0.0.1:19321
Wobei /api/ das Beispiel-Routing in der aktuellen Testumgebung ist, um die Rewrite-Regel zu treffen, gefolgt von einer großen Anzahl von +-Zeichen. Die Standardanzahl beträgt 4096.
Die Wahl von + hat drei Hauptgründe:
Erstens ist + ein legales URI-Zeichen. Bei Verwendung mit einem normalen HTTP-Client wird es normalerweise nicht wie Leerzeichen, # usw. abgeschnitten oder zwangsweise umgeschrieben. Daher benötigt der aktuelle PoC nicht, wie bei einigen Request-Target-Bypass-Schwachstellen, einen Raw Socket, um eine illegale Request-Zeile zu konstruieren.
Zweitens kann eine große Anzahl sich wiederholender Zeichen den Rewrite-Erfassungsgruppen eine ausreichend lange Eingabe liefern, was den Ausgabeumfang der nachfolgenden Replacement-Verkettung oder Escape-Verarbeitung vergrößert und es so einfacher macht, eine Diskrepanz zwischen der berechneten Länge und dem tatsächlichen Schreibvorgang auszulösen.
Drittens ist die Payload-Struktur mit sich wiederholenden +-Zeichen einfach, was die Beobachtung in Paketmitschnitten, Logs und IDS-Regeln erleichtert und auch die Anpassung der Länge für Schwellenwerttests vereinfacht.
Es ist jedoch zu beachten, dass + nicht das einzige theoretische Auslöserzeichen der Schwachstelle ist. Die wahren Auslösebedingungen bleiben: "Treffen einer anfälligen Rewrite-Konfiguration + Eingabe, die in die relevanten Erfassungsgruppen gelangt + Rewrite-Ausgabeverarbeitung löst Heap-Überlauf aus". In verschiedenen Umgebungen müssen der Auslöserpfad, der Zeichentyp und der Längenschwellenwert möglicherweise angepasst werden.
Der aktuelle PoC verwendet standardmäßig eine große Anzahl von + als Auslöserzeichen, aber das bedeutet nicht, dass nur + das Problem auslösen kann. + ist nur das Zeichen, das sich am besten für einen allgemeinen PoC eignet, da es in URIs relativ stabil ist, leicht von normalen HTTP-Clients gesendet werden kann und seine Charakteristik in Paketmitschnitten klar ist.
Vom Prinzip der Schwachstelle her, solange ein Zeichen während der NGINX-Rewrite-Verarbeitung in die NGX_ESCAPE_ARGS-Escape-Logik gelangt und von einem ursprünglichen 1-Byte-Zeichen auf eine %XX-Form mit 3 Bytes expandiert wird, kann es zu einer Diskrepanz zwischen "berechnetem Längenwert und tatsächlichem Schreibwert" kommen. Das heißt, der Auslösepunkt ist nicht + selbst, sondern "das dichte Auftreten von Zeichen, die durch den Args-Modus escaped werden können".
Neben + sollten theoretisch besonders folgende Zeichen berücksichtigt werden:
Leerzeichen: 0x20
#: 0x23
%: 0x25
&: 0x26
?: 0x3F
Steuerzeichen: 0x00-0x1F
High-Byte-Zeichen: 0x7F-0xFF
Wenn diese Zeichen in die relevante Erfassung gelangen und im Rewrite-Replacement als Args-Inhalt für die Escape-Verarbeitung behandelt werden, erzeugen sie alle einen ähnlichen Expansionseffekt. Zum Beispiel:
+ -> %2B
& -> %26
% -> %25
# -> %23
? -> %3F
Leerzeichen -> %20
Jedes Auftreten eines solchen Zeichens expandiert theoretisch von 1 Byte auf 3 Bytes, was die tatsächliche Schreiblänge um 2 Bytes erhöht. Wenn die Eingabe viele solcher Zeichen enthält, kann die tatsächliche Schreiblänge die zuvor falsch berechnete Pufferlänge deutlich überschreiten, was das Auslösen eines Heap-Buffer-Overflows erleichtert.
Allerdings ist die Verwendbarkeit verschiedener Zeichen in einem PoC nicht identisch.
+ ist am stabilsten. Es kann normalerweise direkt im HTTP-Request-Target erscheinen, wird von Browsern oder Befehlszeilenwerkzeugen nicht so leicht abgeschnitten und verändert auch nicht von Natur aus die Path/Query-Struktur der URI. Daher verwendet der aktuelle PoC standardmäßig 4096 + als Payload.
& ist ebenfalls ein Kandidat, da es im Args-Modus zu %26 escaped wird. In der Shell hat & jedoch die Bedeutung einer Hintergrundausführung, und in URLs wird es oft als Trennzeichen für Query-Parameter verwendet. Daher ist beim Testen auf die Referenzierung und Position zu achten, da die Anfrage sonst möglicherweise nicht wie beabsichtigt gesendet wird.
% ist ebenfalls ein Kandidat, da es zu %25 escaped wird. % selbst ist jedoch auch ein Präfix für URL-Kodierung. Einige Clients, Proxies oder Frameworks könnten versuchen, %XX-Sequenzen zu interpretieren. Wenn die Konstruktion nicht korrekt ist, erhält das Ziel möglicherweise nicht das rohe %-Zeichen, sondern den vom Client vorverarbeiteten Inhalt.
? ist theoretisch auch ein escaped Zeichen, aber im HTTP-Request-Target trennt es Path und Query. Wenn es direkt im Pfad platziert wird, könnte der nachfolgende Inhalt als Query-String interpretiert werden, was den Rewrite-Erfassungsbereich verändert. Daher eignet es sich besser als ergänzendes Testzeichen, nicht als primäres Standard-PoC-Zeichen.
# kann theoretisch ein Escape auslösen, aber Browser senden # und den darauf folgenden Fragment-Identifier nicht an den Server. Viele fortgeschrittene HTTP-Clients kodieren oder schneiden es ebenfalls ab. Wenn man das literale # testen möchte, benötigt man in der Regel einen Raw Socket, Burp Repeater oder ein Werkzeug, das das ursprüngliche Request-Target beibehält; man kann sich nicht auf die Browser-Adressleiste verlassen.
Das Leerzeichen 0x20 ist ebenfalls ein Escape-Zeichen, aber in einer normalen HTTP/1.1-Request-Zeile ist das Leerzeichen selbst ein Trennzeichen. Wenn es direkt in das Request-Target gesetzt wird, würde es die Struktur der Request-Zeile zerstören. Wenn man stattdessen %20 schreibt, hängt es vom spezifischen Parsing-Prozess und der Rewrite-Position ab, ob der Server in der Verarbeitungsphase die kodierte Form oder das dekodierte Leerzeichen sieht. Daher eignet sich das Leerzeichen besser für Prinziperklärungen und Hilfstests, nicht als Standard-Payload.
Die Steuerzeichen 0x00-0x1F und High-Byte-Zeichen 0x7F-0xFF liegen ebenfalls im Escape-Bereich, aber in echten HTTP-Verbindungen werden sie leichter von Clients, Proxies, WAFs oder dem NGINX-HTTP-Parser abgefangen, normalisiert oder abgelehnt. Sie können als Erklärung von Escape-Objekten auf Quellcode-Ebene dienen, werden aber nicht als Standard-Auslöserzeichen für reguläre PoCs empfohlen.
Daher wird + im aktuellen PoC nicht verwendet, weil die Schwachstelle nur durch + ausgelöst werden kann, sondern weil + drei Bedingungen gleichzeitig erfüllt: Es kann die Args-Escape-Expansion auslösen, ist stabil sendbar und verändert die URI-Struktur nicht signifikant. Bei der Erstellung von Schutzregeln oder der Verkehrsanalyse sollte man sich nicht nur auf aufeinanderfolgende +-Zeichen konzentrieren, sondern auch auf hochdichte Kombinationen anderer escapebarer Zeichen achten, insbesondere auf das häufige Auftreten von Zeichen wie +, &, %, ?, # in langen URIs.
Aus Erkennungsperspektive ist eine vernünftigere Verallgemeinerung nicht:
Nach /api/ erscheint eine große Anzahl von +
Sondern:
In einer langen URI erscheint eine große Anzahl von Sonderzeichen, die im NGX_ESCAPE_ARGS-Modus zu %XX expandiert werden
Wenn man nur ++++ erkennt, deckt die Regel nur die Standardschreibweise des aktuellen PoC ab; wenn ein Angreifer die Payload in &&&&, %%%%, ???? ändert oder +%&?# mischt, könnte ein einzelnes +-Merkmal übersehen werden. Ein robusterer Erkennungsansatz ist die gemeinsame Bewertung von URI-Länge, Dichte der Sonderzeichen, Anzahl der Wiederholungen, riskanten Rewrite-Pfaden und der NGINX-Dienstexposition.
Die normalize_target-Funktion des PoC verarbeitet die Befehlszeileneingabe und unterstützt drei Formen:
python3 CVE-2026-9256-poc.py 127.0.0.1:19321
python3 CVE-2026-9256-poc.py 127.0.0.1 19321
python3 CVE-2026-9256-poc.py http://127.0.0.1:19321
Wenn der Benutzer nur host:port ohne Schema eingibt, ergänzt das Skript automatisch http://host:port. Anschließend wird mit urllib.parse.urlparse der Hostname und Port extrahiert und base generiert, z. B.:
host = 127.0.0.1
port = 19321
base = http://127.0.0.1:19321
Die aktuelle Implementierung ist hauptsächlich für HTTP-Klartext-Testumgebungen ausgelegt. Obwohl normalize_target die https://-Form akzeptiert, verwendet die spätere Keep-Alive-Erkennung einen normalen TCP-Socket ohne TLS-Schicht. Daher ist der Crash-Probe bei HTTPS-Szenarien ungenau. Für HTTPS-Unterstützung müsste dem Socket ssl.wrap_socket oder ssl.create_default_context().wrap_socket() hinzugefügt werden.
Der PoC ruft zunächst check_alive(base) auf, um den Stammpfad / zu erreichen:
GET /
Wenn das Ziel einen beliebigen HTTP-Statuscode zurückgibt, ist der Dienst grundsätzlich aktiv und die Tests können fortgesetzt werden. Bei Verbindungsfehler wird direkt abgebrochen, um zu vermeiden, dass ein unerreichbares Ziel fälschlicherweise als fehlgeschlagene Schwachstellenauslösung gewertet wird.
Anschließend wird check_rewrite(base) aufgerufen, um Folgendes zu erreichen:
GET /api/test
Diese Anfrage dient der Beobachtung, ob /api/* möglicherweise die Rewrite-Logik in der aktuellen Testumgebung trifft. Wenn ein Weiterleitungsstatuscode wie 301, 302, 303, 307, 308 zurückgegeben wird, deutet dies auf ein deutliches Rewrite-Redirect-Verhalten hin, und der PoC gibt den Location-Header als unterstützenden Beweis aus.
Dieser Schritt ist jedoch keine zwingende Erfolgsbedingung. In bestimmten Replikationskonfigurationen kann /api/* selbst in einen problematischen Rewrite-Pfad geraten, oder selbst normale Erkundungsanfragen können ein Timeout oder eine anomale Verarbeitung verursachen. Daher fährt das Skript auch dann mit der Trigger-Phase fort, wenn keine normale Rewrite-Antwort erhalten wurde.
Die Trigger-Funktion heißt send_trigger(base, plus_count=4096). Die Kernlogik ist die Verkettung:
payload = "/api/" + ("+" * plus_count)
Der endgültige Anforderungspfad sieht standardmäßig so aus:
/api/++++++++++++++++++++++++++++++++... insgesamt 4096 +
Dann wird die Anfrage über requests.get(base + payload, timeout=10, allow_redirects=False) gesendet.
Die automatische Weiterleitung wird hier aus zwei Gründen deaktiviert.
Erstens kann Rewrite selbst eine Weiterleitung zurückgeben. Wenn der HTTP-Client automatisch der Weiterleitung folgt, würden sich die ursprüngliche Trigger-Anfrage und die nachfolgende Weiterleitungsanfrage vermischen, was die Beurteilung erschwert, was bei der ersten Anfrage tatsächlich passiert ist.
Zweitens konzentriert sich der PoC auf den Verbindungsstatus während der Trigger-Phase, nicht auf die Geschäftsseite nach der Weiterleitung. Das Beibehalten der ursprünglichen Antwort erleichtert die Analyse.
Das Trigger-Ergebnis wird in mehrere Kategorien eingeteilt:
Wenn ein ConnectionError abgefangen wird, bedeutet dies, dass die Verbindung während der Trigger-Anfrage abnormal geschlossen wurde. Dies könnte eine entfernte Manifestation eines Worker-Crashs sein.
Wenn ein ReadTimeout abgefangen wird, bedeutet dies, dass nach dem Senden der Anfrage längere Zeit keine normale Antwort einging. Dies könnte ebenfalls auf einen hängenden Worker, einen fehlgeschlagenen Crash ohne normale Rückgabe oder ein durch die Netzwerkumgebung verursachtes Timeout hindeuten.
Wenn eine normale HTTP-Antwort empfangen wird, werden der Statuscode und die Länge des Antwortkörpers ausgegeben. Aus einer normalen Antwort kann jedoch nicht allein auf das Fehlen der Schwachstelle geschlossen werden, da in manchen Umgebungen die Auslösebedingungen möglicherweise nicht vollständig erfüllt sind oder die Payload-Länge nicht ausreicht.
Nach der Trigger-Anfrage wartet der PoC eine Sekunde und ruft dann follow_up(base) auf, um erneut den Stammpfad / zu erreichen.
Der Zweck dieses Schrittes ist nicht der Beweis des Überlaufs selbst, sondern die Beurteilung, ob NGINX das Merkmal "Worker-Crash, gefolgt von einem Neustart durch den Master" zeigt.
Wenn die Trigger-Anfrage-Verbindung abnormal getrennt wurde, die nachfolgende Anfrage an / aber wieder einen 200er oder einen anderen normalen HTTP-Statuscode zurückgibt, deutet dies darauf hin, dass der Dienst nicht vollständig ausgefallen ist, sondern eher ein einzelner Worker-Prozess abgestürzt und wiederhergestellt wurde.
Wenn der Dienst nach dem Auslösen längere Zeit unerreichbar ist, könnte dies auf einen Stillstand des gesamten Dienstes, einen Container-Crash oder eine Netzwerkanomalie hindeuten. Ein solches Ergebnis kann nicht direkt als erfolgreiche Auslösung von CVE-2026-9256 gleichgesetzt werden.
Daher lautet die Beurteilungsrichtlinie des aktuellen PoC: Aus der Ferne sichtbarer Worker-Crash, nicht einfach "Dienst nicht verfügbar".
Der kritischste Stabilitätstest im PoC ist keepalive_probe(host, port, rounds=5, plus_count=4096).
Es verwendet nicht requests, sondern baut direkt mit socket.create_connection eine TCP-Verbindung auf und sendet drei Anfragen nacheinander über dieselbe Keep-Alive-Verbindung.
Die erste Anfrage ist eine normale Anfrage:
GET / HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
Diese Anfrage dient dazu, die Verfügbarkeit der aktuellen Verbindung zu bestätigen und nach Möglichkeit sicherzustellen, dass die nachfolgende Trigger-Anfrage auf derselben Verbindung liegt.
Die zweite Anfrage ist die Trigger-Anfrage:
GET /api/++++++++++++++++++++++++++++++++... HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
Wenn diese Anfrage einen Worker-Crash auslöst, wird die von diesem Worker verwaltete Keep-Alive-Verbindung höchstwahrscheinlich direkt getrennt.
Die dritte Anfrage ist wieder eine normale Anfrage:
GET / HTTP/1.1
Host: 127.0.0.1
Connection: close
Wenn auf die dritte Anfrage noch eine Antwort eingeht, wurde die Verbindung durch die Trigger-Anfrage nicht unterbrochen, und diese Runde wird nicht als Worker-Crash gewertet.
Wenn das Senden der dritten Anfrage fehlschlägt, keine Daten gelesen werden können oder die Verbindung bereits geschlossen wurde, wird Folgendes protokolliert:
keepalive connection dropped
Der PoC wiederholt dies standardmäßig für 5 Runden. Der Sinn mehrerer Wiederholungen besteht darin, Fehlalarme durch gelegentliche Netzwerkfehler zu reduzieren. Wenn in den 5 Runden mehrfach ein Keep-Alive-Ausfall auftritt und der Dienst danach wieder antwortet, sind die Beweise von der entfernten Seite her solider.
Der PoC unterteilt die endgültige Beurteilung in drei Stufen.
Stufe 1: Schwachstelle bestätigt.
Die Bedingung ist:
crash_count > 0 and recovered == True
D. h., mindestens eine Runde der Keep-Alive-Erkennung hat einen Verbindungsausfall festgestellt, und die Follow-Up-Normalanfrage hat bestätigt, dass der Dienst wieder antwortet. Das Skript gibt aus:
VULNERABILITY CONFIRMED - CVE-2026-9256 style crash behavior
Impact confirmed: worker crash / denial of service
RCE is not proven by this script
Dies zeigt, dass die aktuelle Umgebung ein CVE-2026-9256-artiges Worker-Crash-Verhalten aufweist, beweist aber keine Remotecodeausführung.
Stufe 2: Schwachstelle vermutet.
Die Bedingung ist:
kind == "connection_error" and recovered == True
D. h., die Haupt-Trigger-Anfrage hat einen Verbindungsabbruch verursacht, und der Dienst hat sich später erholt, aber der Keep-Alive-Probe hat den Worker-Crash nicht stabil bestätigt. Das Skript gibt VULNERABILITY SUSPECTED aus.
Diese Situation zeigt an, dass anomale Phänomene vorliegen, die Beweise jedoch nicht stabil genug sind. Eine weitere Bestätigung durch serverseitige error.logs, Core-Dumps, Container-Logs oder Debugger ist erforderlich.
Stufe 3: Nicht bestätigt.
Wenn weder ein zuverlässiger Keep-Alive-Ausfall noch eine Kombination aus ausgelöstem Verbindungsabbruch und Dienstwiederherstellung vorliegt, gibt das Skript aus:
VULNERABILITY NOT CONFIRMED
Dies bedeutet nicht zwangsläufig, dass das Ziel absolut anfällig ist. Es könnte auch sein, dass der Pfad die Rewrite-Regel nicht trifft, die Payload-Länge unzureichend ist, die Zeichenauswahl nicht passt, die Zielversion bereits gefixt ist, ein vorgeschalteter Proxy die URI verändert hat oder das aktuelle Skript nicht an HTTPS angepasst ist.
Der Skriptablauf lässt sich wie folgt zusammenfassen:
host, port, base generieren./ anfragen, um die Dienstaktivität des Ziels zu bestätigen./api/test anfragen, um zu versuchen, die Aktivität des Beispiel-Rewrite-Pfades zu beurteilen./api/ und 4096 + als Trigger-Anfrage senden./ anfragen, um die Wiederherstellung des Workers zu bestätigen.crash_count, Trigger-Verbindungsstatus und Follow-Up-Wiederherstellung confirmed, suspected oder ausgeben.Lokales Testumgebungsbeispiel:
python3 CVE-2026-9256-poc.py http://127.0.0.1:19321
Oder:
python3 CVE-2026-9256-poc.py 127.0.0.1 19321
Bei erfolgreicher Auslösung zeigt die typische Ausgabe Folgendes:
[+] Connection dropped during trigger request
[+] Worker is responding after trigger (HTTP 200)
round 1: worker likely crashed (keepalive connection dropped)
round 2: worker likely crashed (keepalive connection dropped)
...
[+] VULNERABILITY CONFIRMED - CVE-2026-9256 style crash behavior
[+] Impact confirmed: worker crash / denial of service
[*] RCE is not proven by this script
Diese Ausgabe zeigt, dass auf der entfernten Seite relativ stabile Beweise für einen Worker-Crash beobachtet wurden.
Die Sicherheitsgrenzen dieses PoC sind relativ klar:
Erstens führt er nur eine Crash-Verifikation durch, keine RCE-Ausnutzung.
Zweitens konstruiert er kein Heap-Spray, ROP, ASLR-Umgehung, Shellcode oder Befehlsausführungslogik.
Drittens ist sein Erfolgskriterium der Ausfall der Worker-Verbindung und die Dienstwiederherstellung, nicht das Erlangen einer Shell oder das Lesen von Dateien.
Viertens eignet er sich für lokale Replikation, Schwachstellenverifizierung, Erstellung von IDS/IPS-Regeln und Vergleichstests vor und nach der Behebung.
Um die Sicherheit weiter zu erhöhen, könnten folgende Einschränkungen hinzugefügt werden:
127.0.0.1, localhost, private Adressen oder explizit autorisierte Testnetzsegmente erlauben.--plus-count-Parameter hinzufügen, um das Senden einer zu großen Payload standardmäßig zu vermeiden.--route-Parameter hinzufügen, damit der Benutzer den Trigger-Pfad explizit angeben kann, anstatt /api/ fest zu kodieren.--rounds-Parameter hinzufügen, um die Anzahl der Keep-Alive-Erkennungsdurchläufe zu steuern.--print-request-Debug-Parameter hinzufügen, um die tatsächlich gesendete HTTP-Anfrage auszugeben und den Vergleich mit Paketmitschnittergebnissen zu erleichtern.Aus der PoC-Ableitungsperspektive sollten Erkennungsregeln nicht nur auf /api/ starren, da /api kein fester Schwachstellenpfad ist, sondern nur ein Beispiel in der aktuellen Testumgebung. Wirklich wertvollere Erkennungspunkte sind:
+ oder eine Mischung aus Sonderzeichen wie +, &, %, ?, #.Wenn die Regel nur /api/++++ fest kodiert, deckt sie nur den aktuellen PoC und die aktuelle Testumgebung ab; für eine allgemeinere Abdeckung von Angriffsverkehr sollten Merkmale um "lange URI + viele dicht auftretende Sonderzeichen + HTTP-Anforderungsrichtung + riskante NGINX-Rewrite-Pfade" extrahiert werden.
Gleichzeitig, da auch legitimer Geschäftsverkehr lange URLs oder viele kodierte Zeichen enthalten kann, müssen Regeln durch Längenschwellenwerte, Zeichendichte, Wiederholungsanzahl und Pfadkontext Fehlalarme reduzieren. Ein robusterer Erkennungsansatz ist:
Lange URI
+
Viele Sonderzeichen, die durch NGX_ESCAPE_ARGS expandiert werden können
+
Anforderungsrichtung to_server
+
NGINX-Rewrite-bezogene Exposition
Nicht einfach:
/api/++++
Für Suricata-/Snort-Regeln kann man, wenn man nur den aktuellen öffentlichen PoC abdecken möchte, aufeinanderfolgende + als eines der starken Merkmale verwenden; wenn man Varianten abdecken möchte, muss der Bereich der Sonderzeichen in den PCRE aufgenommen werden, z. B. +, %, #, &, ? und andere Zeichen, die möglicherweise escaped/expandiert werden. Solche Regeln sind jedoch anfälliger für Fehlalarme und sollten in Verbindung mit urilen, Zeichenwiederholungsschwellenwerten, Pfadeinschränkungen und dem NGINX-Asset-Bereich verwendet werden.
Der Schwerpunkt der PoC-Ableitung für CVE-2026-9256 liegt nicht auf der Suche nach einem festen Schwachstellenpfad, sondern zunächst auf dem Verständnis der Auslösebedingungen: anfällige Rewrite-Konfiguration, sich überschneidende Erfassungsgruppen, Referenzierung mehrerer Erfassungsvariablen und spezielle URI-Eingabe, die zu einer anomalen Expansion der Rewrite-Verarbeitungsergebnisse führen kann.
Das aktuelle Skript wählt /api/ plus 4096 +, weil dieser Pfad die Rewrite-Regel in der aktuellen Replikationsumgebung trifft und eine große Anzahl von + stabil einen langen Eingabedruck erzeugt. Das Skript implementiert keine RCE, sondern beweist den Worker-Crash durch Verbindungsabbruch, Dienstwiederherstellung und mehrfachen Keep-Alive-Ausfall.
Gleichzeitig ist + nur das stabilste und am einfachsten zu sendende Standardzeichen, nicht das einzig mögliche Auslöserzeichen. Alle Zeichen, die im NGX_ESCAPE_ARGS-Modus zu %XX expandiert werden, sollten in der Prinzipanalyse und bei der Erstellung von Schutzregeln berücksichtigt werden. Ein genaueres Verständnis sollte sein: In einer langen URI treten dicht gedrängt escape-expandierbare Zeichen auf; nachdem sie in eine anfällige Rewrite-Erfassung und -Verarbeitung (Replacement) gelangen, wird eine Diskrepanz zwischen der berechneten Länge und dem tatsächlichen Schreibvorgang ausgelöst, was letztendlich zu einem Worker-Crash oder schwerwiegenderer Speicherbeschädigung führt.
not confirmed