php2shell: Die PHP-Lücke, gegen die ein Update Ihrer Website nicht hilft
Seit dem 21. Oktober gibt es Sicherheitsupdates, und seit demselben Tag kursiert öffentlich Angriffscode. Betroffen ist nicht nur Ihr Onlineshop, sondern jedes System, das PHP ausliefert: Website, Kundenportal, Intranet, Dateiablage, Ticketsystem.
php2shell ist der Name für zwei kritische Schwachstellen im PHP-Interpreter, über die Angreifer ohne Anmeldung eigenen Programmcode auf einem Server ausführen können. PHP ist die Programmiersprache, auf der ein Großteil aller Websites, Onlineshops und Kundenportale läuft. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619.
Das Bundesamt für Sicherheit in der Informationstechnik hat am 21. Oktober gewarnt und ein Update noch am selben Tag empfohlen. Der Name kommt daher, dass sich über PHP eine Kommandozeile auf dem Server öffnen lässt: „PHP to shell“.
Was genau passiert ist
Am 20. Oktober gelangten Details zu beiden Schwachstellen vorzeitig an die Öffentlichkeit, bevor die Updates fertig waren. Das PHP-Projekt zog die Veröffentlichung daraufhin vor und stellte am 21. Oktober um 15:45 Uhr außerplanmäßig neue Versionen bereit.
Beide Lücken sind mit 9,2 von 10 Punkten nach CVSS v4.0 bewertet. Sie erlauben das Ausführen von Code aus der Ferne, ohne Anmeldung und ohne Zutun eines Nutzers. Inzwischen kursiert öffentlich Angriffscode, das RUS-CERT der Universität Stuttgart hat ihn auf einem Testsystem nachvollzogen, und erste Angriffsversuche werden gemeldet. Bestätigte erfolgreiche Angriffe waren zum Stand dieses Beitrags nicht belegt — bei einer Lücke dieser Art ist das allerdings eher eine Frage von Tagen als von Wochen.
BSI-Vizepräsident Thomas Caspers in der Pressemitteilung vom 21. Oktober: „Wir halten eine kurzfristige, großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Sicherheitsupdates für wahrscheinlich.“ Als Begründung nennt das BSI, dass Angreifer die Updates mit KI-gestützten Werkzeugen in kurzer Zeit auswerten und daraus Angriffscode erzeugen können.
Das BSI schreibt weiter, dass alle bekannten PHP-Versionen zurückgehend bis mindestens PHP 5 verwundbar sind. Behörden in Mainz und Saarbrücken haben am selben Tag reagiert und Dienste vorübergehend abgeschaltet. Das ist ein brauchbarer Maßstab dafür, wie die Lage eingeschätzt wird.
Welche PHP-Version die Lücke schließt
Das ist die einzige Zahl, auf die es ankommt. Sicher sind ausschließlich diese Stände oder neuer:
| PHP-Zweig | Sicher ab | Was gilt |
|---|---|---|
| PHP 8.5 | 8.5.12 | Update verfügbar |
| PHP 8.4 | 8.4.27 | Update verfügbar |
| PHP 8.3 | 8.3.36 | Update verfügbar |
| PHP 8.2 | 8.2.35 | Update verfügbar |
| PHP 8.1, 8.0, 7.4 | — | Kein Update vom PHP-Projekt. Es gibt nur minimale Rückportierungen im Quellcode. Fragen Sie Ihren Hoster oder wechseln Sie den Zweig. |
| älter als 7.4 | — | Seit Jahren ohne Unterstützung. Hier ist php2shell das kleinere Ihrer Probleme. |
Betroffen ist nach Angaben des CERT praktisch jede PHP-Version ab PHP 5, also nahezu alles aus den letzten zwanzig Jahren.
Warum ein Update Ihrer Website nicht reicht
Das ist der Punkt, der in den meisten Meldungen untergeht und der die größten Missverständnisse erzeugt.
Die Lücke steckt nicht in WordPress, Shopware, TYPO3, Joomla, Magento oder einem Plugin. Sie steckt eine Ebene tiefer, im PHP-Interpreter selbst. Das PHP-Projekt stuft den Betrieb über mod_php als besonders gefährdet ein: Dort wurde technisch demonstriert, dass eine einzelne Anfrage ohne Anmeldung greift, bevor überhaupt Programmcode Ihrer Anwendung ausgeführt wird. Das ist ein Machbarkeitsnachweis, kein berichteter Angriff — für die Einschätzung des Risikos macht das allerdings kaum einen Unterschied.
Praktisch heißt das: Ein aktuelles WordPress hilft nicht. Ein Sicherheits-Plugin hilft nicht. Und der Login Ihrer Anwendung hilft ebenfalls nicht — er läuft erst, wenn PHP die Anfrage längst verarbeitet hat.
Ein Unterschied ist hier wichtig, weil er über eine brauchbare Notlösung entscheidet. Ein Zugriffsschutz, der vor PHP sitzt, wirkt sehr wohl: ein Verzeichnisschutz auf Webserver-Ebene (Basic Auth, in Plesk mit wenigen Klicks eingerichtet) oder eine vorgeschaltete Web Application Firewall. Damit lässt sich eine Seite bis zum Update abschirmen. Entscheidend ist nicht, ob ein Passwort abgefragt wird, sondern wo im Ablauf es greift.
Was das für den Betrieb heißt: Wenn Sie in den letzten Tagen eine Mail bekommen haben, die zum „Update Ihres Shops“ auffordert, war das gut gemeint, aber am Thema vorbei. Entscheidend ist allein, welche PHP-Version auf dem Server läuft.
Wer das Update einspielt — und wie Sie es herausfinden
Die Zuständigkeit hängt davon ab, wo Ihre Anwendung läuft. Drei Fälle decken fast alles ab:
- Webhosting beim Anbieter (IONOS, Strato, netcup, Hetzner und andere). Dort aktualisiert der Anbieter die PHP-Versionen. Ihre Aufgabe: im Kundenbereich nachsehen, welcher PHP-Zweig für Ihre Domain eingestellt ist, und auf den aktuellen Stand wechseln. Steht dort noch 7.4 oder 8.0, ist Handeln nötig.
- Eigener Server oder Root-Server. Hier sind Sie oder Ihr Dienstleister zuständig. Nach dem Paketupdate müssen alle PHP-Prozesse neu gestartet werden, sonst läuft der alte Code weiter. Container-Abbilder hinken oft nach und brauchen eine eigene Prüfung.
- Anwendung beim Softwarehersteller. Bei gehosteten Lösungen liegt es beim Anbieter. Eine kurze schriftliche Nachfrage ist trotzdem sinnvoll — und sie ist später Ihr Nachweis.
Die eigene Version finden Sie im Kundenbereich des Hosters, in der Verwaltungsoberfläche Ihrer Anwendung oder, auf einem eigenen Server, über php -v.
Oft vergessen: die Verwaltungsoberflächen selbst. Plesk, cPanel, phpMyAdmin und Webmail-Oberflächen wie Roundcube sind selbst in PHP geschrieben und damit genauso betroffen wie die Anwendungen, die sie verwalten. Für sie liefern die jeweiligen Hersteller eigene Aktualisierungen, unabhängig vom PHP-Update des Servers.
Betrifft es Ihren Shop — und was ist mit Shopify?
Die häufigste Frage dieser Tage, und die Antwort hängt davon ab, worauf Ihr Shop läuft.
Shopware, WooCommerce und Magento sind PHP-Anwendungen. Hier gilt die Lücke in vollem Umfang: Es zählt die PHP-Version auf dem Server, auf dem der Shop läuft, nicht die Version des Shopsystems.
Ein gehosteter Shopify-Shop ist anders. Shopify betreibt die Plattform selbst, und zwar nicht auf PHP-Basis, sondern auf Ruby on Rails. Der Shop-Kern ist von php2shell deshalb nicht betroffen — darum müssen Sie sich bei einem reinen Shopify-Shop nicht kümmern. Aufpassen müssen Sie erst, wenn Sie daneben etwas Eigenes in PHP betreiben: eine zusätzliche Firmenwebsite, oft WordPress, einen Headless-Storefront mit eigenem Backend, eine selbst gehostete App oder eine Schnittstelle zwischen Shop und Warenwirtschaft. Das läuft auf Ihrem Server und braucht das Update.
Hat mein Hoster die Lücke geschlossen?
Bei Webhosting bei IONOS, Strato, Hetzner und anderen gilt eine einfache Faustregel: Der Hoster stellt die reparierten PHP-Versionen bereit, aber er schaltet Ihre Domain nicht von selbst darauf um. Das würde ältere Anwendungen lahmlegen, deshalb bleibt die Entscheidung bei Ihnen.
Praktisch heißt das: Sehen Sie im Kundenbereich nach, welcher PHP-Zweig für Ihre Domain eingestellt ist. Steht dort 8.2, 8.3, 8.4 oder 8.5, bekommen Sie das reparierte PHP mit dem nächsten Update des Hosters automatisch. Steht dort noch 8.1 oder älter, hat das Update Sie nicht erreicht — dann stellen Sie den Zweig um, in der Regel mit zwei, drei Klicks, und prüfen danach, ob Ihre Seite noch läuft.
Wenn Sie nicht sofort aktualisieren können
Das PHP-Projekt nennt Übergangsmaßnahmen und sagt dazu ausdrücklich, dass sie einzelne Angriffswege verengen, die Installation aber nicht sicher machen. Sie sind eine Brücke über Stunden, kein Ersatz.
memory_limit=-1so setzen, dass Anwendungen es nicht überschreiben können, etwa perphp_admin_valueim FPM-Pool.post_max_sizeklein halten: 8M ohne Datei-Uploads, 32M mit.upload_max_filesizedarunter.session.upload_progress.enabled=0setzen und alle Arbeitsprozesse neu starten. Nicht überini_set(), das greift zu spät.- Unter PHP 8.5 zusätzlich
fatal_error_backtraces=0, ebenfalls mit Neustart. - Grenzen über Container oder cgroup setzen, aber nicht über
RLIMIT_ASoderRLIMIT_DATA— die lösen genau den Fehlerfall aus, um den es geht.
Wer Cloudflare einsetzt: Dort sind Regeln aktiv, die bekannte Ausnutzungsversuche blockieren. Auch das ist eine Schicht, kein Ersatz.
Woran Sie erkennen, ob es Sie schon erwischt hat
Ein Update schließt die Tür. Es sagt nichts darüber, ob vorher jemand durchgegangen ist. Wenn Ihr System länger als ein paar Stunden ungepatcht am Netz war, gehört eine Prüfung dazu:
- Neue oder veränderte PHP-Dateien im Web-Verzeichnis, besonders mit unauffälligen Namen in Upload- oder Cache-Ordnern.
- Auffällige Einträge im Zugriffsprotokoll ab dem 20. Oktober bis zum Zeitpunkt Ihres Updates, vor allem ungewöhnlich große oder stark verschachtelte Anfragen.
- Neue administrative Benutzer oder geänderte Zugangsdaten in der Anwendung.
- Ausgehende Verbindungen des Webservers zu unbekannten Zielen.
- Geplante Aufgaben (Cronjobs), die niemand angelegt hat.
Findet sich etwas davon, ist das kein Fall mehr für ein Update, sondern für eine saubere Wiederherstellung aus einer Sicherung von vor dem 20. Oktober — und für die Frage, ob personenbezogene Daten betroffen sind. Dann läuft die Frist von 72 Stunden nach Art. 33 DSGVO.
Wobei wir unterstützen
Wir sind ein IT-Systemhaus aus Bad Vilbel bei Frankfurt und betreuen Websites, Onlineshops und Serverumgebungen für mittelständische Betriebe in der Region: in Frankfurt, Offenbach, Hanau, Bad Homburg, Friedberg, Maintal, der Wetterau und im übrigen Rhein-Main-Gebiet. In den letzten beiden Tagen haben wir genau diese Prüfung mehrfach durchlaufen.
Was wir übernehmen können:
- Bestandsaufnahme: Welche Systeme in Ihrem Haus liefern überhaupt PHP aus, welche Version läuft dort, und wer ist jeweils zuständig? Erfahrungsgemäß findet sich dabei mindestens ein System, an das niemand gedacht hat.
- Update und Neustart auf von uns betreuten Servern, einschließlich Container-Abbildern und der Kontrolle, dass wirklich alle Prozesse den neuen Stand verwenden.
- Nachfrage beim Hoster dort, wo wir nicht selbst zuständig sind, mit schriftlicher Bestätigung für Ihre Unterlagen.
- Prüfung auf Spuren einer Ausnutzung, Auswertung der Protokolle und, wenn nötig, Wiederherstellung aus einer sauberen Sicherung.
- Dokumentation für Nachweispflichten, etwa gegenüber einer Cyberversicherung oder im Rahmen von NIS-2.
Wir prüfen Ihre Systeme. Wenn Sie nicht sicher sind, ob Sie betroffen sind, ist das die häufigste und berechtigtste Frage dieser Tage — und sie klärt sich meist in wenigen Minuten am Telefon: 069 4015000-33, oder schreiben Sie an sales@centriccom.de. Wenn es brennt, kommen wir im Rhein-Main-Gebiet auch vor Ort.
Häufige Fragen
Was ist php2shell?
Der Sammelname für zwei kritische Schwachstellen im PHP-Interpreter, CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 Punkten nach CVSS v4.0 bewertet. Angreifer können darüber ohne Anmeldung eigenen Code auf dem Server ausführen. Der Name bedeutet „PHP to shell“: über PHP zur Kommandozeile.
Welche PHP-Version ist sicher?
PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, jeweils diese Version oder neuer. Für PHP 8.1 und älter gibt es vom PHP-Projekt keine Updates mehr, nur minimale Rückportierungen im Quellcode. Dort müssen Sie Ihren Hoster fragen oder den Versionszweig wechseln.
Reicht es, wenn ich WordPress oder meinen Shop aktualisiere?
Nein. Die Lücke sitzt nicht in der Anwendung, sondern im PHP-Interpreter darunter. Der Angriff greift, bevor Programmcode Ihrer Anwendung ausgeführt wird. Weder ein aktuelles WordPress noch ein Sicherheits-Plugin noch ein Anmeldeschutz verhindern ihn. Nur ein Update von PHP selbst hilft.
Betrifft php2shell meinen Shopify-Shop?
Ein gehosteter Shopify-Shop läuft nicht auf Ihrem eigenen PHP — Shopify betreibt die Plattform selbst, und zwar nicht auf PHP-Basis, sondern auf Ruby on Rails. Der Shop-Kern ist von php2shell deshalb nicht betroffen. Aufpassen müssen Sie, wenn Sie daneben etwas Eigenes in PHP betreiben: eine zusätzliche Firmenwebsite, oft WordPress, einen Headless-Storefront mit eigenem PHP-Backend, eine selbst gehostete App oder eine Schnittstelle. Das läuft auf Ihrem Server und muss aktualisiert werden. Shopware, WooCommerce und Magento dagegen sind PHP-Anwendungen — hier gilt die Lücke in vollem Umfang.
Kann ich meine Seite abschirmen, bis das Update da ist?
Ja, wenn der Schutz vor PHP greift. Ein Verzeichnisschutz auf Webserver-Ebene (Basic Auth, in Plesk schnell eingerichtet) oder eine vorgeschaltete Web Application Firewall fängt die Anfrage ab, bevor PHP sie verarbeitet. Der Login Ihrer Anwendung tut das nicht, weil PHP zu diesem Zeitpunkt bereits läuft. Für eine Seite, die ohnehin nur intern gebraucht wird, ist das eine brauchbare Übergangslösung.
Ich habe Webhosting bei einem Anbieter. Muss ich etwas tun?
Ja, mindestens nachsehen. Der Anbieter stellt die aktualisierten PHP-Versionen bereit, aber welcher Zweig für Ihre Domain eingestellt ist, entscheiden Sie im Kundenbereich. Steht dort noch PHP 7.4 oder 8.0, bekommen Sie das Update nicht automatisch.
Hat mein Hoster (IONOS, Strato, Hetzner) die Lücke schon geschlossen?
Die großen Hoster haben die aktualisierten PHP-Versionen in ihren Systemen bereitgestellt. Das schützt Ihre Website aber nur, wenn für Ihre Domain auch ein sicherer Zweig eingestellt ist: PHP 8.2, 8.3, 8.4 oder 8.5 in der jeweils gepatchten Fassung. Den Zweig stellen Sie selbst im Kundenbereich ein — die Hoster schalten eine Hauptversion nicht von sich aus um, weil das ältere Anwendungen lahmlegen könnte. Steht Ihre Domain also noch auf PHP 8.1 oder älter, hat Sie das Update Ihres Hosters nicht erreicht.
Woran merke ich, dass mein System angegriffen wurde?
An neuen oder veränderten PHP-Dateien in Upload- und Cache-Ordnern, an auffälligen Einträgen im Zugriffsprotokoll ab dem 20. Oktober bis zum Zeitpunkt Ihres Updates, an neuen administrativen Benutzern, an ausgehenden Verbindungen zu unbekannten Zielen und an Cronjobs, die niemand angelegt hat.
Betrifft das nur Onlineshops?
Nein. Betroffen ist jedes System, das PHP ausliefert: Firmenwebsites, Kundenportale, Intranets, Dateiablagen wie Nextcloud, Ticketsysteme, Buchungssysteme, Monitoring-Oberflächen, Webmail und Schnittstellen zu ERP oder Warenwirtschaft. Auch Systeme, die nur intern erreichbar sind, gehören auf die Liste.
Wir haben erst gestern aktualisiert. Sind wir damit durch?
Die Lücke ist geschlossen, ja. Offen bleibt die Frage, ob zwischen dem Bekanntwerden am 20. Oktober und Ihrem Update jemand hineingekommen ist. Dieses Zeitfenster ist bei jedem System ein anderes. Bei Systemen, die länger als ein paar Stunden ungepatcht erreichbar waren, gehört eine Prüfung der Protokolle und Dateien dazu.
Woher die Angaben stammen
Versionsnummern, Angriffswege und Übergangsmaßnahmen nach der Sicherheitsmeldung des PHP-Projekts vom 21. Oktober 2026 sowie den zugehörigen Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp. Einstufung und Handlungsempfehlung nach der Pressemitteilung des BSI vom 21. Oktober 2026 (BITS 026-297981-1032) vom 21. Oktober 2026. Betroffene Versionen und nachvollzogener Angriffscode nach dem RUS-CERT der Universität Stuttgart. Betroffene Verwaltungsoberflächen nach der Aufstellung von Black Kite. Das technische Advisory führt CERT-Bund unter WID-SEC-2026-4055.
Stand dieses Beitrags: 22. Oktober 2026. Die Lage entwickelt sich weiter; wir ziehen den Beitrag nach, wenn sich Wesentliches ändert.
Sven Ali Souilem
IT Consultant: Schwerpunkt Websites, Onlineshops, Schnittstellen und Serverbetrieb.