PHP2Shell: Kritische Sicherheitslücken in PHP – jetzt handeln

Zwei kritische Sicherheitslücken in PHP selbst halten derzeit IT-Administratoren weltweit in Atem: Unter dem Namen „PHP2Shell“ wurden Schwachstellen bekannt, über die Angreifer ohne Anmeldung eigenen Code auf Webservern ausführen können. Betroffen ist nicht eine einzelne Anwendung, sondern die PHP-Laufzeitumgebung und damit potenziell jede Website, jeder Shop und jede Webanwendung auf PHP-Basis. Das PHP-Projekt hat am 21. Oktober 2026 Notfall-Updates veröffentlicht.

Für unsere Kunden vorab die wichtigste Nachricht: Wir haben unsere eigenen Systeme unmittelbar nach Veröffentlichung der Updates gepatcht. Die Systeme unserer Wartungsvertragskunden wurden priorisiert bearbeitet, und die betroffenen Kunden wurden bereits von uns informiert.

In diesem Beitrag fassen wir zusammen, was hinter PHP2Shell steckt, wer betroffen ist und was Sie jetzt tun sollten.

Was ist PHP2Shell?

PHP2Shell bezeichnet zwei Schwachstellen in der PHP-Laufzeitumgebung, die unter den Kennungen CVE-2026-109618 und CVE-2026-109619 geführt werden. Das PHP-Sicherheitsteam bewertet beide mit 9,2 auf der CVSS-4.0-Skala – also als kritisch. Entdeckt wurden die Lücken von Sicherheitsforschern von Calif, Wiz und OpenAI. Beide Schwachstellen haben dieselbe Ursache: Wenn eine Anfrage abnormal endet – etwa weil das konfigurierte Speicherlimit überschritten wird –, kann PHP seinen Arbeitsspeicher in einem inkonsistenten Zustand hinterlassen. Genau diesen Moment können Angreifer ausnutzen.

• CVE-2026-109618 – Codeausführung durch Speicherkorruption bei Speichermangel: Läuft PHP während einer Anfrage in das Speicherlimit, kann die Verarbeitung abbrechen, bevor interne Daten vollständig initialisiert sind. Beim anschließenden Aufräumen verwendet PHP diese unfertigen Daten möglicherweise weiter – mit der Folge, dass Code mit den Rechten des Webserver-Benutzers ausgeführt werden kann.
• CVE-2026-109619 – Codeausführung durch veralteten globalen Zustand: Hier bleibt nach einem Abbruch veralteter Zustand im Speicher zurück. Das ermöglicht ohne Authentifizierung einen sogenannten Use-after-free auf dem Heap, das Auslesen von Speicherinhalten und ebenfalls die Ausführung von Code.

Die Lücken stecken in PHP selbst. Eine Anwendung muss also keinen Programmierfehler enthalten, um angreifbar zu sein.

Welche Systeme und PHP-Versionen sind betroffen?

Nach Angaben des PHP-Projekts ist jede PHP-Installation betroffen, die Web-Anfragen verarbeitet – unabhängig von der Betriebsart:

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

Das höchste Risiko sieht das PHP-Team bei mod_php: Hier wurde ein Angriff demonstriert, bei dem eine nicht authentifizierte Anfrage den Exploit auslöst, noch bevor überhaupt Anwendungscode ausgeführt wird.

Auch PHP-Webserver unter Windows sind angreifbar. Ob FrankenPHP tatsächlich betroffen ist, wird derzeit unterschiedlich bewertet.Wir empfehlen, vorsorglich auch hier zu aktualisieren. Damit sind auch alle gängigen PHP-basierten Systeme betroffen, von Content-Management-Systemen wie Contao, WordPress, Joomla oder Drupal über Online-Shops bis hin zu individuellen Laravel-Anwendungen.

Ebenso betroffen sind Docker-Container, die eine verwundbare PHP-Version mitbringen. Sie müssen mit aktualisierten Images neu gebaut bzw. neu gestartet werden.

Firewalls, NAS und Appliances nicht vergessen

PHP steckt nicht nur in Webservern, sondern auch in den Weboberflächen zahlreicher Netzwerkgeräte. Dazu gehören unter anderem Geräte bzw. Systeme von pfSense, OPNsense, QNAP, Synology, DrayTek, ZyXEL, D-Link, TP-Link, Netgear und Tenda sowie Security-Appliances von Citrix, Palo Alto, Ivanti und F5 (BIG-IP).

Sind deren Management-Oberflächen aus dem Internet erreichbar, sind sie angeifbar. Prüfen Sie daher, ob die Hersteller Updates bereitstellen und schränken Sie den Zugriff auf Verwaltungsoberflächen bis dahin konsequent ein. Auch rein intern genutzte PHP-Anwendungen sind kein Grund zur Entwarnung: Ist ein Angreifer etwa über Malware bereits im Netzwerk, kann er verwundbare PHP-Systeme nutzen, um sich dauerhaft festzusetzen.

Korrigierte Versionen:

Forscher gehen davon aus, dass die Schwachstellen bis in sehr alte PHP-Versionen zurückreichen. Wer noch PHP 7 oder älter einsetzt, hat damit ein doppeltes Problem: eine kritische Lücke und keine regulären Updates mehr.

Warum die Lage besonders ernst ist

Üblicherweise werden Schwachstellen koordiniert offengelegt: Erst steht das Update bereit, dann werden die Details veröffentlicht. Bei PHP2Shell ist das schiefgegangen. Informationen zu den Lücken sind vor dem geplanten Veröffentlichungstermin geleakt, weshalb das PHP-Projekt die ursprünglich für den 22. Oktober geplanten Updates um einen Tag vorgezogen hat. Hinzu kommt: Die Angriffe funktionieren zwar nicht beim ersten Versuch und benötigen mitunter einige Tausend bis Zehntausend HTTP-Anfragen, sind dann aber zuverlässig. Damit eignen sie sich ideal für automatisierte Massenangriffe. Die Entdecker von Calif zeigen in einem Video, wie sie auf einem Webserver mit dem PHP-Framework Laravel nach rund 38 Sekunden Systembefehle ausführen.

Cloudflare meldete bereits Angriffsverkehr gegen die Schwachstellen und hat Schutzregeln in seiner Web Application Firewall ausgerollt. Das britische National Cyber Security Centre (NCSC) rät Organisationen, betroffene Systeme umgehend zu aktualisieren oder sie bis zum Patch vom Netz zu nehmen.

Angesichts der enormen Verbreitung von PHP –rechnen Sicherheitsexperten mit Massenscans und zahlreichen Angriffen in den kommenden Tagen.

Was Sie jetzt tun sollten

1. PHP-Version prüfen: Ermitteln Sie auf allen Servern die eingesetzte PHP-Version (z. B. php -v bzw. php-fpm -v). Denken Sie auch an Testsysteme und „vergessene“ Altsysteme.
2. Updates einspielen: Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. auf das entsprechende Sicherheitsupdate Ihrer Linux-Distribution.
3. Dienste neu starten: Ein Update wirkt erst, wenn alle PHP-Prozesse neu gestartet wurden – also PHP-FPM-Pools, Apache oder die jeweiligen Worker.
4. Container aktualisieren: Ziehen Sie aktualisierte Images, sobald diese verfügbar sind, und starten Sie die Container neu (z. B. docker compose pull && docker compose up -d).
5. Internetexponierte Systeme zuerst: Priorisieren Sie öffentlich erreichbare Webserver, Shops, Portale und Management-Oberflächen von Appliances.
6. Altversionen ablösen: Wer noch PHP 8.2 oder älter einsetzt, sollte mindestens auf PHP 8.3 wechseln (Support bis Ende 2027). Den größten zeitlichen Puffer bietet PHP 8.5. PHP 8.2 erreicht bereits Ende 2026 sein Support-Ende.
7. Logs im Blick behalten: Auffällige Abstürze von PHP-Prozessen, gehäufte Speicherfehler oder unbekannte Prozesse unter dem Webserver-Benutzer können auf Angriffsversuche hindeuten.

Übergangsmaßnahmen, falls ein Update nicht sofort möglich ist

Das PHP-Sicherheitsteam hat einige Maßnahmen veröffentlicht, die bestimmte Angriffswege erschweren. Wichtig: Diese Maßnahmen schützen nicht vollständig. Das Einspielen der Updates bleibt die einzige dauerhafte Lösung.

Gegen CVE-2026-109618:

• memory_limit=-1 setzen – möglichst so, dass Anwendungen den Wert nicht überschreiben können, etwa per php_admin_value im FPM-Pool oder in der Apache-Konfiguration.
• post_max_size niedrig halten: 8M für Anwendungen ohne Datei-Uploads, 32M, falls Uploads benötigt werden.
• Speicherbegrenzung stattdessen über Container- oder cgroup-Limits absichern, idealerweise so, dass nur der betroffene Worker beendet wird.

Gegen CVE-2026-109619:

• session.upload_progress.enabled=0 setzen und alle Worker neu starten.
• Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und alle Worker neu starten.
• Ungültige oder veraltete Einstellungen entfernen, die pro Anfrage gesetzt werden und dabei Warnungen erzeugen. Das bloße Unterdrücken von Fehlermeldungen hilft hier nicht.

Weitere Härtungsmaßnahmen:

• post_max_size kleiner als ein Viertel des Speicherlimits wählen.
• max_input_nesting_level auf einen niedrigen Wert wie 8 beschränken.
• Bei PHP-FPM pm.max_requests niedrig ansetzen, damit Worker regelmäßig neu gestartet werden.
• SELinux bzw. AppArmor nutzen, um die Rechte des Webserver-Prozesses zu begrenzen.
• Mit expose_php=0 das Vorhandensein von PHP nach außen verschleiern.

Alle diese Einstellungen können Leistung oder Funktionalität Ihrer Anwendungen beeinträchtigen. Das PHP-Team selbst bezeichnet sie als temporäre Krücke, denn sie ersetzen kein zügiges Update. Ergänzend kann eine Web Application Firewall bekannte Angriffsmuster abfangen – als zusätzliche Schutzschicht, nicht als Ersatz für das Update.

So sind wir bei ETES vorgegangen

Sicherheitsupdates dieser Kategorie behandeln wir nicht als Routine, sondern als Notfall. Unmittelbar nach Veröffentlichung der korrigierten Versionen haben wir:

• unsere eigenen Systeme gepatcht – darunter unsere Webhosting-Plattform sowie die Infrastruktur in unserem ISO 27001-zertifizierten Rechenzentrum in Stuttgart,
• die Systeme unserer Wartungsvertragskunden priorisiert bearbeitet und die Updates dort eingespielt,
• unsere Wartungsvertragskunden aktiv informiert über den Stand der Maßnahmen und eventuell notwendige Folgeschritte,
• OPNsense-Firewalls und weitere Appliances mit Weboberfläche im Blick – denn auch dort ist häufig PHP im Einsatz. Wir verfolgen die Hersteller-Updates und spielen sie bei betreuten Systemen ein, sobald sie verfügbar sind.

Genau hier zeigt sich der Wert eines Wartungsvertrags: Wenn eine kritische Lücke bekannt wird, müssen Sie nicht selbst Nachrichten verfolgen, Versionen recherchieren und nachts Server aktualisieren – wir kümmern uns darum, nach festen Prozessen und dokumentiert.

Sie betreiben eigene PHP-Server oder Webanwendungen ohne Wartungsvertrag und sind unsicher, ob Ihre Systeme betroffen sind? Sprechen Sie uns an. Wir prüfen Ihre Umgebung, spielen die Updates ein und unterstützen Sie bei der Migration von veralteten PHP-Versionen.

Fazit

PHP2Shell gehört zu den schwerwiegendsten Sicherheitslücken der vergangenen Jahre: Sie steckt in der Laufzeitumgebung selbst, ist ohne Anmeldung ausnutzbar und betrifft einen großen Teil des Webs. Durch den vorzeitigen Leak bleibt Betreibern kaum Zeit. Wer PHP einsetzt, sollte die Updates jetzt einspielen, die PHP-Dienste neu starten und Altsysteme zeitnah ablösen.
Für unsere Wartungsvertragskunden ist dieser Schritt bereits erledigt. Allen anderen helfen wir gern – schnell und unkompliziert.