Technische Analyse von CVE-2025-55182: Meine Forschungsreise

⚠️ Wichtiger Haftungsausschluss

Dieses Dokument beschreibt meinen persönlichen Forschungsprozess zu CVE-2025-55182, einschließlich bestätigter Erkenntnisse und Experimenten, die ich durchgeführt habe. Es stellt einen ehrlichen Bericht meiner Untersuchung dar, einschließlich anfänglicher falscher Annahmen und des letztendlichen Durchbruchs.

Zusammenfassung

Nach einer umfangreichen Untersuchung von CVE-2025-55182 (CVSS 10.0) war meine anfängliche Schlussfolgerung, dass eine automatische RCE nicht öffentlich demonstriert worden war und dass die Ausnutzung anwendungsspezifische Gadgets erforderte. Diese Schlussfolgerung war falsch.

Am 5. Dezember 2025 gelang es mir, nach zusätzlichen Erkenntnissen von einem weiteren unabhängigen Forscher auf X (@maple3142), vollständige nicht authentifizierte RCE auf vanilla Next.js zu reproduzieren, ohne dass anwendungsspezifische Code-Schwachstellen erforderlich waren.

Forschungsmethodik

Phase 1: Patch-Analyse (Anfängliche falsche Annahme)

Mein anfänglicher Fokus lag auf der ersten Änderung im React-19.0.1-Patch:

Verwundbar (19.0.0):

return fn.bind.apply(fn, [null].concat(_ref));

Gepatcht (19.0.1):

if (Array.isArray(promiseValue)) {
  promiseValue = promiseValue.slice(0);
} else {
  promiseValue = [];
}

Ich nahm an, dass der Angriffspfad über fn.bind.apply() mit bösartigen Objekten anstelle von Arrays verlief. Ich konnte die Argumentinjektion in Server Actions mithilfe von $ACTION_REF_ mit einem angreiferkontrollierten bound demonstrieren:

curl -X POST http://localhost:9000/ \
  -F '$ACTION_REF_0=' \
  -F '$ACTION_0:0={"id":"<ACTION_ID>","bound":["; id #","/etc/passwd"]}'

Ergebnis: Die Argumente wurden erfolgreich in die Server Action injiziert. Dies führt jedoch nur dann zu RCE, wenn die Zielfunktion diese Argumente unsicher verwendet.

Phase 2: Unsicheres Verhalten im Patch beobachtet

Ein genauerer Blick auf den Patch offenbarte eine weitere wichtige Änderung in getOutlinedModel():

Verwundbar:

for (key = 1; key < reference.length; key++)
  parentObject = parentObject[reference[key]];

Gepatcht:

if (hasOwnProperty.call(value, name)) {
  value = value[name];
}

Dieses verwundbare Verhalten erlaubte die Traversierung der Prototypenkette mithilfe von Referenzen wie:

$1:__proto__:constructor:constructor

Phase 3: Experiment mit Thenable und Function.constructor (Sackgasse)

Während der Forschung testete ich ein Thenable-Objekt mit einer .then-Eigenschaft:

{"then": "$1:__proto__:constructor:constructor"}

Wenn JavaScript dies über await verarbeitet:

1. JavaScript sieht eine .then-Eigenschaft und behandelt das Objekt als Promise
2. Ruft obj.then(resolve, reject) auf
3. Wenn then zu Function.constructor aufgelöst wird, versucht JavaScript, Function(resolve, reject) auszuführen

Beobachtetes Ergebnis:

SyntaxError: Unexpected token 'function'
    at Object.Function [as then] (<anonymous>)

Phase 4: Die Grenze der Argumentbindung (Die Wand)

Wenn Function.constructor wie folgt aufgerufen wird:

Function(resolve, reject)
// resolve.toString() = "function () { [native code] }"
// Function attempts to parse this as code → SyntaxError

Die Argumente resolve und reject sind immer die nativen Promise-Funktionen. Function versucht, das erste Argument als Quellcode zu interpretieren, was ungültiges JavaScript ist.

Hier kam meine Forschung ins Stocken. Ich schlussfolgerte, dass die Kontrolle der Argumente für Function.constructor ohne ein anwendungsspezifisches Gadget unmöglich war.

Phase 5: Der Durchbruch — Blob-Deserialisierung (5. Dezember 2025)

Nach der Veröffentlichung meiner ersten Erkenntnisse wies mich ein weiterer unabhängiger Forscher auf ein kritisches Element hin, das ich übersehen hatte: den $B-Deserialisierungs-Sink (Blob).

Das fehlende Puzzlestück

Im kompilierten React-Flight-Servercode (in den TypeScript-Quellen nicht sichtbar) existiert:

case "B":
  return response._formData.get(response._prefix + id);

Fundort:

• Paket: [email protected]
• Datei: cjs/react-server-dom-webpack-server.node.unbundled.development.js
• Auch in: [email protected]/dist/compiled/react-server-dom-webpack/

Dieser Code erlaubt React, response._formData.get() mit Werten aufzurufen, die aus angreiferkontrollierter Eingabe abgeleitet sind, ohne Validierung.

Warum dies alles verändert

Durch die Kombination von:

1. Prototypen-Traversierung ($1:__proto__:then → Chunk.prototype.then)
2. Einem vergifteten _response-Objekt mit:
   • _formData.get gesetzt auf Function.constructor
   • _prefix gesetzt auf beliebigen JavaScript-Code
3. Einem inneren Modell mit einer $B-Referenz

Der case "B":-Handler führt Folgendes aus:

Function.constructor("<attacker code>" + id)

Dies umgeht die Grenze der Argumentbindung vollständig.

Öffentliche PoCs: Analyse

Beliebte GitHub-PoCs, die vorgeben, RCE zu ermöglichen, verwenden Action-IDs wie:

• "child_process#execSync"
• "vm#runInThisContext"

Diese sind gefälscht. Next.js akzeptiert nur von der Anwendung definierte Action-IDs. Ungültige IDs erzeugen:

TypeError: Cannot read properties of undefined (reading 'workers')

Der echte Exploit erfordert jedoch keine gefälschten Action-IDs. Jede gültige Server-Action-ID funktioniert.

Verifizierung und Auswirkungen

Ich testete diese Ausnutzungskette auf einer minimalen Next.js 15.0.3 + React 19.0.0-Anwendung mit nur:

async function myAction(data) {
  "use server";
  console.log("Server Action called with:", data);
  return { success: true, received: data };
}

Ergebnis: Vollständige RCE bestätigt. Die Anwendung enthielt keinen unsicheren Code, kein eval, kein execSync, keine Gadgets.

Auswirkungsbewertung

Kritische Entdeckung: Patch-Status

Stand 5. Dezember 2025 existiert der $B-Sink weiterhin in Next.js 15.0.5 (der angeblich gepatchten Version).

Verifizierung:

$ npm pack [email protected]
$ tar -xzf next-15.0.5.tgz
$ grep -A5 'case "B":' package/dist/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-server.node.development.js

Ergebnis:

case "B":
  return response._formData.get(response._prefix + obj);

Der Code ist identisch mit der verwundbaren Version.

Hinweis zur verantwortungsvollen Offenlegung

Aufgrund der Entdeckung, dass die Schwachstelle in den behaupteten „behobenen" Versionen möglicherweise nicht vollständig gepatcht ist, halte ich das vollständige Proof-of-Concept-Payload zurück, bis die Verifizierung mit den Sicherheitsteams von Vercel und Meta abgeschlossen ist.

Die in diesem Dokument bereitgestellten technischen Details reichen aus, um den Schwachstellenmechanismus zu verstehen, sind jedoch absichtlich unvollständig, um eine sofortige Ausnutzung zu verhindern.

Aktualisierte Schlussfolgerungen

Was ich gefunden habe (Phasen 1-4)

Was ich anfänglich übersehen habe

Abschließende Bewertung

CVE-2025-55182 ist für vollständige nicht authentifizierte RCE auf vanilla Next.js-Anwendungen ausnutzbar.

• ✅ Kein anwendungsspezifisches Gadget erforderlich
• ✅ Funktioniert mit einem einzigen HTTP-POST
• ✅ Das „Gadget" ist in die Deserialisierungslogik von React eingebaut
• ⚠️ Möglicherweise in behaupteten behobenen Versionen nicht vollständig gepatcht

Zeitleiste

• 3. Dezember 2025: Analyse der Prototypen-Traversierung und des Thenable-Ansatzes (Sackgasse)
• 4. Dezember 2025: Einblicke zur $B-Deserialisierung von einem unabhängigen Forscher erhalten
• 5. Dezember 2025: Vollständige RCE-Reproduktion bestätigt
• 5. Dezember 2025: Entdeckt, dass die Schwachstelle in „gepatchten" Versionen fortbestehen könnte
• 5. Dezember 2025: Dieser Bericht veröffentlicht (PoC-Details zurückgehalten)

Empfehlungen

1. Sofort aktualisieren auf die neuesten Versionen von React und Next.js
2. Den Patch verifizieren, indem getestet wird, ob die $B-Deserialisierung weiterhin beliebige _response-Objekte akzeptiert
3. Auf Ausnutzungsversuche überwachen - achten Sie auf:
   • Ungewöhnliche Next-Action-Header
   • Komplexe Multipart-Payloads mit Mustern wie $@, __proto__, $B
4. WAF-Regeln in Betracht ziehen, um verdächtige Muster in Server-Action-Anfragen zu blockieren
5. Sicherheitsteams kontaktieren, wenn Sie betroffene Versionen in der Produktion einsetzen

Danksagungen

• Der bahnbrechende Einblick bezüglich der $B-Deserialisierung wurde von einem Forscher auf X (@maple3142) bereitgestellt
• Den Sicherheitsteams von React und Next.js für ihre Arbeit an Patches (laufende Verifizierung)
• Der Sicherheitsforschungsgemeinschaft für die gemeinschaftliche Untersuchung

Gelernte Lektionen

1. Kompilierten Code untersuchen, nicht nur Quellen - Kritische Schwachstellen können sich im gebündelten Output verstecken
2. Annahmen überdenken, wenn neue Informationen auftauchen
3. Gemeinschaftliche Forschung ist für komplexe Schwachstellen unerlässlich
4. Die Reise dokumentieren - Sackgassen sind wertvoll, um das Gesamtbild zu verstehen
5. Verantwortungsvolle Offenlegung hat Vorrang vor öffentlicher Anerkennung

Zuletzt aktualisiert: 5. Dezember 2025