PHP2Shell: Deine Website ist sauber. PHP interessiert das nicht.

Da pflegst du deine Website.

WordPress aktuell.

Plugins aktuell.

Theme aktuell.

Admin-Passwort so lang, dass du es selbst nur noch unter Aufsicht eines Passwortmanagers sehen möchtest.

Zwei-Faktor-Authentifizierung.

Firewall.

Backups.

Alles schön.

Und dann kommt PHP selbst um die Ecke und sagt:

Hallo. Ich hätte da zwei kritische Sicherheitslücken.

CVSS:

9,2 von 10.

Unauthentifizierte Remote Code Execution möglich.

Also vereinfacht:

Jemand muss sich im schlimmsten Fall nicht einmal anmelden, bevor dein Server Dinge tut, die du ganz bestimmt nicht bestellt hast.

Schön.

Willkommen bei PHP2Shell.

Inhaltsverzeichnis

• [Was ist PHP2Shell?](#was-ist-php2shell)
• [Warum ist das so kritisch?](#warum-ist-das-so-kritisch)
• [Die zwei Schwachstellen](#die-zwei-schwachstellen)
• [Bin ich betroffen?](#bin-ich-betroffen)
• [Welche PHP-Versionen sind sicher?](#welche-php-versionen-sind-sicher)
• [Warum WordPress-Updates diesmal nicht reichen](#warum-wordpress-updates-diesmal-nicht-reichen)
• [Was muss ich jetzt tun?](#was-muss-ich-jetzt-tun)
• [Docker? Natürlich auch Docker.](#docker-natuerlich-auch-docker)
• [Was ist mit alten PHP-Versionen?](#was-ist-mit-alten-php-versionen)
• [Kann ich das Problem irgendwie wegkonfigurieren?](#kann-ich-das-problem-irgendwie-wegkonfigurieren)
• [Und meine CODEundKRAM-Engine?](#und-meine-codeundkram-engine)
• [Fazit](#fazit)

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei kritische Sicherheitsprobleme direkt im PHP-Kern:

CVE-2026-109618

und

CVE-2026-109619.

Beide wurden mit CVSS 9,2 bewertet.

PHP selbst warnt davor, dass sie unauthentifizierte Remote Code Execution ermöglichen können. Betroffen sind grundsätzlich PHP-Installationen, die Webanfragen verarbeiten – unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Das wichtige Wort dabei ist:

PHP.

Nicht WordPress.

Nicht Drupal.

Nicht Joomla.

Nicht irgendein dubioses Plugin namens super-mega-slider-final-v2-real.zip.

PHP.

Die Laufzeitumgebung darunter.

Forscher konnten Angriffe unter anderem gegen WordPress, Drupal und Joomla demonstrieren. Das Problem benötigt diese Systeme aber nicht: Die verwundbare Komponente sitzt eine Etage tiefer. Selbst eine sehr einfache PHP-Anwendung kann betroffen sein.

Das ist ungefähr so, als würdest du stolz verkünden:

„Meine Haustür ist absolut sicher.“

Und jemand zeigt auf die fehlende Rückwand des Hauses.

Ach.

Warum ist das so kritisch?

Weil bei PHP2Shell gleich mehrere unangenehme Dinge zusammenkommen.

Der Angreifer braucht unter bestimmten Bedingungen keine Anmeldung.

Er muss also nicht erst dein WordPress-Passwort erraten.

Keine Session klauen.

Keinen Admin überzeugen, auf Rechnung_Oktober_final_final2.pdf.exe zu klicken.

Eine präparierte Webanfrage kann reichen, um verwundbare PHP-Interna zu erreichen.

Beim besonders problematischen mod_php-Szenario beschreibt das PHP-Team sogar einen demonstrierten Angriffspfad, der ausgelöst werden kann, bevor der eigentliche Anwendungscode läuft.

Deine Anwendung kann dann noch so stolz sagen:

„Ich validiere alle Eingaben.“

Schön.

PHP hatte eventuell schon vorher einen schlechten Tag.

Und Remote Code Execution bedeutet nicht automatisch:

Angreifer ist sofort root.

Das wäre zu pauschal.

Der eingeschleuste Code läuft zunächst mit den Rechten des jeweiligen PHP-Webprozesses.

Was daraus wird, hängt davon ab, was dieser Benutzer auf deinem System darf.

Dateien lesen?

Konfigurationen lesen?

Uploads verändern?

Datenbank-Zugangsdaten sehen?

Weitere Dienste erreichen?

Dann wird aus:

„PHP-Prozess kompromittiert“

ziemlich schnell:

„Heute ist Restore-Übung.“

Die Forscher beschreiben neben Codeausführung auch mögliche Speicherlecks, durch die sensible Daten wie Passwörter, Tokens, API-Schlüssel oder Zertifikate aus dem PHP-Prozessspeicher sichtbar werden können.

Sehr praktisch.

Nur leider für die falsche Person.

Die zwei Schwachstellen

PHP2Shell ist nicht einfach ein einzelnes kaputtes if.

Die beiden CVEs betreffen den Umgang von PHP mit internem Speicher und Zuständen während der Verarbeitung von Webanfragen.

Bei CVE-2026-109618 geht es um Fehler beim Umgang mit einer Out-of-Memory-Situation.

Vereinfacht:

PHP verarbeitet eine Anfrage.

Intern sind bestimmte Daten noch nicht vollständig vorbereitet.

Dann läuft der Speicher in eine problematische Situation.

Die normale Verarbeitung wird unterbrochen.

Beim anschließenden Aufräumen behandelt PHP interne Daten so, als wären sie bereits gültig.

Sind sie aber nicht.

Und Speicherverwaltung besitzt bei „wird schon stimmen“ ungefähr denselben Humor wie eine Kreissäge.

PHP beschreibt das als RCE via OOM corruption.

Bei CVE-2026-109619 geht es dagegen um alten internen Zustand, der eine Anfrage überleben kann, obwohl der Speicher dahinter bereits freigegeben wurde.

Ein späterer Request desselben Workers kann dann auf diesen alten Zustand zugreifen, bevor alles sauber neu initialisiert wurde.

Oder auf Deutsch:

Der Speicher ist weg.

Der Zeiger hat die Nachricht noch nicht bekommen.

Fortschritt.

Beide Fehlerklassen können letztlich dazu führen, dass Speicher manipuliert oder ausgelesen wird und daraus unter geeigneten Bedingungen Codeausführung entsteht.

Für den normalen Website-Betreiber ist allerdings weniger wichtig, welche internen PHP-Strukturen genau Kopfstand machen.

Wichtig ist:

Patchen.

Bin ich betroffen?

Wenn dein Server PHP für Webanfragen benutzt und noch nicht gepatcht wurde:

Du solltest davon ausgehen, dass du handeln musst.

PHP nennt ausdrücklich:

• PHP-FPM
• Apache mit mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

als relevante Installationen.

Das bedeutet wiederum:

WordPress?

Prüfen.

Nextcloud?

Prüfen.

Joomla?

Prüfen.

Drupal?

Prüfen.

Shop?

Prüfen.

Eigenes PHP-Projekt?

Auch prüfen.

„Aber meine Website ist nur ganz klein.“

PHP2Shell führt leider keine Alexa-Rangliste, bevor es funktioniert.

Auf einem Server kannst du zunächst schlicht nachsehen:

php -v

Das zeigt dir die PHP-Version der Kommandozeile.

Aber Vorsicht:

Das muss nicht zwingend dieselbe PHP-Version sein, die dein Webserver verwendet.

Weil Serveradministration langweilig wäre, wenn es nur eine PHP-Installation gäbe.

Bei PHP-FPM solltest du deshalb zusätzlich prüfen, welche FPM-Version tatsächlich läuft und welche Runtime deine Website verwendet.

Bei Webhosting:

Kontrollpanel öffnen.

PHP-Version prüfen.

Im Zweifel Hoster fragen.

Nicht:

„Wird der schon gemacht haben.“

Das ist kein Patch-Konzept.

Das ist Religion.

Welche PHP-Versionen sind sicher?

Das PHP-Projekt hat am 21. Oktober 2026 außerplanmäßige Security-Releases veröffentlicht.

Die ersten gefixten Versionen der aktuell unterstützten Zweige sind:

PHP fordert Nutzer ausdrücklich zum sofortigen Update auf. Die Entwickler schreiben außerdem klar, dass es keine vollständige Mitigation gibt und ein Update die einzige sichere Lösung ist.

Also nicht:

„Ich habe mal eine Apache-Regel eingebaut.“

Nicht:

„Cloudflare steht davor.“

Nicht:

„Meine WordPress-Firewall hat ein grünes Häkchen.“

Update.

Der Fachbegriff dafür lautet:

Update.

Warum WordPress-Updates diesmal nicht reichen

Das ist vermutlich der wichtigste Punkt.

Angenommen, du betreibst WordPress.

Dann öffnest du das Dashboard.

WordPress aktuell.

Plugins aktuell.

Theme aktuell.

Perfekt.

Hilft dir bei PHP2Shell nur leider nicht zwingend.

Denn WordPress läuft auf PHP.

Ein WordPress-Update ersetzt deine darunterliegende PHP-Runtime nicht.

Dasselbe gilt für Drupal, Joomla, Laravel, Symfony, Moodle, Nextcloud und eigene PHP-Anwendungen.

Die PHP2Shell-Forscher formulieren es entsprechend klar: Erst eine gepatchte PHP-Runtime installieren und anschließend Apache, PHP-FPM beziehungsweise andere langlebige PHP-Worker neu starten.

Das ist wie:

Auto gewaschen.

Reifen kontrolliert.

Scheibenwasser aufgefüllt.

Motor fehlt.

Aber immerhin glänzt es.

Was muss ich jetzt tun?

Kein Drama.

Keine zwölfteilige Incident-Response-Tanzaufführung.

Aber handeln.

1. PHP-Version feststellen.

Welche Runtime verarbeitet tatsächlich deine Website?

Nicht nur blind php -v tippen und Feierabend.

PHP-FPM, Apache, Container und CLI können unterschiedliche Stände haben.

2. Pakete aktualisieren.

Bei einer normalen Linux-Distribution sollte der Security-Fix über den jeweiligen Paketmanager beziehungsweise Vendor bereitstehen.

Ubuntu hat beispielsweise bereits aktualisierte Pakete für unterstützte Versionen und auch mehrere ältere Releases veröffentlicht. Wichtig ist hier: Distributionen können Sicherheitspatches zurückportieren. Deshalb muss die sichtbare Versionsnummer nicht immer exakt 8.3.36 lauten, damit ein Ubuntu-Paket geschützt ist. Entscheidend ist die Sicherheitsmeldung deines Distributors.

3. PHP-Prozesse neu starten.

Das Paket auf der Platte zu aktualisieren bringt erstaunlich wenig, wenn der alte Worker weiterhin fröhlich im RAM lebt.

Also je nach Setup:

PHP-FPM neu starten.

Apache neu starten.

Container neu starten.

Oder das System sauber rebooten.

Ubuntu weist ausdrücklich darauf hin, dass betroffene Anwendungen nach dem Paketupdate neu gestartet werden müssen beziehungsweise ein Reboot sicherstellt, dass die neuen Komponenten verwendet werden.

4. Kontrollieren.

Nicht:

Update lief durch.

Fenster schließen.

Kaffee.

Sondern anschließend verifizieren:

Welche Version läuft jetzt tatsächlich?

Sind die FPM-Worker neu gestartet?

Läuft die Website?

Sind Logs auffällig?

Sind alle Container aktuell?

Die einfachste Sicherheitskontrolle ist erstaunlich oft:

Nachsehen.

Revolutionär.

Docker? Natürlich auch Docker.

„Meine Website läuft in Docker.“

Schön.

Docker ist keine magische Glaskuppel, unter der Sicherheitslücken aus Respekt stehen bleiben.

Wenn dein Image eine verwundbare PHP-Version enthält, enthält dein Container eine verwundbare PHP-Version.

Das bedeutet:

Neues Base-Image beziehungsweise aktualisierte Pakete holen.

Image neu bauen.

Container ersetzen.

Danach prüfen, welche PHP-Version im laufenden Container tatsächlich vorhanden ist.

Nicht nur Dockerfile ansehen.

Nicht nur Registry-Tag anschauen.

Nicht denken:

php:8.3

wird schon irgendwie aktuell sein.

Ein Image, das vor drei Wochen gebaut wurde, reist nicht nachts selbständig durchs Internet und sammelt Security-Patches ein.

Wäre praktisch.

Macht es aber nicht.

Was ist mit alten PHP-Versionen?

Jetzt wird es lustig.

Also „lustig“ im Sinne von:

Serveradministratoren fangen leise an zu weinen.

PHP 8.1 und älter bekommen vom normalen PHP-Projekt keine regulären Sicherheitsupdates mehr.

Das PHP-Team hat wegen der Schwere dieser Lücken zwar minimale Source-Backports für PHP 7.4, 8.0 und 8.1 bereitgestellt. Außerdem können Linux-Distributionen und kommerzielle LTS-Anbieter eigene gepatchte Pakete liefern.

Das bedeutet aber nicht:

„PHP 7.4 ist jetzt wieder eine super Idee.“

Nein.

Wenn du auf einer uralten PHP-Version festhängst, weil irgendeine Website aus dem Jahr 2014 nur unter Vollmond und PHP 7.4 funktioniert, hast du zusätzlich zu PHP2Shell noch ein Architekturproblem.

„Aber das läuft seit Jahren.“

Schön.

Mein alter Rauchmelder hängt auch seit Jahren an der Decke.

Das bedeutet nicht, dass die Batterie voll ist.

Wer alte Distributionen mit Vendor-Backports nutzt, sollte die Paket-Sicherheitsmeldung seines Distributors prüfen und nicht stumpf Versionsnummern mit php.net vergleichen.

Ubuntu 24.04 kann beispielsweise ein gepatchtes PHP-8.3-Paket liefern, dessen Versionsschema anders aussieht als die Upstream-Version 8.3.36.

Versionen sind schon kompliziert genug.

Natürlich brauchten wir auch noch Backports.

Kann ich das Problem irgendwie wegkonfigurieren?

Teilweise lassen sich einzelne Angriffspfade erschweren.

PHP nennt beispielsweise Änderungen an Speicher- und Request-Limits als Maßnahmen, die bestimmte Wege reduzieren können.

Und sagt direkt danach sinngemäß:

Das macht die Installation nicht sicher.

Für CVE-2026-109618 kann etwa ein unbegrenztes PHP-memory_limit einen kontrollierbaren PHP-Speicherfehler als Angriffspfad entfernen. Trotzdem kann ein anderer Speicherfehler weiterhin denselben verwundbaren Bereich erreichen. Auch kleinere Request-Grenzen können das Risiko bestimmter Pfade reduzieren.

Das sind Notmaßnahmen.

Keine Lösung.

Wenn PHP selbst schreibt:

Update.

dann lautet die kreative Alternative nicht:

„Ich habe da eine nginx-Regel aus Stack Overflow von 2019 gefunden.“

Update.

Und meine CODEundKRAM-Engine?

An dieser Stelle darf ich ausnahmsweise entspannt zuschauen.

CODEundKRAM OS läuft nicht auf PHP.

Die eigene BlogEngine basiert auf Node.js, SQLite, serverseitig erzeugtem HTML und Vanilla JavaScript.

PHP steckt dort nicht darunter.

Damit betrifft diese konkrete PHP2Shell-Lücke meine BlogEngine nicht.

Das bedeutet selbstverständlich nicht:

Node.js ist unverwundbar.

Oder:

Eigene Software braucht keine Updates.

Das wäre ungefähr dieselbe Logik wie:

„Mein Haus kann keinen Motorschaden bekommen.“

Korrekt.

Dafür kann es abbrennen.

Jeder Stack bringt seine eigene Sammlung wunderschöner Möglichkeiten mit, den Feierabend zu ruinieren.

Diesmal darf ich nur aus der Zuschauerreihe winken.

Auch mal schön.

Fazit

PHP2Shell ist kein lustiger Plugin-Bug.

Keine kleine XSS-Lücke in einem WordPress-Kalender, den zwölf Leute installiert haben.

Die Schwachstellen sitzen im PHP-Kern.

Zwei CVEs.

Beide kritisch.

CVSS 9,2.

Codeausführung ohne vorherige Anmeldung ist möglich.

Und die PHP-Entwickler sagen ausdrücklich:

Es gibt keine vollständige Umgehung. Aktualisieren ist die sichere Lösung.

Deshalb:

PHP-Version prüfen.

Vendor-Update installieren.

PHP-FPM, Apache oder Container neu starten.

Danach überprüfen, dass tatsächlich die gepatchte Runtime läuft.

Nicht morgen.

Nicht beim nächsten Wartungsfenster im Dezember.

Nicht:

„Der Hoster wird schon.“

Jetzt.

Denn dein WordPress kann aktuell sein.

Dein Theme kann aktuell sein.

Deine Plugins können aktuell sein.

Dein Passwort kann 64 Zeichen haben.

Dein Administrator kann Zwei-Faktor-Authentifizierung nutzen.

Und PHP2Shell sagt trotzdem:

Schöne Website.

Ich komme eine Etage tiefer rein.