Beitragsbild: KI-generierte Karikatur.
Moin zusammen,
seit dem 21. Oktober 2026 geht ein Name durch alle Admin-Foren: php2shell. Dahinter stecken zwei Sicherheitslücken im PHP-Kern (CVE-2026-109618 und CVE-2026-109619), die zusammen einem Angreifer erlauben, ohne Anmeldung eigenen Code auf dem Webserver auszuführen. Das BSI bewertet beide mit 9,2 von 10 Punkten, also „kritisch“. Und weil PHP unter WordPress, Nextcloud, Plesk, Joomla und gefühlt der halben Welt läuft, betrifft das vermutlich auch den einen oder anderen von euch – inklusive mir mit dem vServer. 😊
Ich versuche mal zu erklären, was da eigentlich passiert, ohne dass man Kernel-Entwickler sein muss.
Kurz gesagt: Was ist php2shell?
Zwei Fehler in der Art, wie PHP mit Abbrüchen mitten in einer Anfrage umgeht. Jeder für sich ist schon unschön. Zusammen ergeben sie eine Kette, mit der ein Angreifer die Kontrolle über den PHP-Prozess übernehmen kann – und damit über alles, was der Webserver-Benutzer darf. Daher der Name: aus PHP wird eine Shell.
Betroffen sind laut PHP-Projekt alle Betriebsarten: PHP-FPM, Apache mit mod_php, php-cgi, LiteSpeed, FrankenPHP. Am gefährlichsten ist mod_php, weil der Fehler dort schon ausgelöst werden kann, bevor überhaupt eine Zeile eurer Anwendung läuft. Ein Login, ein Plugin oder eine bestimmte Seite ist nicht nötig; eine einzige passend gebaute HTTP-Anfrage reicht.
Wie die PHP-Sicherheitslücke funktioniert
Um das zu verstehen, muss man wissen, wie PHP einen Abbruch behandelt.
Der Notausgang: longjmp()
Wenn ein PHP-Skript sein Speicherlimit (memory_limit) überschreitet oder ein fataler Fehler auftritt, räumt PHP nicht ordentlich Funktion für Funktion auf, sondern nimmt eine Abkürzung: Mit dem C-Befehl longjmp() springt es direkt zurück an den Anfang der Anfrage, ähnlich wie ein Notausgang, der alle Zwischentüren überspringt. Das ist schnell, hat aber einen Haken: Alles, was in dem Moment „halb fertig“ war, bleibt halb fertig liegen.
Bug 1 (CVE-2026-109618): Halb angelegte POST-Daten
Wenn PHP ein Formular mit POST-Daten einliest, trägt es jeden Wert in eine interne Liste ein, bevor er vollständig initialisiert ist. Schafft es ein Angreifer, genau in diesem Moment den Speicherfehler auszulösen – zum Beispiel durch eine Anfrage, die absichtlich viel Speicher braucht –, dann springt longjmp() raus und in der Liste liegt ein Eintrag, der nur zur Hälfte gültig ist. Beim späteren Aufräumen hält PHP diesen Eintrag für vollständig und folgt einem darin enthaltenen Zeiger, dessen Inhalt der Angreifer beeinflussen kann.
Bug 2 (CVE-2026-109619): Speicher, der nach dem Abbruch noch benutzt wird
Beim gleichen Notausgang (zend_bailout(), ebenfalls über longjmp()) bleiben manche Zeiger in globalen Variablen stehen, obwohl der Speicher dahinter schon freigegeben wurde. PHP-Worker bearbeiten Anfragen nacheinander, und diese Zeiger überleben bis zur nächsten Anfrage. Die kann dann auf Speicher zugreifen, der nicht mehr ihr gehört – ein klassischer „Use after free“. Das kann Speicherinhalte verraten (Passwörter, Session-Daten) oder, kombiniert mit Bug 1, den Programmfluss umbiegen.
Die Kette
Mit Bug 1 kann der Angreifer bestimmen, was in dem freigegebenen Speicher aus Bug 2 steht. Mit Bug 2 bringt er PHP dazu, genau diesen Speicher zu benutzen. Ergebnis: PHP springt an eine Adresse, die der Angreifer vorgibt, und führt seinen Code aus. Die Entdecker beschreiben das als „hochgradig zuverlässig“, also kein Glücksspiel wie bei vielen Speicherfehlern.
Das Erschreckende: Der betroffene Code ist laut Calif.io seit PHP 5.4.0 drin, also seit 2012. Vierzehn Jahre hat niemand hingeschaut, bis Forscher von Calif, Wiz und OpenAI – nach eigenen Angaben mit Hilfe von KI-Modellen – die Lücke fanden. Da schließt sich der Kreis zu meinem letzten Beitrag: KI kann eben nicht nur falschen Code vorschlagen, sondern auch 14 Jahre alten Code lesen.
Was bisher passiert ist
- 17. Oktober: Amazon sieht erste Exploit-Versuche in seinem Honeypot-Netz – vier Tage vor der Veröffentlichung.
- 20. Oktober: Die CVE-Nummern tauchen auf Hacker News und in sozialen Medien auf. PHP kündigt ein Notfall-Update an.
- 21. Oktober: PHP zieht die Veröffentlichung um einen Tag vor und liefert die Patches. Cloudflare meldet erste Angriffe und schaltet WAF-Regeln.
- 22. Oktober: Amazon spricht von breiter Ausnutzung durch mehrere Gruppen. Exploit-Code kursiert; eine Demo gegen WordPress, Drupal, Joomla und Magento ist öffentlich.
Bin ich betroffen?
Kurz: Ja, wenn auf eurem Server PHP vor diesen Versionen läuft:
| Zweig | Sicher ab |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 7.4 – 8.1 | kein offizielles Release; nur Quelltext-Backports des PHP-Teams – Distributionen und z. B. packages.sury.org liefern Pakete |
| PHP 5.4 – 7.3 | kein Fix – End of Life |
So findet ihr eure Version:
- SSH:
php -v– bei mehreren Versionen (Plesk!) für jede einzeln, z. B./opt/plesk/php/8.3/bin/php -v - Plesk: Tools & Einstellungen → Updates → PHP-Versionen zeigt alle installierten Versionen
- WordPress: Werkzeuge → Website-Zustand → Bericht → Server
- Debian/Ubuntu:
apt list --upgradable | grep php– die Distributionen haben die Patches vorab bekommen, die Versionsnummer sieht dann anders aus (z. B. 8.2.29-1~deb12u3); entscheidend ist das Changelog des Pakets
Vorsicht bei Geräten, an die man nicht denkt: NAS-Systeme (Synology DSM liefert PHP 8.1), Router-Oberflächen, Docker-Images (Nextcloud hatte am 21.10. noch keinen Fix im Image), alte Entwicklungs-VMs.
Was ihr jetzt tun solltet
- Updaten. Sofort, auf allen Servern, für alle installierten PHP-Versionen. Danach PHP-FPM bzw. Apache neu starten, sonst läuft der alte Code weiter.
- Wenn ihr nicht sofort updaten könnt: Die Seite offline nehmen oder per Passwortschutz/IP-Beschränkung abschirmen. Das PHP-Team nennt das die einzige wirklich verlässliche Alternative.
- Keine falsche Sicherheit durch Workarounds. PHP nennt als Notbehelf,
memory_limit = -1fest zu setzen (so, dass Anwendungen es nicht überschreiben können), sagt aber ausdrücklich: Das macht die Installation nicht sicher, es erschwert nur einen der beiden Auslöser. Gleiches gilt für Cloudflare-WAF-Regeln. - Alte Zweige loswerden. Wer noch auf PHP 7.x oder 8.0/8.1 hängt, hat jetzt den Grund, den er schon lange brauchte.
- Nach dem Update nach Spuren suchen. Angriffe laufen seit dem 17. Oktober. Schaut in die Webserver-Logs nach ungewöhnlichen POST-Anfragen, nach Segfaults im PHP-FPM-Log, nach neu angelegten
.php-Dateien in Upload-Ordnern und nach Prozessen, die der Webserver-User gestartet hat. Wer nach dem 17.10. ungepatcht erreichbar war, sollte im Zweifel von einem Einbruch ausgehen.
Ich habe meinen vServer durchgesehen – [hier dein Ergebnis: welche Versionen liefen, Plesk-Update eingespielt, Logs sauber?]. Und ja, auch dieser Blog läuft auf PHP. 😊
Bleibt wachsam, und schreibt gern in die Kommentare, wie es bei euch lief – besonders, wenn ihr NAS oder Docker-Container im Einsatz habt.
Viele Grüße
SiSoSnooP
Quellen
- BSI-Cybersicherheitswarnung: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit
- Zscaler ThreatLabz: CVE-2026-109618 and CVE-2026-109619 – PHP2Shell
- Tenable: php2shell FAQ
- Borncity: php2shell – PHP-Updates und Nachlese
- Huntress: Rapid Response php2shell