--- title: 'PHP2Shell: kritische RCE im gesamten PHP | DevSense' description: 'Analyse von PHP2Shell — CVE-2026-109618 und CVE-2026-109619, einer nicht authentifizierten RCE im PHP-Kern: wie die Schwachstellen aufgebaut sind, warum sie so gefährlich sind, wer zur Behebung ausgerückt ist und wie Sie Ihren Server schützen. Ohne funktionierenden Exploit, zu Bildungszwecken.' faq: - { question: 'Was ist PHP2Shell und welche PHP-Versionen sind betroffen?', answer: 'PHP2Shell ist der gemeinsame Name zweier Schwachstellen im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, offengelegt am 21. Oktober 2026. Zusammen ermöglichen sie nicht authentifizierte Remote Code Execution über das ganz normale Parsen eines HTTP-Requests. Betroffen sind praktisch alle Zweige des letzten Jahrzehnts; die Fixes erschienen in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, für 8.1/8.0/7.4 hat PHP minimale Backports veröffentlicht.' } - { question: 'Braucht der Angreifer eine Anmeldung oder ein verwundbares Plugin?', answer: 'Nein. Genau das ist der Kern: Das Leck sitzt im PHP-Kern selbst, auf dem Pfad, der den eingehenden Request parst und noch vor dem Anwendungscode ausgeführt wird. Es braucht weder Login noch ein bestimmtes CMS noch ein verwundbares Plugin — es genügt, dass der Server HTTP-Requests annimmt und PHP ausführt. Deshalb sprechen Forscher von „70 % des Webs“: Das ist der Anteil der PHP-Seiten, nicht die Zahl der tatsächlich kompromittierten Server.' } - { question: 'Wird die Schwachstelle in realen Angriffen ausgenutzt?', answer: 'Zum Zeitpunkt dieses Textes (dritter Tag nach der Offenlegung) gibt es keine öffentlich bestätigten Einbrüche gerade über PHP2Shell, aber Cloudflare und andere beobachten bereits Scans und Exploit-Versuche, und zwar mit mutierenden Payloads zur Umgehung der Filter. Bei einer nicht authentifizierten RCE mit einem CVSS von bis zu 9.2 bemisst sich das Fenster zwischen „niemand hat es rechtzeitig aktualisiert“ und „die Massenangriffe sind da“ in Tagen.' } - { question: 'Was ist jetzt sofort zu tun, wenn ein sofortiges Update nicht möglich ist?', answer: 'Das PHP-Update ist die einzige vollständige Lösung. Bis es ausgerollt ist: Schalten Sie eine WAF ein (Cloudflare, Fastly, Akamai, Imperva und die Cloud-Anbieter haben den Schutz bereits standardmäßig ausgerollt), begrenzen Sie die Größe des Request-Bodys am Reverse Proxy, deaktivieren Sie session.upload_progress.enabled und auf PHP 8.5 fatal_error_backtraces, und achten Sie in den Logs auf Speichermangel-Fehler mit „Unknown on line 0“ und auf abstürzende Worker. Das senkt das Risiko, schließt das Leck aber nicht.' } published: '2026-10-23' --- # PHP2Shell: kritische RCE im gesamten PHP — was passiert ist und wie Sie sich schützen Es gibt eine besondere Sorte von Schwachstellen — solche, die nicht in irgendjemandes Plugin oder in einer schiefen Zeile einer konkreten Anwendung wohnen, sondern im Fundament selbst, auf dem alles andere steht. PHP2Shell ist genau eine davon. Es ist kein Leck in WordPress, kein Fehlgriff eines einzelnen Entwicklers und kein vergessenes `eval()`. Es ist ein Riss in der tragenden Wand: in genau dem Code des PHP-Kerns, der den eingehenden Request parst, noch bevor die erste Zeile Ihrer Anwendung ausgeführt wird. Am 21. Oktober 2026 veröffentlichte PHP Notfall-Releases und legte zwei Schwachstellen offen — **CVE-2026-109618** und **CVE-2026-109619** —, die zusammen das ermöglichen, wovor es im Web kaum etwas Schlimmeres gibt: **nicht authentifizierte Remote Code Execution**. Ohne Login. Ohne verwundbares Plugin. Ohne einen einzigen Klick des Opfers. Dieser Artikel entstand am dritten Tag nach der Offenlegung, als der Patch bereits da ist, aber das halbe Internet noch nicht aktualisiert hat — und deshalb ist er ohne eine einzige Zeile funktionierenden Exploit-Codes geschrieben. Wir sezieren, was zerbrochen ist und warum das so gefährlich ist, geben aber keine Waffe in die Hand. Das Ziel ist, dass Sie den Gegner verstehen und die Tür schließen, nicht dass jemand aus unserem Text einen Angriff zusammenbaut. **Verwandte Leitfäden:** [Web-Angriffe und ihre Abwehr](web-attacks-and-prevention) · [Ausfallsichere Integrationen](resilient-external-integrations) · [Observability und Monitoring](observability-monitoring-laravel) · [Zero-downtime Deployment](zero-downtime-deployment-laravel) ## Inhalt * [Kurz: was Sie in dreißig Sekunden wissen müssen](#tldr) * [Warum eine Schwachstelle im Kern eine andere Größenordnung hat](#why-core) * [Timeline: wie eine KI das Leck im gesamten PHP fand](#timeline) * [Zwei Türen: was sich hinter den beiden CVEs verbirgt](#two-doors) * [Wie schwer der Schaden wiegt](#impact) * [Der Blick des Angreifers: Bedrohungsmodell ohne Anleitung](#attacker) * [Wer bereits zur Behebung ausgerückt ist](#responders) * [Gibt es bereits Opfer](#victims) * [Wie Sie sich schützen: Schritt für Schritt](#defense) * [Wie Sie den Angriff in Ihren Logs erkennen](#detection) * [PHP lebt — und das ist der Beweis](#php-alive) * [Checkliste](#checklist) * [Selbsttest-Quiz](#self-test-quiz) --- ## Kurz: was Sie in dreißig Sekunden wissen müssen * **Was:** zwei Schwachstellen des PHP-Kerns unter dem gemeinsamen Namen PHP2Shell — CVE-2026-109618 und CVE-2026-109619. * **Wie bedrohlich:** nicht authentifizierte Remote Code Execution (RCE), Schweregrad bis zu **CVSS 9.2**. * **Wen es trifft:** praktisch alle PHP-Zweige des letzten Jahrzehnts, unabhängig von CMS und Framework. * **Wo behoben:** PHP **8.5.12, 8.4.27, 8.3.36, 8.2.35**; für 8.1/8.0/7.4 — minimale Backports des PHP-Teams. * **Was zu tun ist:** PHP aktualisieren und PHP-FPM sowie die Queue-Worker neu starten. Sofort. Alles andere sind nur temporäre Krücken. Wenn Sie dies aus der Produktion auf einer ungepatchten Version lesen — schließen Sie den Artikel, aktualisieren Sie, kommen Sie zurück. Im Ernst. --- ## Warum eine Schwachstelle im Kern eine andere Größenordnung hat Die meisten Web-Schwachstellen gleichen einem unverschlossenen Fenster in einer einzigen bestimmten Wohnung: ein Bug in einem Plugin, eine SQL-Injection in einem selbstgeschriebenen Controller, eine vergessene Rechteprüfung. Reparieren Sie die Wohnung — das Fenster ist zu. PHP2Shell ist ein Fabrikationsfehler im Schloss, das an jeder zweiten Tür des Planeten sitzt. PHP verarbeitet einen eingehenden Request in Schichten. Zuerst der Kern: Er liest die Header, parst den Request-Body, füllt die superglobalen Arrays `$_POST`, `$_FILES`, `$_COOKIE`. Und erst danach erreicht die Steuerung Ihren Code — den Router von Laravel, den WordPress-Kern, die erste Zeile, die Sie geschrieben haben. PHP2Shell wohnt **in der ersten Schicht**. Der verwundbare Pfad wird bei jedem und immer ausgeführt, einfach weil der Server einen Request angenommen hat. Daher auch die berühmte Formulierung der Forscher von den „70 % des Internets“. Wichtig ist zu verstehen, was das bedeutet: PHP bedient rund 70 % aller Websites der Welt, und die theoretische Angriffsfläche sind sie alle. Das heißt **nicht**, dass bereits 70 % der Seiten gehackt sind oder dass jede von ihnen garantiert in einem Request durchbrochen wird. Es heißt, dass die Obergrenze dieser Schwachstelle so groß ist wie das Web. --- ## Timeline: wie eine KI das Leck im gesamten PHP fand Diese Geschichte hat ein Detail, dessentwegen sie in die Lehrbücher eingehen wird — und das ist nicht die Schwachstelle selbst. Gefunden wurde sie nicht durch klassisches manuelles Audit, sondern durch das Zusammenspiel von Mensch und KI. Forscher von Wiz suchten mithilfe moderner Modelle, und nach ihren eigenen Worten leistete das Modell einen „unschätzbaren Beitrag“ nicht nur beim Aufspüren, sondern auch dabei, die Funde in funktionierende Exploits gegen mehrere Ziele zu verwandeln — „innerhalb von Stunden“. Wir leben in einer Welt, in der das Fuzzing des PHP-Kerns nicht mehr nur von einem Menschen mit Debugger betrieben wird, sondern auch von einer KI — und beide Seiten der Barrikade haben das bereits begriffen. Chronologie des Jahres 2026 (laut Wiz): | Datum | Ereignis | |------|---------| | 19. August | Die erste der Schwachstellen wird gefunden | | 20. August | Nicht authentifizierte RCE gegen Drupal bestätigt | | 21. August | Nicht authentifizierte RCE gegen WordPress bestätigt | | 24. August | An das PHP-Sicherheitsteam übergeben | | 21. September | PHP bestätigt das Problem und startet die koordinierte Behebung | | 21. Oktober | Patches veröffentlicht und öffentliche Offenlegung erfolgt | Fast zwei Monate — zwischen der stillen Übergabe an das PHP-Team und der öffentlichen Offenlegung. Genau das ist der richtige, „erwachsene“ Prozess: erst reparieren, dann erzählen. Der Artikel, den Sie lesen, entstand zwei Tage nach der letzten Zeile dieser Tabelle. --- ## Zwei Türen: was sich hinter den beiden CVEs verbirgt Unter dem Namen PHP2Shell verbergen sich zwei verschiedene Defekte — zwei Türen in denselben Raum. Verschiedene Forscher und Hersteller beschreiben die zugrunde liegenden Bugs mit kleinen Abweichungen in den Details, und hinter jedem CVE steckt eher eine Klasse von Problemen als eine einzige Zeile. Wir bleiben bewusst auf der Ebene der Mechanik — „was genau zerbrochen ist“ —, ohne bis zum Rezept für die Eskalation zur Shell hinabzusteigen. ### CVE-2026-109618 — Verarbeitung eingehender Request-Daten Die erste Tür öffnet sich in der Phase, in der PHP den Body eines POST-Requests parst und Uploads verarbeitet. Das Problem liegt im Umgang mit dem Speicher auf diesem Pfad: Bei einer bestimmten Form der Eingabedaten greift der Kern auf Speicher zu, den er bereits freigegeben hat, oder verletzt die Buchführung bei dessen Zuteilung. Dort, wo ein sauberes „zugeteilt — genutzt — freigegeben“ stehen sollte, entsteht ein Fenster, in dem der Speicherzustand nicht mehr dem entspricht, was der Code erwartet. Und ein gestörter Umgang mit dem Speicher in nativem Code ist ein klassisches Sprungbrett: Von ihm führt der Weg sowohl zum Leck von Fragmenten des Prozessspeichers (und damit zur Umgehung von Schutzmechanismen wie ASLR) als auch zur Kontrolle über die Ausführung. Ein entscheidendes Detail: Dieser Pfad erfordert weder eine Anmeldung noch eine spezielle Konfiguration der Anwendung. Es genügt, dass PHP den Request-Body automatisch parst — und das tut es immer. ### CVE-2026-109619 — Restzustand zwischen Requests Die zweite Tür ist subtiler und in gewissem Sinne eleganter. PHP-FPM ist ein langlebiger Prozess: Ein und derselbe Worker bedient Request um Request, ohne das Framework neu zu laden (warum das zugleich schnell und gefährlich ist, haben wir im Artikel über [Queues in der Produktion](laravel-queues-production#memory) behandelt). Bleibt nach der Verarbeitung eines Requests im Worker ein „Müll“-Zustand zurück — etwa vom Mechanismus zur Fortschrittsverfolgung von Datei-Uploads (`session.upload_progress`) oder von der Erzeugung von Backtraces fataler Fehler —, dann kann der nächste Request auf diese abgestandenen Daten stoßen. Ein Request stellt die Falle, ein zweiter tappt hinein. Die Tücke liegt darin, dass ein Teil dieser Mechanismen arbeitet, selbst wenn die Anwendung sie nie explizit aufgerufen hat. `session.upload_progress` ist standardmäßig aktiviert und greift ohne ein einziges `session_start()` in Ihrem Code. > [!NOTE] > Merken Sie sich zwei Einstellungen aus der zweiten Tür — `session.upload_progress.enabled` und (auf PHP 8.5) `fatal_error_backtraces`. Weiter unten, im Abschnitt zur Abwehr, sind es genau diese, die wir abdecken werden, falls ein sofortiges Update nicht möglich ist. --- ## Wie schwer der Schaden wiegt RCE ist die Spitze der Nahrungskette der Schwachstellen. Nicht „Daten abgeflossen“, nicht „Seite verändert“, sondern **fremder Code wird auf Ihrem Server mit den Rechten Ihres Web-Prozesses ausgeführt**. Was das in der Praxis bedeutet: * **Vollständige Kontrolle über die Anwendung.** Der Angreifer liest und verändert alles im Code und in den Dateien, auf die `www-data` Zugriff hat. * **Zugriff auf Geheimnisse.** `.env` mit dem Datenbankpasswort, Schlüssel von Zahlungssystemen, API-Tokens, `APP_KEY` — alles, was der Prozess lesen kann, liest auch der Angreifer. * **Die gesamte Datenbank.** Nicht über eine ausgefeilte Injection, sondern direkt — mit denselben Zugangsdaten wie die Anwendung. * **Laterale Bewegung.** Der Server wird zum Brückenkopf: Von hier aus wird das interne Netz gescannt, werden benachbarte Dienste angegriffen, wird über eine Web-Shell ein Fuß in der Tür behalten. * **Stille.** Eine erfolgreiche Ausnutzung kann ein ganz normales HTTP 200 zurückgeben und den Worker nicht zum Absturz bringen. Von außen — nichts, von innen — der Fremde ist schon im Haus. Für eine Seite wie DevSense, auf der es keine Zahlungen und keine personenbezogenen Nutzerdaten über das Nötigste hinaus gibt, ist der direkte Schaden geringer als für einen Online-Shop oder eine Bank. Aber „geringer“ heißt nicht „keiner“: Selbst unser Server bedeutet Zugriff auf die Datenbank, auf die Mail-Schlüssel, auf die Deployment-Infrastruktur und einen hervorragenden Brückenkopf für Angriffe auf andere. Deshalb haben [wir PHP aktualisiert](../tools/dockerfile-php-best-practices) noch am selben Tag. --- ## Der Blick des Angreifers: Bedrohungsmodell ohne Anleitung Es ist nützlich, eine Schwachstelle mit den Augen des Angreifers zu betrachten — so wird klarer, wo die Abwehr anzusetzen ist. Aber „der Blick des Angreifers“ meint hier das **Bedrohungsmodell und die Ökonomie des Angriffs**, kein Schritt-für-Schritt-Rezept. Das Rezept geben wir aus Prinzip nicht preis: Es ist zwei Tage alt, es trifft eine nicht authentifizierte RCE, und die Hälfte der Server ist noch nicht geschlossen. Was den Angreifer in einer solchen Lage antreibt: * **Masse ist wichtiger als Präzision.** Wenn „das ganze Web“ verwundbar ist, wählt niemand sein Opfer gezielt aus. Ein breiter Scan wird gestartet: Wir probieren wahllos alle durch und setzen uns dort fest, wo es funktioniert hat. Ihre Seite gerät nicht unter Beschuss, weil Sie interessant wären, sondern weil Sie existieren und auf Requests antworten. * **Wettlauf mit dem Patch.** Der Wert eines Exploits ist in den ersten Tagen am höchsten, solange die Masse noch nicht aktualisiert hat. Daher der Aktivitätsschub unmittelbar nach der Offenlegung — er ist bereits zu beobachten. * **Umgehung der Filter.** Sobald die WAF-Hersteller Regeln ausgerollt haben, begannen die Angreifer, die Payload zu mutieren, um ihnen nicht ins Netz zu gehen. Das hat Cloudflare bereits festgehalten. Fazit für Sie: Eine WAF ist gewonnene Zeit, kein Sieg. Gewonnen wird nur mit dem Patch. * **Auch auf ihrer Seite steht Automatisierung.** Wenn eine KI auf Seiten der Forscher half, die Schwachstelle in Stunden zu finden und zu eskalieren, dann ist auch auf Seiten der Angreifer der Zyklus „vom CVE zum Massenscanner“ kürzer geworden als je zuvor. Der praktische Sinn dieser Optik ist ein einziger: Rechnen Sie nicht damit, dass „meine kleine Seite niemanden interessiert“. In einer Welt der breitflächigen Angriffe gibt es keine uninteressanten Seiten. --- ## Wer bereits zur Behebung ausgerückt ist Die gute Nachricht: Die Branche hat auf PHP2Shell wie ein eingespielter Organismus reagiert, und das ist vielleicht die beste Illustration dafür, dass das PHP-Ökosystem lebt und gesund ist. Die Offenlegung war koordiniert — zur Stunde X stand der Schutz bereits. * **Cloudflare** rollte WAF-Regeln **etwa 9 Stunden vor der öffentlichen Offenlegung** aus und aktivierte den Schutz standardmäßig am 21. Oktober um 3:02 UTC — auf allen Tarifen, einschließlich dem kostenlosen, ohne Zutun des Kunden. Nach ihren Angaben sehen sie bereits angreifenden Traffic und dessen Mutationen. * **Fastly, Akamai, Imperva** — rollten eigene Schutzregeln für Kunden aus, die nicht sofort aktualisieren können. * **AWS, Google Cloud, Microsoft, Vercel** — veröffentlichten Leitfäden zur Reaktion und Schutz auf der Ebene ihrer Plattformen. * **Automattic** (das Unternehmen hinter WordPress.com) und weitere Beteiligte des Ökosystems — stehen auf der Liste derer, die bei der koordinierten Reaktion geholfen haben. Besonders hervorzuheben ist das PHP-Sicherheitsteam selbst: zwei Monate stiller Arbeit, die synchrone Veröffentlichung von Patches über alle unterstützten Zweige hinweg und sogar Backports für Zweige, deren offizieller Support bereits ausgelaufen ist (7.4, 8.0, 8.1). Für ein Projekt, das in Kommentaren seit Jahren zu Grabe getragen wird, ist das eine vorbildliche Reaktion. --- ## Gibt es bereits Opfer Hier gilt es, ehrlich zu sein und keine Panik zu schüren. **Am dritten Tag nach der Offenlegung gibt es keine öffentlich bestätigten Einbrüche gerade über PHP2Shell.** Noch ist keine einzige große Organisation als Opfer genannt worden. Doch einige Dinge stehen sicher fest: * Funktionierende Exploits existieren — sie wurden von Forschern gegen frische Images von WordPress, Drupal und Joomla demonstriert. Das ist eine Demonstration der Angriffsfläche, nicht die Wurzel des Problems: Es geht nicht um diese CMS, sondern um das PHP darunter. * Scans und Exploit-Versuche laufen bereits — davon berichten sowohl Cloudflare, das angreifenden Traffic beobachtet, als auch Branchenberichte, die „das Auftauchen von Exploit-Versuchen“ festhalten. * Das Ausbleiben öffentlicher Opfer am dritten Tag ist kein „nochmal gut gegangen“, sondern ein „noch zu früh“. Zwischen flächendeckenden Scans und den ersten öffentlichen Berichten über Einbrüche vergehen in der Regel Wochen. Das Fenster, in dem Sie das Update rechtzeitig schaffen müssen, ist gerade jetzt offen. Einfacher gesagt: Die Stille auf der Anzeigetafel ist keine Entwarnung, sondern ein Vorsprung. Nutzen Sie ihn. --- ## Wie Sie sich schützen: Schritt für Schritt ### 1. Aktualisieren Sie PHP — das ist die einzige echte Lösung Alles Weitere unten sind Krücken, die Zeit kaufen. Das Leck schließt nur der Patch. ```bash # Debian/Ubuntu, Repository von Ondřej Surý (wie bei uns) sudo apt-get update sudo apt-get install --only-upgrade -y \ $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php8.5*' | awk '$1 == "ii" {print $2}') # Alles neu starten, was die alte Binary im Speicher hält sudo systemctl restart php8.5-fpm sudo supervisorctl restart all # Queue-Worker sind ebenfalls PHP ``` Zielversionen: **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** oder neuer. Prüfen Sie sowohl CLI als auch FPM: ```bash php -v | head -1 /usr/sbin/php-fpm8.5 -v | head -1 ``` > [!WARNING] > Der Neustart von PHP-FPM ist zwingend. Der langlebige Prozess hält die alte, verwundbare Binary auch nach `apt upgrade` im Speicher, bis er neu gestartet wird. Dasselbe gilt für Queue-Worker unter Supervisor oder Horizon — sie sehen das neue PHP erst nach einem Neustart. Ausführlich zu Update und Neubau der Images — in unserer Analyse des [Production-Images für PHP](../tools/dockerfile-php-best-practices). ### 2. Richten Sie eine WAF ein Wenn Sie hinter Cloudflare sind — der Schutz ist bereits standardmäßig aktiv, prüfen Sie nur, dass die Regeln im Blockiermodus laufen. Fastly, Akamai, Imperva und die Cloud-Anbieter haben Entsprechendes ausgerollt. Denken Sie an die Payload-Mutation: Eine WAF ist eine temporäre Maßnahme. ### 3. Begrenzen Sie den Request-Body an der Grenze Schneiden Sie am Reverse Proxy (nginx, Load Balancer) anomal große Request-Bodys ab, bevor sie PHP erreichen. Das heilt nicht, bremst aber einen erheblichen Teil der automatischen Versuche aus. ### 4. Decken Sie die zweite Tür per Einstellung ab Falls der Patch noch nicht ausgerollt ist — deaktivieren Sie die Mechanismen, über die CVE-2026-109619 arbeitet. DevSense nutzt sie nicht, auf den Betrieb der Seite hat das keinen Einfluss: ```ini ; /etc/php/8.5/fpm/conf.d/99-hardening.ini session.upload_progress.enabled = 0 fatal_error_backtraces = 0 ; nur PHP 8.5 expose_php = Off ``` ```bash sudo systemctl restart php8.5-fpm ``` Das senkt die Exposition, **ersetzt aber nicht das Update**. --- ## Wie Sie den Angriff in Ihren Logs erkennen Abwehr ohne Observability ist blind. Hier die ehrlichen Indikatoren, auf die zu achten sich lohnt (keiner von ihnen beweist für sich allein einen Einbruch — entscheidend ist die Korrelation): * **In den PHP-FPM-Logs:** `Allowed memory size ... exhausted` in Verbindung mit `Unknown on line 0`. Die Zeile `on line 0` bedeutet, dass der Absturz in der Phase der Request-Initialisierung geschah, noch vor dem Anwendungscode — genau dort wohnt die erste Tür. * **Worker-Abstürze:** Segfaults (`SIGSEGV`, `exited on signal 11`) in den Logs von PHP-FPM oder Apache, besonders in Serien. * **Anomale Requests:** POST mit ungewöhnlich langen Feldnamen (im Bereich von Megabytes), Binärdaten und Nullbytes in den Feldwerten. * **Ungewöhnlich große `PHPSESSID`-Cookies** — eines der Anzeichen, auf die die Forscher selbst hinweisen. * **Verwaiste Prozesse des Web-Nutzers:** eine Shell, gestartet unter `www-data`, ist kein Anzeichen mehr, sondern fast schon ein Urteil: ```bash ps -eo user,pid,ppid,cmd | awk '$1=="www-data"' | grep -vE "php-fpm|nginx" sudo grep -h "Unknown on line 0" /var/log/php8.5-fpm.log* 2>/dev/null | tail ``` Wie Sie solche Signale in ein dauerhaftes Monitoring und in Alerts einbauen — im Artikel über [Observability](observability-monitoring-laravel). --- ## PHP lebt — und das ist der Beweis PHP wird mit beneidenswerter Regelmäßigkeit zu Grabe getragen. „Tote Sprache“, „Legacy“, „alle sind zu Node und Go abgewandert“ — dieser Nachruf wird jedes Jahr geschrieben. PHP2Shell ist, so paradox es klingt, ein Argument in genau die entgegengesetzte Richtung. Erstens ist eine Schwachstelle dieses Ausmaßes nur bei einer Technologie möglich, auf der tatsächlich ein riesiger Teil des Webs steht. Tote Sprachen landen nicht in den Schlagzeilen der CISA und zwingen Cloudflare nicht dazu, neun Stunden vor der Offenlegung einen Schutz auszurollen. In ein Leck von der Größe von 70 % des Internets fällt nur das hinein, was dieses Internet trägt. Zweitens — und das ist das Entscheidende — schauen Sie sich die Reaktion an. Das PHP-Sicherheitsteam hat eine vorbildliche koordinierte Behebung durchgezogen, Patches über alle Zweige hinweg synchron veröffentlicht und die Fixes sogar in Zweige ohne offiziellen Support zurückportiert. Die gesamte Branche — von Automattic bis AWS — hat wie ein einziger Organismus gearbeitet. So verhält sich kein sterbendes Projekt, sondern ein reifes, lebendiges Ökosystem mit erwachsenen Prozessen. PHP 8.5 mit Property Hooks, asymmetrischer Sichtbarkeit, typisierten Eigenschaften und dem Pipe-Operator ist eine moderne Sprache, kein Museumsstück. Lebendiges hat ein Immunsystem, und im Oktober 2026 hat es schnell und geschlossen angeschlagen. Lebendiger als alle Lebenden — auch deshalb, weil es solche Wunden schnell zu heilen weiß. --- ## Checkliste 1. PHP ist auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 oder neuer aktualisiert — sowohl CLI als auch PHP-FPM. 2. PHP-FPM ist neu gestartet; die Queue-Worker (Supervisor/Horizon) sind neu gestartet. 3. Es ist geprüft, dass der FPM-Prozess nicht die alte Binary hält (`/proc//exe` ohne die Markierung `(deleted)`). 4. Die WAF ist eingeschaltet und im Blockiermodus; denken Sie an die Vorläufigkeit dieser Maßnahme. 5. An der Grenze ist die Größe des Request-Bodys begrenzt. 6. Falls der Patch nicht ausgerollt ist — `session.upload_progress.enabled` und `fatal_error_backtraces` sind deaktiviert. 7. Die Logs sind auf `Unknown on line 0`, Segfaults und Shells unter `www-data` geprüft. 8. Die Container-Images sind neu gebaut und neu deployt, falls PHP aus einem Image installiert wird. --- ## Fazit PHP2Shell ist einer der seltenen Fälle, in denen eine Schwachstelle nicht nur dadurch interessant ist, was sie zerbricht, sondern auch dadurch, was sie zeigt. Sie zerbricht das Fundament: eine nicht authentifizierte RCE im Kern, auf dem ein großer Teil des Webs steht. Und sie zeigt — dass das Ökosystem um diesen Kern herum lebendig, schnell und geschlossen ist. Der Patch ist da, die großen Player haben sich schützend vor die gestellt, die es nicht rechtzeitig geschafft haben, und von Ihnen wird eine einzige, einfache Handlung verlangt: aktualisieren und neu starten. Tun Sie es, bevor der Vorsprung aufgebraucht ist. --- ## Selbsttest-Quiz ### Frage 1: Warum ist PHP2Shell gefährlicher als eine typische Schwachstelle in einem CMS-Plugin? - A) Weil sie für Scanner schwerer zu entdecken ist. - B) Weil sie im PHP-Kern sitzt, auf dem Pfad des Request-Parsings, und vor dem Anwendungscode greift — ohne Anmeldung und unabhängig von CMS oder Framework. - C) Weil sie nur veraltete PHP-Versionen betrifft.
Antworten anzeigen **Antwort: B** Der Defekt wohnt in der ersten Schicht der Request-Verarbeitung, die allen PHP-Anwendungen gemeinsam ist. Weder Login noch ein bestimmtes CMS noch ein verwundbares Plugin sind nötig — es genügt, dass der Server Requests annimmt und PHP ausführt.
### Frage 2: Warum muss nach `apt upgrade` zwingend PHP-FPM und die Queue-Worker neu gestartet werden? - A) Sonst werden die Konfigurationsdateien nicht aktualisiert. - B) Weil langlebige Prozesse die alte, verwundbare PHP-Binary im Speicher halten, bis man sie neu startet. - C) Um den OPcache von statischen Seiten zu leeren.
Antworten anzeigen **Antwort: B** PHP-FPM und die Queue-Worker sind langlebige Prozesse. Sie führen die alte, in den Speicher geladene Binary auch nach dem Paket-Update weiter aus, bis sie neu gestartet werden. Prüfen lässt sich das über den symbolischen Link `/proc//exe`.
### Frage 3: Warum ist eine WAF gewonnene Zeit und keine vollständige Lösung? - A) Die WAF verlangsamt die Seite und man muss sie abschalten. - B) Weil Angreifer die Payload mutieren, um die Regeln zu umgehen — das Leck schließt nur das PHP-Update. - C) Weil eine WAF nur vor authentifizierten Angriffen schützt.
Antworten anzeigen **Antwort: B** WAF-Regeln filtern bekannte Angriffsformen, aber die Angreifer mutieren die Payload bereits, um ihnen nicht ins Netz zu gehen (das hat Cloudflare festgehalten). Eine WAF senkt das Risiko und kauft Zeit für das Update, aber die einzige vollständige Lösung ist der Patch.