Proaktiver Schutz von Fastly für PHP2Shell, kritische PHP RCE CVE-2026-109618 und CVE-2026-109619

PHP – die Laufzeitumgebung hinter den meisten CMS, E-Commerce-Plattformen und Publishing-Infrastrukturen im Web – wird von den Geistern vergangener Jahrzehnte heimgesucht: einer Designentscheidung, die zu einem Fehler bei der Verarbeitung fataler Fehler durch die PHP-Engine führte. Die heute offengelegten Schwachstellen mit dem Namen php2shell haben ihre gemeinsame Ursache in dieser Designentscheidung, auf die wir in diesem Post eingehen.

Die PHP Foundation hat zwei CVEs (CVE-2026-109618, CVE-2026-109619) zugewiesen. Die entsprechenden Schwachstellen sind ab PHP 8.2 gepatcht (gepatchte Versionen: 8.5.12, 8.4.27, 8.3.36 und 8.2.35). PHP hat außerdem Patches für 7.4, 8.0 und 8.1 zur Integration durch Paketdistributoren veröffentlicht. Versionen unter 7.4 werden nicht von PHP mit einem Patch versorgt und nach Ermessen der Paketdistributoren gepatcht. Jede weiterhin gepflegte PHP-Version ist betroffen. Nach derzeitigem Kenntnisstand besteht der älteste nachgewiesene Angriffspfad bereits seit 2012. 

Es gibt Hinweise auf aktive Angriffe in freier Wildbahn, die bereits vor der Bekanntgabe stattfanden; es handelt sich nicht um rein theoretische Probleme.

Wir empfehlen Kunden dringend, ihre Umgebung nach App-Servern mit mod_php oder php-fpm zu durchsuchen und diese umgehend zu patchen. Wenn Sie keine Möglichkeit zum Patchen finden, empfehlen wir aktive Abwehrmaßnahmen. 

Angesichts der Art dieser instrumentalisieren (einschließlich RCE vor der Authentifizierung) sollten Sie derzeit davon ausgehen, dass eine aktive Abwehr nur "partial"-Schutz bietet und je nach Vorgehensweise möglicherweise die Blockierung eines erheblichen Teils des legitimen Traffics erfordert.

Wir sind dankbar für die enge Zusammenarbeit mit OpenAI sowie anderen Partnern des Software-Ökosystems, die zu diesen dringenden Bemühungen beigetragen haben, um möglichst viele Organisationen bestmöglich zu schützen. 

In diesem Post erläutern wir die Sicherheitslücken näher, beschreiben, wie sich die Instrumentalisierung dieser PHP-Sicherheitslücken auf Ihr Unternehmen auswirken könnte, und geben Hinweise dazu, wie Sie Angriffsversuche abwehren können.

Die Kurzfassung zu CVE-2026-109618 & CVE-2026-109619

Wenn PHP ein Speicherlimit erreicht, bei der Ausführung ein Timeout auftritt oder eine Verbindung abbricht, wird die Ausführung nicht geordnet abgewickelt. PHP bricht den laufenden Betrieb mitten im Betrieb ab und springt zu einem Wiederherstellungspunkt, wobei ein teilweise veränderter interner Zustand zurückbleibt. Dieser zurückbleibende Zustand kann auf bereits freigegebenen Speicher verweisen oder Datenstrukturen enthalten, deren Aufbau nie abgeschlossen wurde.

Forschende haben gezeigt, dass ein Angreifer diese Fehlerzustände mit einer einzigen nicht authentifizierten HTTP-Anfrage auslösen kann. Der Angreifer kann auch ohne Log-in, speziellen Endpunkt oder Mitwirkung der App erfolgreich sein. Die RCE ermöglicht es dem Angreifer, präzise genug Kontrolle darüber auszuüben, was im zurückbleibenden Zustand landet, sodass PHP als vermeintlich legitimer Betriebssystemnutzer des Webservers beliebige Shell-Befehle ausführt. Der Worker-Prozess bleibt bestehen und verarbeitet anschließend weiter Anfragen, ohne zu bemerken, dass er nun von einem neuen Befehlshaber gesteuert wird.

Der einzige Log-Eintrag ist eine gewöhnliche Fehlermeldung wegen Speichermangels. Das wird, gelinde gesagt, eine wilde Fahrt.

Die möglichen Auswirkungen können nicht hoch genug eingeschätzt werden:

• Breite: Jede Organisation mit PHP-Apps

• Tiefe: Der Angreifer kann in der App tun, was er will

Da Sie möglicherweise eine PHP-Konfiguration betreiben, die unbeabsichtigt mod_php oder php-fpm enthält, empfehlen wir Kunden dringend, jede PHP-App als potenziell anfällig zu betrachten und ihre Umgebung entsprechend zu überprüfen.

Ein Lichtblick: Die vorhandenen POC erfordern Kenntnisse über die konkrete, auf dem Server ausgeführte PHP-Binärdatei und die Anordnung des Adressraums, damit ein Angriff auf x86_64 zur Ausführung von Code führt. Daher sind die meisten Deployments möglicherweise vor RCE „sicher“. Gehen Sie nicht davon aus, dass dies auch für Sie gilt. Wenn Sie eine 32-Bit-PHP-App betreiben, sollten Sie wahrscheinlich davon ausgehen, dass sie kompromittiert wurde. 

Genauer betrachtet: Das Designproblem auf Engine-Ebene

Die PHP-Engine geht auf kreative Weise mit schwerwiegenden Fehlern um. Wenn etwas gründlich schiefgeht, erhalten alle Funktionen, die gerade mit einer Aufgabe beschäftigt sind, weder eine Benachrichtigung noch die Gelegenheit, hinter sich aufzuräumen. Ihre halbfertige Arbeit bleibt genau so liegen, wie sie sie hinterlassen haben. Genauer gesagt verwendet die Engine einen Mechanismus namens longjmp(), der die Ausführung direkt zu einem Abfangpunkt versetzt – als würde man die App sozusagen am Kragen packen –, statt einen Fehler per Logging zu erfassen und sich sofort von der Bühne zu verabschieden.

Die PHP-Engine ruft diesen Mechanismus – zend_bailout genannt – aus jedem Codepfad auf, der ein Ressourcenlimit durchsetzt oder einen schwerwiegenden Fehler behandelt (und davon gibt es viele). Wenn bei der App der Arbeitsspeicher erschöpft ist, Zeitüberschreitungen bei der Ausführung auftreten, Clientverbindungen abgebrochen werden oder nicht abgefangene schwerwiegende Fehler auftreten, kommt in all diesen Fällen zend_bailout zum Einsatz.

Dieser kreative Ansatz wäre handhabbar, wenn solche Fehler selten oder unter kontrollierten Bedingungen aufträten. Wer lange genug dabei ist, um die Freuden der PHP-Entwicklung erlebt zu haben, weiß nur zu gut, dass solche schwerwiegenden Fehler bei PHP-Deployments in Produktivumgebungen regelmäßig auftreten. Noch wichtiger ist, dass diese Bedingungen für Angreifer attraktiv sind, die gern die vollständige Kontrolle über das World Wide Web hätten (d. h. alle App-Server, auf denen heute PHP läuft).

Was führt zur Ausnutzung?

Wenn zend_bailout ausgelöst wird, hinterlässt jeder interne PHP-Betrieb, der gerade eine Datenstruktur verändert, diese in einem inkonsistenten Zustand, der den Voraussetzungen des Betriebs widerspricht. Der PHP-Bereinigungscode, der nach jeder Anfrage ausgeführt wird, um den Zustand der Anfrage zu löschen, stößt anschließend auf diese inkonsistenten Daten und verarbeitet sie, als wären sie gültig.

Die veröffentlichten POCs sollten als veranschaulichende Beispiele betrachtet werden. Sie erfassen bei Weitem nicht die gesamte Vielfalt der Bailout- und vorzeitigen Abbruchpfade, die ähnliche Bedingungen auslösen können, welche Angreifer instrumentalisieren können. Um zu verdeutlichen, warum dies für das Internet problematisch ist: Im PHP-Quellcode wird der Mechanismus zend_bailout an vielen Stellen aufgerufen; jeder dieser Aufrufe kann andere laufende Betriebe unterbrechen; und für jeden gelten bei einer Unterbrechung eigene Invarianten.

Die Zahl der möglichen Kombinationen ist, gelinde gesagt, gewaltig. Das Schließen der konkreten Pfade, die Forschende demonstriert haben, macht den Mechanismus nicht sicher. Angesichts des Return on Investment dieser Schwachstelle werden Angreifer hoch motiviert sein, den nächsten noch unentdeckten Pfad zu finden, um ihre Angriffsserie fortzusetzen.

Gehen Sie davon aus, dass sowohl cyberkriminelle Organisationen als auch Nationalstaaten dies aufgreifen werden; in Kombination mit einem Infoleak ist diese Angriffsprimitive wirkungsvoll ... und der Infoleak muss nicht einmal besonders ausgefeilt sein. Der Infoleak-Bug kann den Prozess zum Absturz bringen und dank des Prefork-Designs von mod_phpdennoch als gültig gelten. „Wie man sicher in Panik gerät“ ist ein Thema für ein anderes Mal.

Warum sind die Auswirkungen so gravierend?

Das könnte ein Angreifer durch die Ausführung von Code aus der Ferne auf einem PHP-Server erreichen:

• PHP-basierte Websites und Apps mit einer einzigen nicht authentifizierten Anfrage außer Betrieb setzen; in großem Maßstab führt dies zu einem anhaltenden Ausfall (sofern die Inhalte nicht gecacht sind)

• Beliebige Befehle auf dem Server ausführen, ohne sichtbare Störungen zu verursachen; der Server nimmt die Eingaben der Angreifer bereitwillig entgegen

• Sämtliche Zugangsdaten stehlen, die die App verwendet: Datenbankpasswörter, API-Schlüssel, Schlüssel von Cloud-Anbietern und Verschlüsselungsschlüssel

• Auf die Datenbanken, Systeme zum cachen, Nachrichtenwarteschlangen und internen Systeme zugreifen, die durch diese Zugangsdaten geschützt sind: Kundendatensätze, Transaktionen, personenbezogene Daten und alles andere, worauf die App zugreift; dies kann Meldepflichten bei Sicherheitsverletzungen und weitere regulatorische Pflichten auslösen

• Tiefer in das Netzwerk vordringen: sich über Cloud-Infrastruktur, Kubernetes-Service-Account-Token, Envoy und SSH-Schlüssel auf der Festplatte bis zu internen Services vorarbeiten, da sich der Webserver bereits in Ihrer vertrauenswürdigen Umgebung befindet

• Dauerhaften Zugriff einrichten, der Server-Neustarts und erneute Deployments übersteht (sozusagen der bequeme Strandstuhl für den Angreifer, in Form von Hintertüren in PHP-Dateien oder unauffälligen Cronjob)

• Keine offensichtlichen Hinweise: Der einzige Log-Eintrag meldet einen gewöhnlichen Speicherfehler, den Betriebsteams regelmäßig sehen und nur selten untersuchen (von außergewöhnlich neugierigen SREs abgesehen)

Die Folgenkette kann bei verschiedenen Anwendungsfällen gravierend sein. Ein typischer Onlineshop zeigt, wie das aussehen kann: eine HTTP-Anfrage → Kompromittierung des Servers → Installation eines dauerhaft aktiven Skimmers → fortlaufender massenhafter Diebstahl von Kartendaten sämtlicher Kunden → Sicherheitsverletzung von PCI DSS → möglicherweise vollständiger Verlust der Möglichkeit, Kartenzahlungen abzuwickeln.

So stellen Sie fest, ob Sie betroffen sind

Wir empfehlen Kunden, jede PHP-App als potenziell anfällig zu betrachten und ihre Produktivumgebung entsprechend zu überprüfen. Bei der Untersuchung möglicher Schwachstellen sollten Sie jetzt keine Abstriche machen; beginnen Sie umgehend mit der Bestandsaufnahme. Prüfen Sie anhand der folgenden konkreteren Kriterien, ob eine Gefährdung vorliegt:

• PHP hinter Apache mod_php im Prefork-Modus

• Ein Verhältnis von memory_limit zu post_max_size, das es einem Angreifer ermöglicht, über einen POST-Body einen OOM auszulösen

• Die Denial-of-Service-Varianten (DoS) (Abstürze ohne Codeausführung) betreffen eine größere Bandbreite von Konfigurationen, darunter php-fpm

Zu den Branchen, die unserer Einschätzung nach besonders anfällig für diese Angriffe sein könnten, gehören:

• E-Commerce (Online-Handelsplattformen) | post_max_size liegt häufig über dem Standardwert, um Datei-Uploads zu berücksichtigen

• Medien und Verlagswesen (CMS) | große Angriffsfläche durch zahlreiche Standardinstanzen von Apache mit mod_php und Standardkonfigurationen (oder nahezu unveränderten Standardkonfigurationen)

• Bildungswesen (Lernplattformen, Custom-Portale für Studierende, Tools für Lehrende) | PHP ist im Hochschulbereich stark verbreitet und wird häufig von kleinen Teams betreut

• Gastgewerbe und Reisebranche (Buchungssysteme, Plattformen für Treueprogramme, Property-Managementsysteme) | Custom PHP auf LAMP-Stacks bietet häufig großzügige Upload-Limits für Fotos und Dokumente

• Finanzdienstleistungen (Integration von Zahlungssystemen, Kreditantragsportale, Versicherungsansprüche) | erhöhter Wert für post_max_size aufgrund dokumentenintensiver Workflows; PHP ist das COBOL der kundenorientierten Apps

• SaaS (interne Admin-Tools, Kundensupport-Dashboards, Web-Frameworks) | oft weniger intensiv überwacht und von schlanken Teams kleiner und mittlerer Unternehmen betrieben

• Managed-Hosting- und Shared-Hosting-Anbieter (Webhosting-Kontrollpanels, mandantenfähige Apache-Umgebungen) | vielfach verstärkte Auswirkungen, wenn eine anfällige PHP-Konfiguration auf einem gemeinsam genutzten Server zum Einsatz kommt

• Gesundheitswesen (Patientenportale, Terminplanungssysteme, Integrationen von Gesundheitsdaten) | sensible Uploads wie Laborergebnisse, Überweisungsformulare und Versicherungskarten erfordern einen höheren Wert für post_max_size

Wie Sie jetzt aktiven Schutz erhalten

Um das Risiko für Ihre durch NGWAF geschützten Apps zu verringern, können Fastly-Kunden das Signal aktivieren, das sowohl CVE-2026-109618 & CVE-2026-109619 abdeckt. Der Erkennungsinhalt dieser CVE-spezifischen Vorlagenregel sucht nach strukturellen Merkmalen solcher Ausnutzungsversuche – Bodys und Parametern, die anders strukturiert sind als bei legitimem Traffic – und die auf mögliche Ausnutzungsversuche der php2shell-CVEs hinweisen können.

Das Team für Sicherheitsuntersuchungen von Fastly hat diesen Inhalt in enger Zusammenarbeit mit OpenAI und Partnern aus der Community entwickelt und getestet; wir sind dankbar für diese Partnerschaft. Unser Team für Sicherheitsuntersuchungen wird den virtuellen Patch bei Bedarf aktualisieren; alle, die sich dafür angemeldet haben, erhalten nachfolgende Updates automatisch. 

Fastly wird weiterhin untersuchen, welche zusätzlichen Abwehr-Layer wir unseren Kunden anbieten können, um Angriffs-Traffic im Zusammenhang mit php2shell zu erkennen und zu blockieren. Wir werden weiterhin relevante NGWAF-Inhalte weiterentwickeln und verfeinern, während wir Ausnutzungsversuche beobachten.

Empfohlene Signale und Hinweise für die Untersuchung

Um den einfacheren Fehler bei der Upload-Fortschrittsanzeige zu entschärfen, stellen Sie sicher, dass in php.ini session.upload_progress.enabled = Off festgelegt ist. 

Für die schwerwiegendere zend_bailout -Schwachstelle wurden im instrumentalisieren- und Proof of Concept-Traffic bislang unter anderem folgende wichtige Muster festgestellt:

Verringerung der Angriffsfläche durch die PHP-Konfiguration

• post_max_size = 8M — hält POST-Anfragekörper unter dem Schwellenwert, ab dem eine einzelne Anfrage einen Speichermangel auslösen kann. Testen Sie dies mit jedem Workflow, der Datei-Uploads oder umfangreiche Formularübermittlungen akzeptiert; 8M ist der Standardwert von PHP, wurde aber in vielen Deployments in der Produktivumgebung erhöht.

• max_input_nesting_level = 4 – ein Limit für stark verschachtelte Variablennamen, die in der Payload zum Instrumentalisieren der Hash-Tabelle verwendet werden. Erhöhen Sie den Wert auf 6, wenn die App komplexe verschachtelte Formularstrukturen verwendet. Testen Sie Formularübermittlungen mit Feldnamen in Array-Notation.

• session.upload_progress.enabled = 0 – deaktiviert die Funktion zur Nachverfolgung des Upload-Fortschritts, die sitzungsbezogene Pfade zum Instrumentalisieren auslöst. Betrifft nur Apps, die mithilfe des integrierten Sitzungsmechanismus von PHP Fortschrittsbalken für Uploads in Echtzeit anzeigen. Die meisten Apps, die den Upload-Fortschritt anzeigen, verwenden stattdessen JavaScript-basierte Ansätze.

Im HTTP-Traffic (WAF, Proxy oder Netzwerkinspektion)

• Übergroße Formularübermittlungen. POST-Anfragekörper mit App/x-www-form-urlencoded und mehr als 1–2 MB. Legitime Formularübermittlungen sind fast immer kleiner als 100 KB. URL-kodierte Formulare mit mehreren Megabyte sind so selten, dass sie an jedem Endpunkt, der PHP ausführt, untersucht werden sollten.

• Leere Feldnamen mit tiefer Verschachtelung. Post-Anfragekörper, die mit = (einem Feld ohne Namen) beginnen, gefolgt von einem Feldnamen, der wiederholt das Zeichen [ enthält. Dies ist der konkrete Aufbau des Payloads für das Instrumentalisieren der Hash-Tabelle.

• Feldnamen für die Fortschrittsanzeige bei Uploads. Multipart-Datei-Uploads mit einem Feld namens PHP_SESSION_UPLOAD_PROGRESS. Dies ist eine legitime PHP-Funktion, löst aber auch die Session-bezogenen Pfade zum Instrumentalisieren aus. Markieren Sie das Feld zur Überprüfung bei Endpunkten, die keine Fortschrittsanzeige für Uploads verwenden.

In den Fehler-Logs von Apps und Webservern

• OOM-Fehler aus PHP-internen Komponenten, nicht aus dem App-Code. Suchen Sie nach „Allowed memory size ... exhausted“ mit dem Standort „Unknown on line 0“. Die Datei „Unknown“ und die Zeile 0 bedeuten, dass der Fehler beim Parsen der Anfrage durch PHP selbst auftrat, bevor ein App-Skript ausgeführt wurde. Ein OOM-Fehler im App-Code würde eine konkrete Datei und Zeilennummer angeben.

• Gehäufte Segmentierungsfehler. Cluster von Apache-Protokolleinträgen mit AH00052 ... exit signal Segmentation fault (11) innerhalb kurzer Zeit. Einige vereinzelte Segmentierungsfehler sind nicht ungewöhnlich; Dutzende innerhalb weniger Minuten, gefolgt von einer einzigen langsamen HTTP-200-Antwort, entsprechen der Brute-Force-Phase zur Adresswiederherstellung bei diesem Exploit.

Bei der Prozessüberwachung (auf Host-Ebene)

• Apache-/PHP-Worker, die Shell-Prozesse starten. Jeder mod_php -Worker, der /bin/sh -c ... als untergeordneten Prozess ausführt. Im Normalbetrieb starten mod_php -Worker keine untergeordneten Prozesse, es sei denn, die PHP-App ruft ausdrücklich eine Funktion zur Befehlsausführung auf (exec, system, shell_exec usw.). Wenn kein App-Code ausgeführt wurde (bei den derzeit bekannten instrumentalisieren wird kein App-Code ausgeführt), werten Sie eine von einem PHP-Worker gestartete Shell als Ausführung der Payload zur Codeausführung.

Für PHP-FPM-Deployments

• pm.max_Anfragen = 50 – erzwingt einen Neustart der Worker-Prozesse nach 50 Anfragen und setzt so ein Limit für das Zeitfenster, in dem eine anfrageübergreifende Beschädigung (durch die Session- und Datenconversionfehler) instrumentalisiert werden kann. Verhindert nicht den Hash-Tabellen-Fehler, der eine Beschädigung innerhalb einer einzelnen Anfrage instrumentalisiert. Ein Wert von 1 würde anfrageübergreifende Angriffe vollständig verhindern, allerdings mit erheblichen Einbußen bei der Performance.

Nächste Schritte

Wir wissen, dass unsere Kunden uns die Netzwerkstabilität ihrer geschäftskritischen Services anvertrauen, und es ist ein Kernelement unserer Unternehmensmission, Ihnen den Rücken freizuhalten, wenn Überraschungen wie CVE-2026-109618 und CVE-2026-109619 auftreten. Unsere Teams stehen Ihnen bei der laufenden Abwehr von php2shell zur Seite – egal, ob Sie ein langjähriger Kunde der Fastly-Plattform sind oder neu sind und sofortigen Schutz benötigen. Lassen Sie uns wissen, wie wir helfen können.

Zusammengefasst:

• Der als Angriffsmittel eingesetzte Mechanismus – zend_bailout ruft longjmp() auf, um laufende Betriebe abzubrechen – ist in der gesamten Codebase vorhanden und über gewöhnlichen HTTP-Traffic erreichbar. 

• Spielen Sie die Patches zügig ein und beachten Sie, dass sie nur die bislang entdeckten und instrumentalisierten Fehler abdecken. 

• Rechnen Sie mindestens in dieser und der nächsten Woche mit tatsächlichen Angriffen und neuen Varianten. 

• Die architektonische Voraussetzung, die sie ermöglicht hat, ist eine grundlegende Eigenschaft des Fehlerbehandlungskonzepts der Engine und kein auf eine bestimmte Codestelle begrenzter „Defekt“; sie wird auch nach der Bereitstellung dieser Patches bestehen bleiben.

Wir sind dankbar, dass wir zu diesen gemeinschaftlichen Bemühungen zum Schutz des Internets als Ganzes beitragen können. Wir setzen uns dafür ein, auch im weiteren Verlauf der Angriffe zusammenzuarbeiten; wir möchten, dass unsere Kunden und das breitere Software-Ökosystem schnell handeln und geschützt bleiben. 

Im Sinne der Aufrechterhaltung der Netzwerkstabilität und der Zusammenarbeit im Ökosystem wird Fastly unser globales Netzwerk proaktiv auf Ausnutzungsversuche von PHP2Shell überwachen und anschließend Updates zu den beobachteten Aktivitäten anbieten, ähnlich den Einblicken, die wir während der React2Shell- und Log4Shell-Vorfälle veröffentlicht haben. Falls Sie Unterstützung benötigen, zögern Sie nicht, sich an uns zu wenden. Bleiben Sie dran.