php2shell Red Team: Angriffsfläche und Erkennung

php2shell ist die Bezeichnung für das Paar CVE-2026-109618 und CVE-2026-109619, zwei kritische Fehler der PHP-Laufzeit, die am 21. Oktober 2026 öffentlich wurden und in den von den offiziellen Warnungen bestätigten Szenarien PHP RCE ohne Authentifizierung auf Installationen ermöglichen, die HTTP-Anfragen bedienen.

Zusätzlich verortet der offizielle Hinweis im php.net-Archiv 2026 das Risiko im Motor, der Webanfragen verarbeitet, und nicht in einem CMS-Plugin. Deshalb liegt der Schwerpunkt dieses Textes auf Oberfläche, Inventar in autorisierten Pentests und defensivem Hunting. Der Schwesterartikel auf basilisk deckt dagegen die operative Patch-Checkliste ab. So vermeidet das Red Team, den Korrekturleitfaden zu kannibalisieren, und liefert dennoch ein brauchbares Bedrohungsmodell.

Was die Anatomie von php2shell an den beiden Fehlern zeigt

CVE-2026-109618 beschreibt eine Korruption, die mit Out-of-Memory mitten in der Initialisierung interner Anfragedaten zusammenhängt, während CVE-2026-109619 globalen Zustand beschreibt, der freigegebene Speicherregionen überlebt und von der nächsten Anfrage im selben Worker wiederverwendet wird. Zusammen bilden sie den Speicherfehler in PHP, der unter dem Namen php2shell läuft.

Wie OOM die Anfrage in einen ungültigen Zustand bringt

Im Advisory GHSA-w8hw-w9fx-j79w erklärt das PHP-Sicherheitsteam die Rolle von longjmp(). Der Motor nutzte diesen Mechanismus, um die Anfrage abzubrechen, wenn der Speicher ausging. An bestimmten Punkten war ein Teil der Anfragestruktur bereits erreichbar, aber noch nicht vollständig initialisiert. Scheiterte eine Allokation genau dann, konnte der Aufräumweg ungültige Daten wie gültige behandeln, wodurch der Motor weiter über sie las oder verzweigte.

Wie veralteter Zustand Anfragen im selben Worker überschreitet

Der zweite Bezeichner, CVE-2026-109619, steht im GHSA-6wmf-4rv5-p3rp. Er betrifft globale Worker-Felder, die auf Speicher einer Anfrage zeigen und vor der Heap-Freigabe zurückgesetzt werden müssen. Wenn ein fataler Fehler, eine Diagnose oder ein Session- und Upload-Pfad den Ablauf zum falschen Zeitpunkt unterbricht, bleibt der globale Zeiger stehen, und die nächste Anfrage im selben persistenten Prozess kann diesen Wert konsumieren. In der Fehlerklasse verbindet der erste CVE eine Schwäche im Umgang mit Ausnahmesituationen mit der Nutzung nicht initialisierten Zustands, während der zweite ein klassischer Use-after-free zwischen Anfragen ist.

Wo Quellen bei Umfang und Score auseinanderlaufen

Forschende und Cloud-Berichte, darunter Cloudflare, situieren ausnutzbare Pfade seit PHP 5.4 unter bestimmten Konfigurationen. Der offizielle Hinweis und die GHSAs listen hingegen die Linien 8.2.35, 8.3.36, 8.4.27 und 8.5.12 als behoben, und es gibt auch minimale Quell-Backports für 7.4, 8.0 und 8.1. Die Breite seit 5.4 ist eine Aussage von Forschenden und Drittberichten und kein abgeschlossenes Inventar der PHP-CNA für jedes Legacy-Release.

Der vom PHP-Team veröffentlichte und von CERT-EU, NHS England sowie Datadog übernommene Score liegt bei CVSS v4.0 9.2 für beide. Im Vorab-Leak kursierte eine 10.0, und NVD sowie Hersteller wie Red Hat können abweichende v3.1-Vektoren publizieren. Im Inventar notieren Sie die Score-Quelle und vermischen Sie die Skalen v3.1 und v4.0 nicht.

In der Praxis sehe ich in Engagements am häufigsten, dass Teams beide CVEs von php2shell als ein einziges Patch-Ticket behandeln, wodurch der Unterschied der Vorbedingungen verschwindet. Wer OOM in der Anfragebereinigung von der Worker-Wiederverwendung trennt, platziert Sensoren besser und priorisiert klarer, wenn das Inventar mod_php gegen FPM zeigt.

Welche Voraussetzungen und Angriffsflächen wirklich zählen

Die von php.net bestätigte Oberfläche umfasst jede PHP-Installation, die Webanfragen bedient, einschließlich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das Risiko wird für mod_php als höher beschrieben, mit demonstrierter Ausnutzung, bei der eine nicht authentifizierte Anfrage den Angriff auslöst, bevor Anwendungscode läuft.

Wie SAPI und persistenter Worker das Fenster verändern

Die CISA bekräftigt in der Warnung vom 21. Oktober 2026, dass alle Installationen, die HTTP bedienen, im Umfang liegen, und fordert außerdem Inventar dort, wo PHP in Drittprodukten eingebettet ist. Persistente Worker verändern das Spiel bei CVE-2026-109619, weil Produzent und Konsument des veralteten Zustands denselben Prozess brauchen.

In SAPIs, die den Kindprozess nach fehlgeschlagener Initialisierung beenden, kann der Pfad von CVE-2026-109618 enger werden. Das OOM-Advisory sagt genau das über FPM, weil dieses SAPI das Kind beendet, wenn der Start fehlschlägt, und so den Konsum ungültigen Zustands in jenem Ast vermeidet. Dennoch weist die Quellanalyse des Advisories selbst FPM in anderen Momenten als anfällig aus, und nicht alle Äste haben eine vollständig demonstrierte Ausnutzung. Die PHP Foundation bestätigt RCE auch auf Anwendungspfaden unter FPM. Ein Prozess pro Anfrage verkleinert das Fenster für stale Zustand zwischen Anfragen, hebt jedoch den OOM in der Bereinigung nicht allein auf, wenn das Shutdown noch teilweise Speicher sieht.

Was Teilmitigationen blockieren und was sie offen lassen

Eine weitere praktische Vorbedingung ist die Exposition von automatischem Body-Parsing, Multipart sowie Session- und Diagnose-Pfaden, die früh laufen. Teilmitigationen, die php.net nennt, etwa administratives memory_limit=-1 für den OOM, blockieren bestätigte Pfade. Dasselbe gilt für session.upload_progress.enabled=0 mit Worker-Neustart beim stale Zustand, doch sie lassen Varianten offen und machen die Installation gegenüber php2shell deshalb nicht sicher. Gängige CMS-Anwendungen tauchen in Forscherdemos auf, doch der Fehler liegt in der Runtime, und Anwendungsauthentifizierung ist kein Control für den Ast, der vor dem Script zündet.

Der teuerste Fehler hier ist die Annahme, „wir nutzen keinen Upload“ oder „es gibt nur FPM“ bedeute außerhalb des Umfangs von php2shell. Im realen Inventar entscheiden SAPI, Paketversion und Internetzugänglichkeit sowie die Worker-Wiederverwendung über die Priorität, während der CMS-Name in der Vitrine das Risiko fast nie entscheidet.

Wie der Speicherfehler in PHP konzeptionell zu Codeausführung wird

In der Sprache der Fehlerklasse muss der Angreifer die Logik von WordPress nicht durchbrechen, weil er den Motor zwingt, über Strukturen weiterzuarbeiten, die keine gültige Anfrage mehr darstellen. Bei CVE-2026-109618 liest oder folgt die Bereinigung nach OOM unvollständigen Zeigern und Metadaten. Mit ausreichender Kontrolle über Inhalte, die den Anfragespeicher belegen oder belasten, wird diese Lesung zu nützlicher Korruption. Bei CVE-2026-109619 erlaubt ein Use-after-free zwischen Anfragen, dass die zweite Anfrage Bytes interpretiert, die in der ersten geformt wurden, oder Bytes, die von anderen Anfragen im selben Worker stammen.

Die konzeptionelle Brücke zu RCE entspricht anderen Speicherfehlern in Interpretern, weil Korruption oder Wiederverwendung interner Objekte zu Ablaufablenkung oder Funktionsaufruf unter Angreiferkontrolle wird. Die Privilegien sind die des Web-Worker-Kontos. Speicherpreisgabe, von Wiz, Datadog und dem Advisory zum stale Zustand als mögliche Nebenwirkung beschrieben, kann Adressen und Geheimnisse liefern und damit die RCE-Kette stabiler machen. Nichts davon verlangt in diesem Text ein öffentliches Layout. Der operative Punkt lautet, dass App-Authentifizierung und flache Signatur-WAFs die Klasse nicht schließen, und die Idee, es gebe keine RCE im Anwendungscode, schließt php2shell ebenfalls nicht.

Viele glauben, nur klassischer Heap-Overflow mit veröffentlichtem Offset zähle. Fast immer liegen sie falsch, weil hier der Trigger im Fehlerpfad und im Lebenszyklus der Anfrage liegt. In der Bedrohungsprüfung behandeln Sie php2shell als Runtime-Fehler mit Shell-Auswirkung unter dem Webserver-Benutzer und nicht als Plugin-CVE.

Wie man die Angriffskette auf hoher Ebene beschreibt, ohne einen PoC zu liefern

Auf hoher Ebene beginnt die Kette von php2shell mit einer oder mehreren speziell gebauten HTTP-Anfragen gegen einen Endpunkt, den PHP parst. Für CVE-2026-109618 ist das konzeptionelle Ziel, einen Speicherfehler oder Abbruch in einem Moment auszulösen, in dem Anfragestrukturen halb fertig sind, wonach die Bereinigung über diesen Zustand arbeitet. Für CVE-2026-109619 umfasst die Sequenz typischerweise eine Anfrage, die residualen globalen Zustand erzeugt, und danach eine andere Anfrage im selben Worker, die diesen Zustand vor dem vollständigen Reset konsumiert. Das angestrebte Ergebnis ist Code unter dem Benutzer von Apache, FPM oder dem gleichwertigen SAPI.

Öffentliche Quellen divergieren zur Feldausnutzung am 21. Oktober 2026. Die CISA erklärte, bei Veröffentlichung der Warnung keine Ausnutzung beobachtet zu haben, während Cloudflare Angriffsverkehr und Mutation von Payloads gegen bereits aktive Regeln meldete. Das Kanadische Zentrum für Cybersicherheit sprach von verfügbarem PoC ohne zu diesem Datum identifizierte aktive Ausnutzung. SecurityWeek und watchTowr beschrieben Versuche an Sensoren, und in einigen Berichten blieb der Erfolg noch begrenzt. Für Red Team und SOC ist der sichere Zustand, das Fenster nach dem Leak als feindlich anzunehmen, weil Inventar plus Patch Debatten über Dritt-Telemetrie zu php2shell schlägt.

Wer schon Runtime-Inventare beim Kunden gescannt hat, weiß, dass die Kette aus anomaler Anfrage, Worker unter Druck und unerwartetem Kindprozess vor jeder eleganten Webshell erscheint. Ist das Engagement autorisiert, dokumentieren Sie Hypothese und passive Evidenz, und lösen Sie den Fehler weder in fremder Produktion noch auf Hosts außerhalb des RoE aus.

Wie man die Exposition gegenüber php2shell in autorisierten Pentests bewertet

In einem Pentest mit formeller schriftlicher Autorisierung ist die korrekte Bewertung von php2shell Inventar und Patch-Level-Validierung und kein Auslösen der Schwachstelle. Erfassen Sie Interpreter- und Distributionspaketversion sowie den genutzten SAPI, Präsenz von mod_php, FPM-Pools, Container und Appliances mit eingebettetem PHP. Vergleichen Sie mit 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Liegt die Linie bei 8.1 oder älter, vergleichen Sie mit dem LTS-Vendor-Advisory.

Das britische NCSC forderte in der Warnung zum kritischen PHP-Problem die prioritäre Identifikation internetseitiger Systeme und die laufende Beobachtung von Lieferanten, die die Runtime paketieren. Prüfen Sie, ob Banner oder freiliegendes phpinfo zum installierten Paket passen, weil Proxys und alte Images lügen. In der vertraglich gebundenen Kundenumgebung bevorzugen Sie Paketlesung und kontrollierten Neustart nach dem Patch und vermeiden destruktive Beweise. Verlangt der Scope eine Wirkungsdemonstration, nutzen Sie ein isoliertes Labor, das SAPI und Version spiegelt, und niemals das Produktionsziel Dritter. Suchen Sie Zeichen indirekter Exposition, etwa Panels und Produkte, die eingebettetes PHP angeben, ohne einfachen Upgrade-Kanal.

1. Hosts, Container und Appliances mit PHP inventarisieren, die HTTP beantworten, mit Evidenz zu Paket und SAPI.
2. Die laufende Version mit 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder mit dokumentiertem LTS-Backport vergleichen und Exposition markieren, wenn der behobene Boden fehlt.
3. Netzexposition, Worker-Wiederverwendung und RoE-Grenzen dokumentieren, ohne OOM oder Use-after-free am Produktionsziel auszulösen.

In autorisierten Engagements ist mein Kriterium einfach. Version unter dem behobenen Boden plus Web-SAPI gleich kritischer Expositionsfund zu php2shell, mit Paket- und Konfigurationsbeleg. OOM oder Use-after-free am Ziel nur dann auslösen, wenn das RoE das ausdrücklich sagt und die Umgebung verwerfbar ist, weil Sie sonst Validierung mit einem Incident vermischen.

Welche Logsignale und öffentliche Indikatoren man beobachten sollte

Nützliche Signale zu php2shell erscheinen verteilt über die Anfrageebene, die PHP- bzw. Webserver-Logs und die Prozessebene, und das Material von Datadog Security Labs zu php2shell beschreibt die Korrelation anomaler Submissions, fataler Speicherlimit-Fehler während der Anfrageinitialisierung und Worker, die Shells starten.

Fatale Speicherfehler vor dem Script gehören zur selben IOC-Familie wie Neustarts von Apache-Kindern mit Segmentierungsfehler und wie Peaks großer Bodies oder Multipart außerhalb der Baseline. Unerwartete Kindprozesse unter der UID des Webservers vervollständigen das Bild. CISA und die kanadische Warnung fordern Aufmerksamkeit für PHP-Worker, die Shells starten, Tools laden oder untypische Prozesse, Dateien, Konten und ausgehende Verbindungen erzeugen.

Klassische Post-Exploitation bleibt gültig und umfasst neue Webshells in beschreibbaren Verzeichnissen, Downloads über Netzwerktools vom Worker, Cron oder systemd-Dienste des PHP-Benutzers, neue lokale Konten und untypische Ausgänge. Kein Einzelsignal beweist php2shell, weil legitimer Speicherpeak und schlechtes Deployment ebenfalls OOM erzeugen. Die Kraft liegt in der zeitlichen Korrelation von Anfrageanomalie, Worker-Fehler und Ausführung.

Beim Hunting ist der kürzeste Irrweg, nur bekannte Webshell-Strings zu jagen. Am Tag Null der Veröffentlichung erscheint zuerst oft Worker-Rauschen und Shell-Kinder, weshalb ich mit den Prozessbäumen von Apache und FPM beginnen und erst danach Dateien schließen würde, die mit php2shell Erkennung zusammenhängen.

Wie man php2shell Erkennung mit Sigma und WAF auf hoher Ebene denkt

Sigma-artige Regeln zur php2shell Erkennung sollen Logik beschreiben, keinen Payload. Beispiele generischer Bedingungen sind Elternprozesse des Webservers oder des FPM-Pools, die einen Shell-Interpreter oder ein Download-Utility erzeugen, besonders nach einer Serie fataler Speicherfehler oder Kind-Neustarts. Eine weitere Familie korreliert POST-Methoden mit Multipart-Feldern oder Headern außerhalb der Anwendungsbaseline und einer Fehlerantwort in der Initialisierungsphase. Schwellen müssen aus dem legitimen Verkehr der Umgebung entstehen, weil echte Uploads und schwere Imports existieren.

Auf der WAF-Seite beschrieb die Cloudflare verwaltete Schutzmaßnahmen für php2shell, die am 21. Oktober 2026 um 03:02 UTC aktiviert wurden und Free- sowie bezahlte Pläne mit WAF abdeckten. Der Beitrag spricht von einem Regelsatz anomaler Ausführung und von der Erkennung der vollständigen Transaktion, die Anfrage- und Antwortsignale in derselben HTTP-Transaktion kombiniert. So sinkt das Falschpositiv und eine verdächtige Origin-Antwort wird blockiert. Das ist Defense in Depth. Cloudflare selbst und php.net wiederholen, dass nur der Patch das Problem schließt, während Angreifer bereits versuchten, den Verkehr gegen die Regeln zu mutieren.

Detektion ohne Inventar wird Theater. Die Sigma-Regel oder den WAF, den ich morgen eingeschaltet ließe, wären jene, die anomale Kindprozesse und Initialisierungsfehler im Zusammenhang mit php2shell melden, während parallel das Patch-Ticket der behobenen Versionen mit Owner und Frist steigt. WAF allein wird keine dauerhafte Risikoakzeptanz.

Was in der Incident Response und bei der Behebung von php2shell zu tun ist

Die vollständige Behebung von php2shell ist das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder gleichwertig das LTS-Vendor-Paket mit Neustart aller Worker. Liegt die Linie bei 8.1 oder älter, gibt das PHP-Projekt keine normalen Releases heraus, sondern minimale Quell-Backports für 7.4, 8.0 und 8.1. Die gekreuzte Orientierung von CISA, NCSC und dem Kanadischen Zentrum lautet, Systeme zu isolieren oder aus der Exposition zu nehmen, die nicht auf eine behobene Linie steigen können. Konfigurationsmitigationen des offiziellen Hinweises reduzieren spezifische Pfade, ersetzen das behobene Binary jedoch nicht.

Sobald in der Incident Response Evidenz einer Shell unter dem Worker vorliegt, behandeln Sie den Fall bis zum Gegenbeweis als Kompromittierung und isolieren Host oder Pool, während Sie Access-Logs, PHP-error_log, Service-Journal und Prozestelemetrie bewahren. Anschließend jagen Sie Webshell und Persistenz, rotieren Credentials, die im Worker-Speicher gelegen haben könnten, und validieren den Patch-Level in der gesamten Flotte, nicht nur auf dem symptomatischen Host. Nebenwirkungen des Patches können geändertes OOM-Verhalten und Session-Pfade umfassen, weshalb Tests in Homologation sinnvoll sind, wenn der Kalender es erlaubt. Nutzen Sie das nicht als Ausrede, internetseitige Systeme gegenüber php2shell verwundbar zu lassen.

Nach dem Patch bleiben oft vergessene Appliances und gepinnte Container-Images übrig. Ich würde den Incident erst mit neuem Inventar zu php2shell schließen und außerdem die Bestätigung verlangen, dass hinter dem Load Balancer kein alter Worker mehr steht.

Häufige Fragen zu php2shell

Dieser Abschnitt schließt die Fragen, die am 21. Oktober 2026 in Red-Team-Engagements und War Rooms zu CVE-2026-109618 und zum Set php2shell am häufigsten auftauchen. Die Antworten trennen, was der offizielle Hinweis bestätigt, von dem, was noch von Dritt-Telemetrie abhängt, und verstärken außerdem die ethische Grenze des Tests. Nutzen Sie sie als verbale Checkliste mit Kunde oder SOC, ohne FAQ in einen PoC zu verwandeln.

Ist CVE-2026-109618 dasselbe wie php2shell?

Nicht allein, weil php2shell der Spitzname für das Paar CVE-2026-109618 und CVE-2026-109619 ist. Der erste deckt die Korruption über OOM in Initialisierung und Bereinigung der Anfrage ab, und der zweite deckt globalen stale Zustand zwischen Anfragen im selben Worker ab. In Inventar und Patch-Ticket behandeln Sie beide gemeinsam. In Hunting und Bedrohungsmodell behalten Sie den Unterschied der Vorbedingungen, weil Sensoren und Teilmitigation bei php2shell nicht identisch sind.

Blockiert die Anwendungsauthentifizierung die Ausnutzung?

In den Ästen, in denen der Auslöser vor dem Anwendungscode liegt, nein. Der Hinweis von php.net und Labornachstellungen betonen nicht authentifizierte Anfragen, die den Motor erreichen, und Login-Controls des CMS sind nicht das richtige Control für diese Klasse. Deshalb muss der Fund als Runtime-Exposition von php2shell klassifiziert werden und nicht als Plugin- oder authentifizierter Formularfehler. PHP RCE ohne Authentifizierung gehört genau in diese Einordnung.

Darf man sich nur auf den WAF verlassen, bis der Patch läuft?

Nicht als vollständige Lösung, weil ein verwalteter WAF, wie von Cloudflare beschrieben, Exposition senken und Zeit gewinnen kann, aber Bypass-Risiko und Falschnegativ bleiben, wenn der Edge-Parser nicht dasselbe sieht wie PHP. Isolation exponierter Systeme bleibt die Alternative, wenn der Patch stockt. Dauerhafte Risikoakzeptanz nur mit WAF ist eine fragile Entscheidung angesichts von PHP RCE ohne Authentifizierung bei php2shell.

Sind PHP 7.x und 8.1 vom Projekt behoben?

Das Projekt pflegt für diese Linien keine normalen Releases. Es veröffentlichte minimale Quell-Backports für 7.4, 8.0 und 8.1 und verweist auf Pakete von Distributionen und LTS-Vendors. Ohne bestätigtes behobenes Paket lautet die Orientierung mehrerer Behörden Migration oder Isolation. In autorisierten Pentests registrieren Sie die EOL-Linie als kritische Exposition gegenüber php2shell, bis Belege für angewandten Backport und neu gestartete Worker vorliegen.

Gibt es schon von allen Behörden bestätigte Massenausnutzung?

Am 21. Oktober 2026 gibt es keinen einheitlichen Konsens. Die CISA meldete in ihrer Warnung keine beobachtete Ausnutzung, während Cloudflare, watchTowr und andere Firmen Versuche oder Angriffsverkehr meldeten. Das Kanadische Zentrum sprach von verfügbarem PoC ohne zu diesem Datum identifizierte aktive Ausnutzung. Behandeln Sie die Divergenz transparent und priorisieren Sie Patch sowie Prozessüberwachung im Zusammenhang mit php2shell.

Wie belegt man Exposition ohne auszunutzen?

Vergleichen Sie Version und Paket mit den behobenen Releases, bestätigen Sie SAPI und Netzexposition und dokumentieren Sie das. Im eigenen Labor oder in der vom RoE autorisierten Umgebung bleibt der Konzeptnachweis isoliert. Auf fremden Zielen ohne formelle Autorisierung ist jeder Auslöser illegal und ethisch außerhalb des Scopes. Der akzeptable Beleg im Bericht ist meist Paket plus Konfiguration plus Oberflächenmapping zu php2shell, nicht ein induzierter Crash in Produktion.

Fazit

CVE-2026-109618 und CVE-2026-109619 verschieben die Diskussion vom Plugin-Bug zum Runtime-Fehler, und die Auswirkung ist eine Shell unter dem Benutzer des Webservers. Für Red Team und Detektion ist die nützliche Lesart von php2shell, SAPI und Patch-Level zu inventarisieren und Initialisierungsfehler mit anomalen Kindprozessen zu korrelieren. Konfigurationsmitigationen gelten als Pfadreduzierer und niemals als Schließen des Risikos.

Die meisten Umgebungen gewinnen mehr mit einer Flotte auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder einem verifizierten LTS-Äquivalent als mit der Debatte, welches Labor den ersten Exploit zu php2shell sah. Die Antwort ändert sich, wenn PHP in einer Appliance ohne Update-Kanal steckt, denn dann wird der erste Schritt Isolation und Druck auf den Lieferanten. Die Kompromissjagd sollte annehmen, dass das Fenster nach dem 21. Oktober 2026 bereits feindlich war.

Dieser Beitrag hat informativen und bildenden Charakter zu php2shell sowie zu den Kennungen CVE-2026-109618 und CVE-2026-109619. Er ersetzt weder die Bewertung Ihres Lieferanten noch die Ihrer Sicherheitsteams oder der für die Umgebung Verantwortlichen. Technische Tests dürfen ausschließlich auf eigener Infrastruktur oder mit formeller schriftlicher Autorisierung des Systeminhabers stattfinden.