OrcaCyber Research – PHP2Shell: Wie eine fehlgeschlagene Anfrage zu Remote Code Execution führte

Der Proof of Concept in dieser Untersuchung wurde mit OrcaCyber Zero und OrcaCyber UltraModellen erstellt. Das Forschungspaket dokumentiert eine Analyse auf Quellcodeebene, eine kontrollierte Reproduktion mit einem angepassten öffentlichen Exploit, ein Artefakt zur Offenlegung von Speicherinhalten, Prozessabstürze und Belege für Befehlsausführung. Die bereitgestellten Dateien erfassen nicht unabhängig, welche Schritte von welchem Modell durchgeführt wurden; die Modellzuordnung wird vom Forschungsteam bereitgestellt.

Eine fatale Out-of-Memory-Situation sollte eine Anfrage sicher beenden. Hier könnte sie PHP unterbrechen, während der native Zustand erst teilweise initialisiert war, und Referenzen hinterlassen, die bis in die nächste Anfrage bestehen blieben. Das Ergebnis war eine anfragenübergreifende Verletzung der Speicherlebensdauer mit Folgen, die von Offenlegung bis hin zu Remotecodeausführung in der getesteten Umgebung reichten.

Wichtigste Belege auf einen Blick

• Target — PHP 8.4.26, Apache/mod_php, einzelner Worker, isoliertes Docker-Lab.

• Absturzprotokolle — Ein SIGABRT und drei SIGSEGV-Worker-Beendigungen im bereitgestellten Auszug.

• HTTP-Antwort — 819.200 Bytes im URL-dekodierten PHPSESSID-Wert.

• Ausführungsnachweis — code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>.

• Regression — Der Bericht beschreibt vier erfolglose Versuche mit gepatchtem PHP 8.4.27; Rohläufe sind nicht mitgeliefert.

Quelle: hochgeladene REPORT.md, crash_evidence.log, leak_attempt.resp und rce_proof_8426.txt. Die unten beschriebenen Anlagen geben diese Artefakte als gesetzte Beweispaneele wieder; es handelt sich weder um Fotografien noch um native Terminal-Screenshots.

1. Die Schwachstelle: Fehlende Zuständigkeitszuordnung an der Anfragegrenze

Die beiden zusammenhängenden Probleme betreffen unterbrochene Request-Initialisierung und veraltete laufzeitglobale Zeiger. In der betreffenden PHP-Architektur können die Verarbeitung von multipart/form-data und Session-Upload-Fortschritts-Callbacks vor normalem Benutzeranwendungscode ausgeführt werden. Ein außergewöhnlicher Kontrollflussübergang, einschließlich code>zend_bailout()/code>, kann die erwartete Bereinigung überspringen und einen Zustand hinterlassen, der auf Speicher zeigt, der später freigegeben oder wiederverwendet wird.

Sicherheitsinvariante: Eine worker-globale Referenz, die Anfrage B ausgesetzt wird, darf niemals auf Speicher verweisen, dessen Eigentümerschaft und Lebensdauer mit Anfrage A geendet haben. Der gemeldete Fehler verletzt diese Invariante.

Der demonstrierte Endpunkt war eine minimale PHP-Seite, die einfach OK zurückgab; das Exploit-Narrativ hing nicht von SQL-Injection-, File-Inclusion- oder Deserialisierungs-Endpunkten auf Anwendungsebene ab.

2. Technischer Ablauf

• A1 — Unterbrechung. Die Behandlung von Multipart- und Upload-Fortschritt löst während der Bereinigung OOM aus und hinterlässt veralteten Sitzungsstatus.

• B1 — Leck. Eine nachfolgende Anfrage führt dazu, dass die Serialisierung des Session-Cookies über eine gültige Session-ID hinausliest.

• Adresswiederherstellung. Durchgesickerte Zeigerwerte werden genutzt, um auf das relevante Bibliotheks- und Heap-Layout in diesem Build zu schließen.

• A2/B2 — Korruption. Eine weitere Zwei-Anfragen-Sequenz formt und leitet veraltete Daten um, die beim Herunterfahren verwendet werden.

• Ergebnis. Der angepasste öffentliche Exploit meldet Befehlausführung als www-data.

Beweismittel: was die bereitgestellten Dateien tatsächlich zeigen

Anlage A — Worker-Beendigung aus dem Apache-Log

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 54 exit signal Abort (6), possible coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: Kindprozess mit PID 55 wurde durch Signal Segmentation Fault (11) beendet, möglicher Coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: Kindprozess 58 beendet mit Signal Segmentation Fault (11), mögliches Coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: Kindprozess mit PID 61 wurde durch Signal Segmentation Fault (11) beendet, möglicher Coredump in /etc/apache2/code>

Gesetzter Auszug aus crash_evidence.log (23. Oktober 2026). Mehrere Worker-Beendigungen stützen die Annahme eines Speichersicherheitsfehlers; allein durch Abstürze lässt sich keine RCE belegen.

Anhang B — HTTP-Antwort mit anomalem Session-Cookie

• code>HTTP/1.1 200 OK/code>, wobei Binärdaten ausgelassen wurden.

• code>Server: Apache/2.4.69 (Debian)/code>

• code>X-Powered-By: PHP/8.4.26/code>

• code>Set-Cookie: PHPSESSID=[Binärdaten ausgelassen]/code>

• Länge des codierten Cookies: 2.330.754 Bytes.

• URL-dekodierter Wert: 819.200 Bytes.

Die Messung wurde direkt aus leak_attempt.resp berechnet. Der Binärwert wird absichtlich weggelassen, um die Wiedergabe jeglicher geleakter Prozessinhalte zu vermeiden.

Anlage C — Vollziehungsnachweis

code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>

Exakter Inhalt von rce_proof_8426.txt, wie geliefert. Er stützt das gemeldete Ausführungsergebnis, ist jedoch kein vollständiges Befehls-/Sitzungsprotokoll.

Anlage D — Behebung des Sitzungslebenszyklus

• code>static inline void php_rinit_session_globals(void)/code>

• code>@@ -121,6 +120,7 @@ static inline void php_rinit_session_globals(void)/code>

• code>* kodiert die Session beim Request-Start neu, vor RINIT, wenn kein Benutzer/code>

• code>/* Wird vor RINIT ausgeführt: Es darf kein Benutzercode aufgerufen werden, siehe php_session_unserialize_init() *//code>

• code>/* Dies wird vor RINIT ausgeführt, daher müssen wir diese frühzeitig leeren *//code>

• code>php_rinit_session_globals();/code>

Ausgewählte Quelldiff-Zeilen aus session.c.diff. Diese Änderung setzt den sitzungsglobalen Zustand ausdrücklich früher als bei regulärem RINIT zurück.

3. Warum die Beweislage wichtig ist

Die Speicherofflegung bildet die Brücke zwischen einem Prozessabsturz und einer Exploit-Kette. Ein Sitzungswert mit anormaler Größe und eingebetteten Binärdaten ist konsistent damit, dass die Laufzeit ungültigen Speicher als Zend-String interpretiert. Der Forschungsbericht beschreibt außerdem das Extrahieren von Code- und Heap-Adressen aus dem geleakten Fenster. Das Evidenzbündel enthält die Rohantwort, aber kein eigenständiges Skript, das jede wiederhergestellte Adresse belegt.

Das RCE-Artefakt zeigt den Sicherheitskontext von www-data. Es belegt weder Root-Zugriff noch die Kompromittierung einer Produktionsumgebung noch vollständige Portabilität auf beliebige PHP-Deployments. Die Laborumgebung mit einem einzigen Worker ist wichtig, weil die Anfragereihenfolge und die Worker-Affinität den Mechanismus beeinflussen.

4. Eine Korrektur des zugrunde liegenden Lebenszyklus, nicht nur des Symptoms

Der bereitgestellte Quelltext-Diff für den PHP-Patch-Commit 01a40e89fbfc („Avoid state corruption via bailout“) zeigt eine frühe Initialisierung der Session-Globals, Änderungen an der OOM-Behandlung des Allocators und eine umfassendere Reset-/Cleanup-Logik. Diese Änderungen sollen verhindern, dass nativer Zustand einen unterbrochenen Request in einem ungültigen Zustand überlebt. Nur den Cookie-Encoding-Pfad zu korrigieren würde diese Speicher-Eigentumsgarantie nicht für sich genommen wiederherstellen.

Der Forschungsbericht stellt fest, dass Versuche gegen PHP 8.4.27 in vier Durchläufen weder den abnormalen Cookie noch einen Absturz oder einen RCE-Nachweis hervorbrachten. Die tatsächlichen Transkripte der gepatchten Version sind nicht in diesem Paket enthalten, daher wird dieser Vergleich als Beobachtung des Forschers und nicht als unabhängig überprüfbares Beweisstück gemeldet.

5. Abwehrmaßnahmen

• Sofort.Aktualisieren Sie die betroffene unterstützte PHP-Versionslinie auf ihre sicherheitskorrigierte Version und prüfen Sie anhand der Anbieterhinweise den genauen Status des Pakets.

• Reduzierung der Angriffsfläche. Erwägen Sie, Multipart-Eingaben einzuschränken und code>session.upload_progress/code> zu deaktivieren, falls nicht verwendet; diese ersetzen den Patch nicht.

• Erkennung. Überprüfen Sie Abstürze während der Initialisierung von Anfragen, unerwartete 500er-Fehler und übermäßig große code>Set-Cookie/code>-Antwortheader.

• Zusicherung. Erneut mit produktionsnahen Worker-Pools testen und verifizieren, dass alter Sitzungszustand nicht über Anfragen hinweg bestehen bleiben kann.

6. Forschungsmethodik von OrcaCyber

Die wertvolle Forschungsaufgabe besteht nicht nur darin, einzelne unsichere Operationen zu erkennen; sie besteht darin, eine vollständige Invariantenverletzung über Request-Parsing, Allokatorverhalten, persistente native Globals, Serialisierung und Herunterfahren hinweg nachzuvollziehen. OrcaCyber Zero und OrcaCyber Ultra wurden verwendet, um den PoC in dieser Untersuchung zu erstellen, wie vom Forschungsteam zugeschrieben. Der öffentliche Artefaktsatz unterstützt die technische Reproduktion, liefert jedoch keine modellbezogenen Ausführungsspuren und belegt auch nicht die autonome Entdeckung von Schwachstellen.

Evidenzleiter: Quellhypothese → erreichbarer Auslöser → Laufzeitfehler → Offenlegung von Informationen → Ausführungsnachweis → Regression der behobenen Version. Diese Reihenfolge schafft stärkeres Vertrauen als eine Schwachstellenbeschreibung oder ein reines Absturzergebnis. Sie fördert zudem eine klare Berichterstattung über Unsicherheiten, wenn Quelldateien oder Rohausführungsprotokolle fehlen.

7. Geltungsbereich und Einschränkungen

Diese Veröffentlichung beschreibt ein autorisiertes isoliertes Docker-Labor. Der Exploit basiert auf der zuvor veröffentlichten PHP2Shell-Forschung, wobei die lokale Anpassung im bereitgestellten Bericht dokumentiert ist. Das Paket enthält Skripte, Diffs, Antwort-Bytes, Logs und Proof-Ausgaben, lässt jedoch den vollständigen Upstream-Exploit-Checkout, native Screenshots und vollständige rohe Patch-Regressions-Transkripte aus. Es wird keine Kompromittierung echter Opfer oder Kunden behauptet.

Quellen und Artefakte

Primär: bereitgestelltes php2shell-report-bundle.tar.gz (REPORT.md; report-CVE-2026-109618.md; report-CVE-2026-109619.md; crash_evidence.log; leak_attempt.resp; rce_proof_8426.txt; PHP-Quellcode-Diffs). Öffentlicher Kontext: PHP-Sicherheitshinweise GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp; Ankündigungen zu PHP-Sicherheitsreleases. Öffentliche Exploit-Zuordnung: 9bie/php2shell-bypass-aslr-exp. Forschungs-Repository: orcacyber-php2shell-research.

Fazit: Eine Anfrage schlug fehl; ein Zeiger überlebte; die nächste Anfrage vertraute ihm. Das Schwierige daran, diese Schwachstelle zu verstehen, ist, diese Verbindung mit beobachtbaren Belegen herzustellen.