PHP2Shell: CVE-2026-109618 und die Runtime-Grenze

Die Anfrage erreicht PHP vor Ihrem Controller

Ihre Anwendung kann einen Upload ablehnen, nachdem PHP bereits einen Teil des Request-Bodys verarbeitet hat. Diese Reihenfolge verlangt bei einer Runtime-Schwachstelle eine andere Untersuchung als bei einem unsicheren Upload-Controller. Bei CVE-2026-109618 und CVE-2026-109619, öffentlich als PHP2Shell diskutiert, geht es darum, wo kontrollierbare Anfragedaten eine Sicherheitsgrenze im Interpreter überschreiten.

Ich betrachte drei Ebenen: das bestätigte Sicherheitsrelease, das im Quellcode erkennbare Laufzeitverhalten und den Mechanismus der geprüften Implementierungen. Diese Bewertung vom 21. Oktober 2026 beruht auf statischer Analyse von PHP 8.4.4, relevantem PHP-8.5.4-Code, Proof-of-Concept-Implementierungen, Berichten und einer geprüften Demonstration. Eine unabhängige Reproduktion des Exploits wurde nicht durchgeführt.

Was PHP bestätigt hat

PHP bestätigt in der Mitteilung vom 20. Oktober zwei kritische Schwachstellen mit jeweils CVSS v4.0 9.2. Das Sicherheitsrelease ist für den 21. Oktober um 14:00 UTC angekündigt. Die eingesehene Vorankündigung behält betroffene und korrigierte Versionen sowie technische Details dem Release vor. Sie nennt selbst weder die CVE-Nummern noch Upload-Fortschrittsverfolgung als Ursache. Die Kennungen und die RCE-Beschreibung stammen aus der zugehörigen öffentlichen Berichterstattung. [1, 2]

Der Huntress-Bericht schreibt watchTowr die Reproduktion von CVE-2026-109618 zu. Huntress erklärt zugleich, die Probleme zum Stand vom 20. Oktober weder selbst reproduziert noch entsprechende Angriffe in Partnerumgebungen beobachtet zu haben. Die Demonstration zeigt Effekte, die mit Befehlsausführung und Dateierstellung vereinbar sind, unter anderem bei WordPress und Drupal. Die gezeigte Implementierung des Demonstrationswerkzeugs wurde den hier geprüften Implementierungen nicht zugeordnet. Diese Beobachtungen begründen Dringlichkeit; genaue Ursache und Voraussetzungen bleiben zu bestimmen. [2]

Warum der Upload-Fortschritt untersucht werden muss

PHP kann während der Verarbeitung eines Multipart-Uploads Fortschrittsinformationen in der Session führen. Dazu gehören ein Gesamtzähler, Dateizähler, Metadaten und Abschlussmarkierungen. Diese Funktion arbeitet innerhalb der Anfrageverarbeitung. Das sichtbare Upload-Formular beschreibt deshalb nicht die gesamte Angriffsfläche der Laufzeitumgebung. Das PHP-Handbuch dokumentiert die Funktion und ihre einstellbare Aktualisierungshäufigkeit. [3]

Im untersuchten Code legt FILE_START den Dateizustand an, FILE_DATA aktualisiert Zähler und END beendet die Verfolgung oder räumt Daten auf. Der Gesamtzählerzeiger wird bei der ersten Konstruktion gespeichert; der Zeiger für die aktuelle Datei wird für jede Datei erneuert. Zählerschreibzugriffe erfolgen vor dem Session-Update-Helfer. Authentifizierung im Anwendungscode schützt daher nicht automatisch die frühere Parser-Verarbeitung. Eine Zugriffskontrolle am Proxy vor der Übergabe an PHP setzt an einer anderen Grenze an. [4]

Die vorgeschlagene Kette in einzelnen Phasen

Eine geprüfte Proof-of-Concept-Implementierung ordnet die erste Kennung dem Gesamtzähler zu; eine andere ordnet die zweite dem Zähler der aktuellen Datei zu. Beide beschreiben einen veralteten Zeiger bei wiederholten Fortschrittsupdates. Diese Zuordnung stammt aus den geprüften Implementierungen, nicht aus der eingesehenen Herstellerankündigung. Das Modell setzt Erreichbarkeit, angelegten Fortschrittszustand, eine Freigabe vor einem späteren Zugriff und nutzbare Kontrolle über den beschädigten Zustand voraus.

Für RCE werden zusätzlich ein erreichbarer Ausführungspfad sowie zur Zielversion passende Adressen und Strukturen benötigt. Die Demonstration zeigt eine Phase zur Adressoffenlegung; die lokale Symbolextraktion des Frameworks belegt keine entsprechende entfernte Offenlegung. Frühere Allokationen beweisen keine spätere Wiederbelegung eines bestimmten freigegebenen Bereichs. Zwei zeitversetzte Socket-Schreibvorgänge beweisen ebenso wenig zwei passende Server-Callbacks. Eine funktionierende Kette muss diese eigenständigen Bedingungen verbinden; die geprüften Implementierungen lassen diese Verbindung unvollständig.

Die Lebensdauerfrage: Wer besitzt das Array noch?

Use-after-free bezeichnet einen Zugriff auf eine Allokation nach dem Ende ihrer Lebensdauer. P sei das aktive Fortschrittsarray, D ein separat dekodiertes Session-Array. Gleicher Inhalt bedeutet keine identische Allokation. Im gewöhnlichen erfolgreichen Update-Pfad von PHP 8.4.4 erhöht der Helfer den Referenzzähler, bevor P in den Session-Baum eingefügt wird. Dessen Zurücksetzen gibt seine Referenz frei; der Fortschrittszustand besitzt P weiterhin. Das Ersetzen von D gibt P nicht frei. Die entsprechende Referenzerhöhung existiert auch im untersuchten PHP-8.5.4-Helfer. [4, 5, 6, 7]

Dieses Besitzmodell ist das ungeklärte Glied der vorgelegten Erklärung. Es entkräftet weder die CVEs noch die separate Demonstration. Eine vollständige Ursachenanalyse muss einen anderen Pfad oder eine Bedingung benennen, die die Lebensdauergarantie bricht. Selbst die Trennung am Anfrageende verlangt eine Reihenfolgeanalyse: Bei deaktivierter Bereinigung besitzt der alte Session-Baum das ursprüngliche Array noch beim letzten Zählerschreibzugriff, vor erzwungenem Update und Abbau. Ein veralteter Zeiger allein genügt ohne späteren Zugriff nicht. [4]

Session Poisoning überschreitet eine andere Grenze

Ein geprüfter Laborbericht Dritter beschreibt einen zweiten Weg zur Codeausführung: Vom Angreifer kontrollierte Sitzungsdaten gelangen zu einer Dateieinbindung in der Anwendung. Der bewusst verwundbare Testendpunkt übergibt einen Anfrageparameter unmittelbar an include(). Das Persistenzprofil deaktiviert die Bereinigung der Fortschrittsdaten und verändert Aktualisierungsintervalle sowie Multipart-Grenzen. Das Protokoll im Bericht meldet Codeausführung unter diesen Bedingungen. Damit zeigt es eine relevante Prüfgrenze in der Anwendung, belegt aber nicht unabhängig den Speicherfehler einer der beiden CVEs.

Der Bericht beschreibt außerdem über die Wahl einer Sitzungs-ID ohne Cookie-Header, Session Fixation in einer bewusst nachlässigen Login-Testanwendung und einen Serialisierungsfehler bei einem senkrechten Strich im Fortschrittsschlüssel. Diese Beobachtungen hängen vom Handler, Serializer, der Sitzungsrichtlinie und dem Anwendungsverhalten ab. Sitzungsinhalte müssen Daten bleiben; Pfade für include/require sollten aus einer kontrollierten Positivliste stammen, und bei einem Wechsel in den authentifizierten Zustand sollte die Sitzungs-ID erneuert werden. Ein Fortschrittseintrag allein belegt keine Wiederverwendung freigegebenen Speichers.

Das Ergebnis uid=0 im Protokoll beschreibt die Identität des Laborprozesses. Das Startskript führt den PHP-Entwicklungsserver ohne Angabe eines eingeschränkten Benutzers aus; die Ausgabe belegt daher weder eine Rechteausweitung noch Root-Zugriff auf den Host. Für die Absicherung ist diese Trennung wesentlich: Sichere Dateieinbindung und Sitzungsrichtlinien reduzieren Risiken auf Anwendungsebene, während ein Speicherfehler der Laufzeit weiterhin einen eigenen Herstellerpatch benötigt.

Betroffene Versionen und Exploit-Kompatibilität

Die eingesehene Herstellerankündigung enthält weder einen bestätigten Versionsbereich noch eine Matrix korrigierter Versionen. Pauschale Aussagen zu PHP ab Version 5 bleiben Angaben aus öffentlichen Berichten. PHP 8.4.4 ist unsere Quellcode-Basis; PHP 8.5.4 erscheint im geprüften Material und einem angezeigten Demonstrationsprofil. Keine dieser Beobachtungen bestimmt den gesamten betroffenen Bereich. Dies ist eine Momentaufnahme der Belege. Paketentscheidungen müssen sich auf das detaillierte Hersteller-Advisory stützen. [1, 8]

Eine Schwachstelle kann mehrere Versionszweige betreffen, während ein Exploit nur eine Architektur, einen Paketbuild oder eine Serverintegration unterstützt. Umgekehrt beweist ein fehlgeschlagener PoC keine Sicherheit. Die Demonstration enthält als Apache prefork mit mod_php und PHP-FPM bezeichnete Profile; sie belegt keine universelle SAPI-Abdeckung. Erfassen Sie den tatsächlich bedienenden Build und seine Integration, statt die Exposition allein aus CMS-Version oder CLI-Binary abzuleiten.

Der geprüfte Versuchsbericht Dritter meldet keine Befehlsausführung bei den Speicherfehler-Versuchen mit php:8.4.4-cli, php:8.4.4-fpm und php:8.2.34-fpm, trotz lokal ermittelter Adressen. Das sind vom Autor berichtete Ergebnisse, keine für diesen Artikel durchgeführten Tests. Sie belegen weder sichere Versionen noch die Übertragbarkeit des erfolgreichen Dateieinbindungsbeispiels auf Standardinstallationen von PHP. Der Autor schlägt zudem einen CVSS-v3.1-Wert vor; dieser ist eine separate Autorenbewertung und keine Umrechnung der von PHP veröffentlichten v4.0-Einstufung.

Welche Einstellungen verändern die Bedingungen?

Im vorgeschlagenen Pfad aktiviert session.upload_progress.enabled die Verfolgung; name bestimmt das auslösende Feld; freq und min_freq steuern Aktualisierungsschwellen; cleanup steuert das Entfernen der Fortschrittsdaten nach der POST-Verarbeitung. Session-Handler und Serialisierung beeinflussen die Speicherung. Diese Einstellungen zeigen Prüfbereiche auf und bilden keine bestätigte Voraussetzungsliste für beide CVEs. Insbesondere verhindert eine spätere Bereinigung nicht zwangsläufig einen früheren Speicherfehler. [3, 9]

SAPI, Serverpufferung, Größenlimits und Zeitüberschreitungen beeinflussen, wann Daten den Parser erreichen. Eine clientseitige Pause muss nach der Pufferung keine Pause zwischen PHP-Callbacks ergeben. Prüfen Sie die wirksame Konfiguration des Webprozesses und jedes FPM-Pools; die CLI-Konfiguration kann abweichen. Wird Upload-Fortschritt nicht benötigt, prüfen Sie seine Deaktivierung als vorsorgliche Härtung. Die untersuchten Belege bestätigen diese Änderung nicht als vollständigen Workaround für eine der CVEs. [3, 9]

Die geprüfte Laborkonfiguration zeigt auch ein wichtiges Konfigurationsdetail: session.upload_progress.freq=1 bezeichnet ein absolutes Byte-Intervall, während sich 1% auf die Anfragegröße bezieht. Das Testprofil für Speicherfehler verwendet den ersten Wert, obwohl die Kommentare Standardeinstellungen beschreiben. Das Persistenzprofil setzt cleanup=0 und min_freq=0. Vor einer Übertragung der Laborergebnisse auf Produktionssysteme müssen die effektiven Werte einschließlich ihrer Einheiten verglichen werden. [4, 9]

Die Folgen richten sich nach den Prozessrechten

Befehlsausführung als www-data kann eine Anwendung bereits kompromittieren. Je nach Berechtigungen kann der Prozess Datenbankzugangsdaten lesen, beschreibbare Inhalte ändern oder Backend-Dienste erreichen. Gemeinsame Dienstkonten und Verzeichnisse können die Auswirkungen auf weitere Anwendungen ausdehnen. Das sind anhand der Umgebung zu bewertende Folgen, keine Behauptungen über sämtliche Effekte der Demonstration. Entscheidend ist, was der Prozess lesen, ändern und erreichen kann.

Huntress empfiehlt die Überwachung unerwarteter Kindprozesse von PHP- und Webserver-Prozessen. Verbinden Sie Prozessabstammung mit Anfragen, Zeitstempeln, neuen Dateien und ausgehenden Verbindungen. Auch legitime Anwendungen starten Werkzeuge; Ausführung kann zudem ohne neue Shell erfolgen. Die Prüfung alter Dateien im lokalen Trigger und die unvollständige FastCGI-Auswertung des Frameworks zeigen ebenfalls, warum ein Toolurteil dem konkreten Ereignis zugeordnet werden muss. Das ältere PHP-Vorfallsbeispiel von Huntress war ausdrücklich unabhängig von PHP2Shell und darf diesen CVEs nicht zugeschrieben werden. [2]

Den Fix im tatsächlich bedienenden Prozess prüfen

Ordnen Sie öffentliche Endpunkte den bedienenden PHP-Paketen oder Images, SAPIs, Erweiterungen und wirksamen Einstellungen zu. Berücksichtigen Sie Herstellerprodukte und Hostingumgebungen mit gebündeltem PHP. Gleichen Sie das detaillierte Advisory mit Distributions- oder Herstellerpaketen ab, einschließlich zurückportierter Korrekturen. Ersetzen oder starten Sie betroffene Worker neu und bestätigen Sie, dass der korrigierte Build Anfragen verarbeitet. Für Installationen ohne gepflegte Sicherheitsupdates braucht es einen Upgrade- oder Expositionsreduktionsplan.

Das technische Ziel verbindet die verwundbare Operation, ihre Erreichbarkeitsbedingungen und den Code, der die nötige Invariante wiederherstellt. Ein unauffälliges Ergebnis dieser Proof-of-Concept-Implementierungen ersetzt diese Zuordnung nicht. Bei meiner Fix-Verifikation verfolge ich die Aussage bis zum bereitgestellten Prozess und prüfe, ob die relevante Korrektur tatsächlich eingesetzt wird. Wenn Ihre PHP-Umgebung diese Bewertung benötigt, beginnt die Arbeit mit dem laufenden System und überprüfbaren Belegen.