Wichtigste Verbesserungen

Probleme mit der Originalversion

Das ursprüngliche Exploit-Skript verwendete requests.post(files=...) zum Erstellen von Multipart-Anfragen. So praktisch es auch war, dieser Ansatz führte zu kritischen Zuverlässigkeitsproblemen:

• Automatische Boundary-Erzeugung: Die requests-Bibliothek erzeugt automatisch eine Boundary und fügt einen eigenen Content-Type-Header hinzu
• Inhaltsumwandlung: Kann den Payload-Inhalt escapen oder umwandeln (z. B. Anführungszeichen, Zeilenumbrüche, JSON-Strukturen) und so die empfindliche Flight-Protokoll-Deserialisierung stören, die der Server erwartet
• Umgebungskompatibilität: In strengen Parser-, Proxy- oder WAF-Umgebungen führt dies zu fehlerhaften Anfragen oder stillen Fehlern
• Erkennungsfehler: Der --check-Modus meldete häufig fälschlich „nicht verwundbar“, weil die Payload-Formatierung abwich

Lösung

Diese Version gewährleistet Kompatibilität und Zuverlässigkeit durch die folgenden Ansätze:

✅ Manuelle Multipart-Erstellung: Wird aus Rohbytes aufgebaut und bewahrt so die exakte Payload-Semantik

✅ RFC-konforme Boundary: Automatisch generiert mit uuid.uuid4() für eine gültige Boundary-Erzeugung

✅ Korrekter Content-Type: Setzt den Content-Type-Header explizit so, dass er zum Roh-Body passt

✅ Kein automatisches Escaping: Bewahrt die Integrität der _prefix- und Prototype-Pollution-Felder

✅ Einheitliche Anwendung: Wendet dieselbe Roh-Multipart-Logik in beiden Methoden an:

• execute()-Methode (für die Befehlsausführung)
• check_vulnerability()-Methode (für eine genaue Erkennung)

Dies gewährleistet Konsistenz zwischen Erkennung und Ausnutzung und verbessert die Erfolgsquoten bei verschiedenen Next.js-Bereitstellungen erheblich.