PHP-Sicherheitslücke „PHP2Shell“: Was Website-Betreiber jetzt prüfen müssen
Stand: 30. Oktober 2026
Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßig zwei kritische Sicherheitslücken geschlossen. PHP ist die Programmiersprache, auf der WordPress, Joomla, Drupal und ein Großteil aller Websites laufen – entsprechend groß war die Aufregung. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat Betreiber von Webservern zum sofortigen Handeln aufgefordert, weltweit gingen Websites vorübergehend offline, um die Updates einzuspielen.
Viele unserer Kunden fragen jetzt: Betrifft mich das? Und was muss ich tun? Hier die Antworten – verständlich und ohne Panik.
Die Lücken CVE-2026-109618 und CVE-2026-109619 („PHP2Shell“) erlauben Angreifern, ohne Anmeldung eigenen Programmcode auf dem Server auszuführen – auch dann, wenn WordPress, Joomla oder Drupal und alle Erweiterungen aktuell sind. Geschützt sind nur die PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer bzw. entsprechend korrigierte Pakete Ihres Hosters. Weil Angriffe schon vor dem Update begonnen haben, sollte auch eine inzwischen aktualisierte Website auf Spuren eines Einbruchs geprüft werden.
Was ist PHP2Shell?
„PHP2Shell“ ist der Spitzname für zwei Fehler in der Speicherverwaltung von PHP selbst. Vereinfacht gesagt: Bei bestimmten Fehlersituationen während einer Seitenanfrage räumt PHP seinen Arbeitsspeicher nicht sauber auf. Ein Angreifer kann das mit präparierten Anfragen ausnutzen und eigenen Code auf dem Webserver ausführen.
Beide Lücken sind mit 9,2 von 10 Punkten (CVSS 4.0) als kritisch eingestuft. Betroffen sind alle gängigen Betriebsarten, in denen PHP Webseiten ausliefert – PHP-FPM, Apache mit mod_php und CGI. Sicherheitsforscher haben bereits gezeigt, dass sich so WordPress- und Drupal-Installationen ohne Zugangsdaten übernehmen lassen.
Warum sind auch gut gewartete Websites betroffen?
Die meisten Sicherheitslücken, über die wir sonst schreiben, stecken in Plugins, Erweiterungen oder im CMS. Die schließt man mit einem Update im Backend.
Bei PHP2Shell ist das anders: Die Lücke steckt in der Software des Servers, nicht in Ihrer Website. Ein Update von WordPress oder ein Security-Plugin ändert daran nichts. Zuständig ist, wer den Server betreibt:
- Shared Hosting / Webhosting-Paket: in der Regel Ihr Hosting-Anbieter.
- Eigener Server, VPS oder Managed Server: Sie selbst oder Ihr IT-Dienstleister – je nach Vertrag.
Gerade bei kleineren Firmen ist diese Zuständigkeit oft nicht klar geregelt. Genau das ist jetzt der Moment, es zu klären.
So prüfen Sie, ob Ihre Website noch gefährdet ist
WordPress: Werkzeuge → Website-Zustand → Bericht → Server. Joomla: System → Systeminformationen. Drupal: Berichte → Statusbericht. Alternativ steht die Version im Kundenmenü Ihres Hosting-Anbieters.
Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie alle neueren Versionen des jeweiligen Zweigs. Zeigt Ihre Website eine niedrigere Nummer, ist sie möglicherweise noch angreifbar.
Viele Hoster nutzen die PHP-Pakete von Linux-Distributionen wie Debian oder Ubuntu. Dort werden Sicherheitskorrekturen oft eingespielt, ohne dass sich die Versionsnummer ändert. Eine scheinbar alte Nummer bedeutet dann nicht automatisch, dass der Server ungeschützt ist – hier hilft nur die Nachfrage beim Hoster.
Für PHP 8.1, 8.0 und 7.x hat das PHP-Projekt keine Korrektur veröffentlicht, weil diese Versionen nicht mehr unterstützt werden. Läuft Ihre Website noch darauf, ist sie nur geschützt, wenn Ihr Hoster selbst nachgebessert hat. Ansonsten ist der Umstieg auf eine aktuelle Version jetzt Pflicht.
Eine kurze E-Mail genügt: „Ist der Server meiner Website gegen CVE-2026-109618 und CVE-2026-109619 gepatcht, und seit wann?“ Das Datum ist wichtig für den nächsten Schritt.
Nicht nur die Website läuft mit PHP. Auch Online-Shops, Intranets, Ticketsysteme, Zeiterfassungen oder Kundenportale auf eigenen Servern brauchen dasselbe Update. Laut BSI veröffentlichen inzwischen sogar Hersteller von Netzwerkgeräten Hinweise, weil PHP in ihren Produkten steckt.
Gepatcht heißt nicht sauber: Warum Sie trotzdem nachsehen sollten
Technische Details zu den Lücken sind schon vor dem offiziellen Update bekannt geworden. Erste Angriffsversuche wurden bereits am 17. Oktober beobachtet – vier Tage bevor die Korrektur überhaupt verfügbar war.
Das Update schließt die Lücke. Es entfernt aber keine Hintertüren, die ein Angreifer vorher eingerichtet hat. Wer in dieser Zeit eingedrungen ist, kann also weiterhin Zugriff haben. Achten Sie deshalb auf folgende Anzeichen:
Benutzer mit Administratorrechten, die niemand aus Ihrem Team angelegt hat.
In Ordnern für Bilder und Dokumente haben Programmdateien nichts zu suchen – etwa in wp-content/uploads (WordPress), images (Joomla) oder sites/default/files (Drupal).
Dateien, die seit Mitte Oktober verändert oder neu angelegt wurden, ohne dass jemand an der Website gearbeitet hat.
Plugins oder Erweiterungen, die niemand installiert hat – bei WordPress besonders im Ordner wp-content/mu-plugins, der im Backend kaum auffällt.
Neue Einträge in der .htaccess-Datei oder Besucher, die plötzlich auf fremde Seiten umgeleitet werden.
Gehäufte Speicher- oder Fatal-Error-Meldungen und ungewöhnliche Anfragen im Zeitraum zwischen dem 17. Oktober und dem Update Ihres Servers.
Wichtig: Viele Hoster bewahren Server-Logs nur wenige Tage oder Wochen auf. Lassen Sie sie jetzt sichern, sonst fehlen später die Beweise, ob etwas passiert ist.
Gibt es einen konkreten Verdacht, sollten Sie alle Passwörter ändern (Website-Admins, FTP/SFTP, Datenbank, Hosting-Konto), bei WordPress die Sicherheitsschlüssel in der wp-config.php erneuern und die Website gründlich untersuchen lassen. Wie eine solche Bereinigung abläuft, beschreiben wir in unserem Beitrag Gehackte Websites wiederherstellen.
Was Sie aus PHP2Shell für die Zukunft mitnehmen sollten
Der Fall zeigt zwei Dinge sehr deutlich. Erstens: Website-Sicherheit endet nicht beim CMS. Auch die Server-Software – PHP, Datenbank, Webserver – muss aktuell gehalten werden, und es muss klar sein, wer dafür zuständig ist.
Zweitens: Die Zeit zwischen dem Bekanntwerden einer Lücke und den ersten Angriffen wird immer kürzer. Wer erst beim nächsten regulären Wartungstermin reagiert, ist bei kritischen Lücken zu spät.
Zu einer professionellen Website-Wartung gehört deshalb auch, die PHP-Version im Blick zu behalten, Sicherheitswarnungen zu verfolgen und im Ernstfall sofort mit dem Hoster zu klären, ob und wann gepatcht wurde.
Wir prüfen PHP-Version und Patch-Stand Ihres Servers, untersuchen WordPress-, Joomla- und Drupal-Websites auf Spuren eines Angriffs und klären bei Bedarf direkt mit Ihrem Hosting-Anbieter, was zu tun ist.
Häufige Fragen zur PHP-Sicherheitslücke PHP2Shell
Muss ich als Website-Betreiber selbst etwas tun?
Ja, zumindest prüfen. Bei einem normalen Webhosting-Paket ist meist der Hoster für das PHP-Update zuständig. Sie sollten aber kontrollieren, welche PHP-Version läuft, sich das Update bestätigen lassen und Ihre Website auf Spuren eines Angriffs untersuchen – denn das übernimmt der Hoster in der Regel nicht.
Hilft ein WordPress-Update oder ein Security-Plugin gegen PHP2Shell?
Nein. Die Lücke steckt in PHP selbst, nicht in WordPress, Joomla oder Drupal. Updates im Backend und Security-Plugins wie Wordfence können sie nicht schließen. Geschützt ist eine Website nur, wenn auf dem Server eine korrigierte PHP-Version läuft.
Welche PHP-Versionen sind sicher?
Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie neuere Versionen. Hoster, die PHP-Pakete von Linux-Distributionen einsetzen, können die Korrektur auch in Versionen mit niedrigerer Nummer eingespielt haben. Im Zweifel fragen Sie Ihren Hoster.
Meine Website läuft noch mit PHP 7.4 oder 8.1 – was nun?
Für diese Versionen gibt es vom PHP-Projekt keine Korrektur. Die Website sollte so schnell wie möglich auf eine aktuelle PHP-Version umgestellt werden. Bei älteren Websites müssen dafür oft vorher CMS, Plugins oder Templates aktualisiert werden, damit nach dem Umstieg alles funktioniert.
Sind auch Joomla- und Drupal-Websites betroffen?
Ja. Betroffen ist jede Anwendung, die auf einer ungepatchten PHP-Version läuft – egal ob WordPress, Joomla, Drupal, ein Online-Shop oder eine selbst programmierte Anwendung.
Mein Hoster hat gepatcht – bin ich damit auf der sicheren Seite?
Gegen neue Angriffe über diese Lücke ja. Da Angriffe aber schon vor dem Update begonnen haben, sollte zusätzlich geprüft werden, ob in der Zwischenzeit jemand eingedrungen ist und eine Hintertür hinterlassen hat.
Woran erkenne ich, ob meine Website angegriffen wurde?
Typische Spuren sind unbekannte Administrator-Konten, PHP-Dateien in Upload-Ordnern, unerklärlich geänderte Dateien und auffällige Einträge in den Server-Logs. Ein erfolgreicher Angriff kann aber auch völlig unauffällig bleiben. Sicherheit bringt nur eine gründliche technische Prüfung.
Unterstützung bei der Prüfung
Sie wissen nicht, welche PHP-Version Ihre Website nutzt, oder Ihr Hoster antwortet nicht? Nestocom prüft WordPress-, Joomla- und Drupal-Websites auf PHP2Shell, klärt den Patch-Stand mit Ihrem Hosting-Anbieter und unterstützt bei der Bereinigung, falls etwas passiert ist. Sprechen Sie uns an – wir melden uns kurzfristig.