PHP-Sicherheitslücke „PHP2Shell“: Ist meine Website betroffen?

Stand: 21. Oktober 2026, 21 Uhr. Wir aktualisieren diesen Beitrag, sobald es Neues gibt.

Seit dem 20. Oktober 2026 warnen das PHP-Projekt, das BSI und Sicherheitsforscher weltweit vor zwei kritischen Lücken in PHP selbst. Unter dem Namen „PHP2Shell“ gehen sie gerade durch alle Nachrichten, Behörden und Kliniken haben vorsorglich ihre Websites abgeschaltet. PHP ist die Programmiersprache, auf der WordPress, WooCommerce, Shopware, Joomla, TYPO3 und unzählige weitere Websites laufen. Hier liest du, was bekannt ist, ob du selbst etwas tun musst und woran du merkst, dass du Hilfe brauchst.

Das Wichtigste in Kürze

• Betroffen ist praktisch jede Website, die mit PHP läuft – unabhängig davon, ob WordPress, Shop oder eigene Anwendung.
• Sicher sind erst PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober 2026 oder entsprechend korrigierte Pakete deines Hosters.
• PHP 8.1 und älter bekommen vom PHP-Projekt kein Update. Hier hilft nur ein Hoster, der die Korrektur selbst einbaut, oder der Wechsel auf eine aktuelle PHP-Version.
• Das Update schließt die Lücke, entfernt aber keine Hintertür. Lief deine Website ungeschützt, solltest du prüfen lassen, ob schon jemand drin ist – unser Security-Check macht genau das.

Was ist PHP2Shell?

PHP2Shell ist der Spitzname für zwei Schwachstellen im Kern von PHP mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Das PHP-Sicherheitsteam bewertet beide mit 9,2 von 10 Punkten (CVSS 4.0). Über sie können Angreifer aus der Ferne eigenen Code auf dem Webserver ausführen – ohne Login und ohne dass jemand etwas anklicken muss. Der Name spielt auf „Log4Shell“ an, die Java-Lücke von 2021.

Technisch geht es um Speicherfehler: Bricht PHP eine Anfrage ab, etwa weil das Speicherlimit erreicht ist, bleiben interne Daten in einem ungültigen Zustand zurück und werden später weiterverwendet. Ausgelöst wird das über präparierte Formular- bzw. Upload-Anfragen. Für Apache mit mod_php hat das PHP-Projekt gezeigt, dass der Angriff greift, bevor überhaupt Code deiner Website läuft. Deshalb hilft auch kein Plugin-Update: Die Lücke steckt in PHP, nicht in WordPress oder deinem Shop.

Entdeckt haben die Lücken Sicherheitsforscher von Calif und Wiz, die sie im August an das PHP-Projekt gemeldet haben. Am 20. Oktober gelangten Details vorzeitig an die Öffentlichkeit, am 21. Oktober gegen 16 Uhr deutscher Zeit erschienen die korrigierten Versionen.

Welche PHP-Versionen sind sicher?

Wichtig beim Ablesen: Linux-Distributionen wie Debian, Ubuntu oder Red Hat bauen Korrekturen oft in ihre eigenen PHP-Pakete ein, ohne die Versionsnummer zu ändern. Eine Nummer, die nicht in der Tabelle steht, heißt deshalb nicht automatisch, dass deine Website offen ist. Verlässlich ist nur die Bestätigung deines Hosters.

Ist meine Website betroffen?

Wahrscheinlich ja – sofern sie mit PHP läuft und noch nicht auf einer der Versionen oben steht. Laut PHP-Projekt sind alle PHP-Installationen betroffen, die Webanfragen beantworten, egal ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Nicht betroffen sind Websites, die als fertige HTML-Dateien ausgeliefert werden und auf dem Server kein PHP brauchen. Entscheidender als die Frage, ob du betroffen bist, ist: Wer spielt das Update ein?

So findest du deine PHP-Version heraus

1. In WordPress: Werkzeuge → Website-Zustand → Bericht → Server. Dort steht die PHP-Version, mit der deine Website gerade läuft.
2. Beim Hoster: Im Kundenbereich, meist unter „PHP-Version“ oder „PHP-Einstellungen“ deiner Domain.
3. Bei Shops und anderen Systemen: In der Systeminformation des Backends, bei Shopware z. B. unter Einstellungen → System.

PHP 8.1 oder älter: Jetzt wird es ernst

Das PHP-Projekt pflegt nur noch die Versionen 8.2 bis 8.5. Für PHP 7.4, 8.0 und 8.1 hat das Sicherheitsteam wegen der Schwere der Lücken ausnahmsweise einen Quellcode-Flicken veröffentlicht – ob dein Hoster ihn einbaut, liegt allein bei ihm. Wer für „Extended Support“ bezahlt, sollte genau das jetzt schriftlich nachfragen. Kommt keine klare Antwort, ist der Schutz ungeklärt – geh dann davon aus, dass deine Website offen ist, bis sie auf einer gepflegten Version läuft. Mehr zu den Grenzen dieses Modells steht in unserem Beitrag Mit PHP Extended Support sicher bleiben.

Der Wechsel auf eine neue PHP-Version ist allerdings kein Klick im Kundenbereich: Ältere Themes, Plugins und eigener Code brechen auf neuem PHP oft. Ohne Test zeigt die Website danach eine weiße Seite oder Formulare funktionieren nicht mehr. Und auch PHP 8.2 bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates – wer jetzt aktualisiert, sollte gleich auf 8.4 oder 8.5 gehen.

Wird die Lücke schon ausgenutzt?

Ja, Angriffsversuche laufen. Laut dem Sicherheitsunternehmen Sansec hat Cloudflare schon am Morgen des 21. Oktober, Stunden vor dem Update, erste Angriffe gesehen. watchTowr beobachtet seit dem 21. Oktober Ausnutzungsversuche in seinem weltweiten Netz aus Honeypots. Das niederländische NCSC hatte am selben Tag noch keine Hinweise auf erfolgreiche Angriffe, verweist aber auf mehrere öffentliche Exploits und rechnet mit einer breiten Ausnutzung. Vorsicht übrigens bei angeblichen Test-Werkzeugen auf GitHub: Laut JFrog kursieren bereits gefälschte Exploits.

Meine Website ist plötzlich offline – warum?

Viele Hoster, Behörden und Unternehmen haben PHP-Dienste vorsorglich abgeschaltet, bis das Update eingespielt war. Zeigt deine Website seit dem 21. Oktober eine Fehler- oder Wartungsseite, steckt oft eine solche Vorsichtsmaßnahme dahinter. Ob das bei dir so ist, sagt dir die Statusseite oder der Support deines Hosters. Bleibt die Website länger weg, frag konkret, ob es an deiner PHP-Version liegt – bei PHP 8.1 und älter ist das wahrscheinlich.

Was hilft, bis das Update drauf ist?

Nur eingeschränkt etwas. Das PHP-Projekt schreibt ausdrücklich, dass es keine vollständige Abhilfe gibt und nur das Update sicher ist. Als Teilschutz nennt es unter anderem, die Upload-Fortschrittsanzeige von PHP-Sitzungen in der Server- bzw. PHP-FPM-Konfiguration abzuschalten (session.upload_progress.enabled=0, danach alle PHP-Prozesse neu starten) und die Größe von Formularanfragen zu begrenzen. Eine Web Application Firewall vor der Website kann Angriffe abfangen, sofern sie passende Regeln hat. Wo das Update nicht kurzfristig möglich ist, ist eine Wartungsseite für ein paar Stunden besser als eine gekaperte Website, die wochenlang Spam verschickt. Wichtig: Die Wartungsseite muss der Webserver oder Proxy ausliefern, ohne PHP zu starten – der Wartungsmodus von WordPress reicht nicht, er läuft selbst über PHP.

Update drauf – und jetzt?

Das Update schließt die Lücke. Hat ein Angreifer sie vorher genutzt, um eine Hintertür einzubauen, bleibt diese davon unberührt – und genau so laufen solche Angriffswellen meist ab: erst massenhaft einbrechen, später ausnutzen. Diese Anzeichen sprechen dafür, dass jemand in deiner Website steckt:

• unbekannte Administratoren oder Benutzerkonten in WordPress,
• neue oder veränderte PHP-Dateien, besonders im Upload-Ordner oder im Theme,
• Weiterleitungen auf fremde Seiten, oft nur für Besucher vom Smartphone oder aus der Google-Suche,
• fremde Seiten oder Spam-Begriffe in den Google-Suchergebnissen zu deiner Domain,
• Hinweise deines Hosters auf Spam-Versand oder ungewöhnliche Last.

Viele Einbrüche bleiben aber unsichtbar. Lief deine Website am 20. und 21. Oktober ohne Schutz, ist ein Check auch ohne Auffälligkeiten sinnvoll. In unserem Security-Check prüfen wir Dateien, Datenbank, Benutzerkonten und Logs auf Spuren eines Einbruchs, und bereinigen deine Website, falls wir etwas finden.

So haben wir die Websites unserer Kunden geschützt

Alle WordPress-Websites, die wir betreiben, laufen auf unseren eigenen Servern. Am 21. Oktober sind wir so vorgegangen:

• Mittags: Die Firewall vor allen Websites holt ihre Regeln seitdem alle 30 Minuten statt einmal täglich, damit Schutzregeln für neue Lücken sofort greifen.
• Noch vor dem offiziellen Update: Wir haben den bekannten Angriffsweg über die Upload-Fortschrittsanzeige von PHP auf allen Websites abgeschaltet.
• Am Nachmittag: Die Firewall weist seitdem Upload-Anfragen ab, die sie nicht vollständig prüfen kann. Und bis das korrigierte PHP für unsere Server bereitstand, haben wir die Websites hinter eine Wartungsseite genommen – in dieser Zeit erreichte keine Anfrage PHP.
• Am Abend: Alle Websites liefen auf dem korrigierten PHP 8.5.12 und waren wieder online.

Unsere Kunden mussten dafür nichts tun. Genau das ist der Gedanke hinter unserer Wartung und unserem Hosting: Wenn die nächste Lücke kommt, kümmern wir uns darum – du musst nicht selbst die Nachrichten verfolgen.

Was du jetzt tun solltest

1. PHP-Version deiner Website herausfinden.
2. Beim Hoster nachsehen oder nachfragen, ob das Update (8.5.12, 8.4.27, 8.3.36 oder 8.2.35) bzw. eine korrigierte Fassung eingespielt ist.
3. Bei PHP 8.1 oder älter: nach der Korrektur fragen und den Wechsel auf eine aktuelle Version planen – nicht erst Ende des Jahres.
4. Bei eigenen Servern und Containern: PHP-Pakete aktualisieren, Images neu bauen, Dienste neu starten.
5. Danach auf Spuren eines Einbruchs prüfen oder prüfen lassen.

Häufige Fragen

Muss ich als WordPress-Nutzer selbst etwas tun?

Ein WordPress-Update allein hilft nicht, die Lücke steckt in PHP. Bei einem Webhosting-Paket spielt dein Hoster das Update ein; du solltest prüfen, ob er es getan hat, und deine PHP-Version kontrollieren. Bei PHP 8.1 und älter musst du handeln.

Hilft ein Sicherheits-Plugin wie Wordfence oder NinjaFirewall?

Nur begrenzt. Zumindest bei Apache mit mod_php greift der Angriff, während PHP die Anfrage einliest – also bevor WordPress und seine Plugins überhaupt laufen. Eine Firewall vor dem Server kann Angriffe abfangen, ein Plugin innerhalb von WordPress kommt dann zu spät.

Sind Online-Shops besonders gefährdet?

Shops mit WooCommerce, Shopware oder Magento sind genauso betroffen wie jede andere PHP-Website, haben aber mehr zu verlieren: Kundendaten, Bestellungen und manipulierte Zahlungsseiten. Hier lohnt sich der Check nach dem Update besonders.

Was bedeutet das Support-Ende von PHP 8.2?

Ab dem 1. Januar 2027 bekommt PHP 8.2 vom PHP-Projekt keine Sicherheitsupdates mehr. Die Website läuft weiter, bei der nächsten Lücke gibt es aber keine Korrektur. Wer jetzt ohnehin aktualisiert, sollte direkt auf PHP 8.4 oder 8.5 wechseln.

Quellen

• PHP-Projekt: Sicherheitshinweis vom 21. Oktober 2026
• GitHub-Advisory zu CVE-2026-109618 und zu CVE-2026-109619
• PHP-Projekt: unterstützte Versionen
• Sansec: PHP2Shell
• watchTowr: FAQ zu CVE-2026-109618
• NCSC-NL: PHP2Shell
• JFrog: PHP2Shell – all you need to know