PHP2Shell: Bin ich betroffen? Der Check in 5 Fragen.
Kurz gesagt: Am 21. Oktober 2026 wurden zwei kritische Lücken in PHP bekannt, genannt PHP2Shell (CVE-2026-109618 und CVE-2026-109619). Angreifer können damit ohne Login eigenen Code auf dem Server ausführen und Speicher mit Passwörtern und Zugangsschlüsseln auslesen. Betroffen ist fast jede PHP-Version seit 5.4, also auch WordPress, WooCommerce, Shopware, Magento, TYPO3 und Drupal. Sicher sind nur PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Für PHP 8.1 und älter gibt es keinen offiziellen Patch. Das BSI stuft die Lücken als kritisch ein und rechnet mit Angriffen binnen Stunden.
Quellen: Sicherheitshinweise der PHP-Entwickler vom 21. Oktober 2026, Warnmeldung des BSI, Alert der US-Behörde CISA, Analysen von Wiz Research, Sansec und dem RUS-CERT der Universität Stuttgart. Stand: 22. Oktober 2026.
Am Mittwoch, dem 21. Oktober, waren plötzlich Websites von Behörden, Unis und Kliniken nicht mehr erreichbar. In den Niederlanden ging das Nationale Zentrum für Cybersicherheit selbst vom Netz. Nicht, weil jemand eingebrochen war, sondern weil die Betreiber verhindern wollten, dass es passiert.
Der Grund heißt PHP2Shell. Zwei Lücken in PHP, der Programmiersprache, auf der laut der Sicherheitsfirma Wiz rund 70 Prozent aller Websites laufen. Wenn deine Seite mit WordPress, WooCommerce, Shopware oder TYPO3 gebaut ist, läuft sie auf PHP. Ob du davon weißt oder nicht.
Das Unangenehme an dieser Lücke: Sie steckt nicht in einem Plugin, das man deaktivieren kann, und nicht in einem Theme, das man austauscht. Sie steckt im Fundament. Eine Website mit sauberem Code und null Plugins ist genauso betroffen wie die alte Seite, um die sich seit Jahren keiner kümmert.
Wir haben die Hinweise von PHP, BSI, CISA und den Forschern, die die Lücken gefunden haben, durchgearbeitet. Hier sind die zwölf Fakten, die du kennen musst, und am Ende fünf Fragen, mit denen du in zehn Minuten weißt, ob du handeln musst.
Die Lücke
Zuerst das Ausmaß. Selten treffen so viele Warnstufen auf einmal zusammen.
1. Fast höchste Gefahrenstufe. Beide Lücken haben eine Bewertung von 9,2 von 10 Punkten. Das BSI stuft sie als kritisch ein: sofortiger Handlungsbedarf.
2. Kein Login nötig. Angreifer brauchen weder Passwort noch Zugang. Eine präparierte Anfrage an die Website reicht, um Code auf dem Server auszuführen.
3. Fast jede PHP-Version seit 5.4 ist betroffen. Das sind PHP-Versionen aus über zehn Jahren, und schon die Standardeinstellung ist verwundbar. Die Forscher haben den Angriff gegen WordPress, Drupal und Magento nachgewiesen.
4. Sauberer Code schützt nicht. Die Lücke sitzt in PHP selbst. Auch eine Website ohne ein einziges Plugin ist angreifbar, solange die PHP-Version nicht aktualisiert ist.
5. Deine Daten können mit abfließen. Eine der beiden Lücken erlaubt es, den Arbeitsspeicher des Servers auszulesen. Darin können Passwörter, Login-Sitzungen, API-Schlüssel und Zertifikatsschlüssel stehen, auch die von anderen Besuchern. Das ist der Teil, der über die Website hinausgeht.
Das Tempo
Früher lagen zwischen Patch und erstem Angriff oft Wochen. Bei PHP2Shell waren die Angreifer schneller als der Patch.
6. Die ersten Angriffe kamen vor dem Update. Cloudflare registrierte erste Angriffsversuche am 21. Oktober um 7:43 Uhr Weltzeit. Das offizielle PHP-Update erschien erst um 14 Uhr.
7. Der Angriffscode ist öffentlich. Das Sicherheitsteam der Uni Stuttgart hat einen frei verfügbaren Exploit auf einem Testsystem erfolgreich nachgestellt. Wer angreifen will, muss nichts mehr selbst entwickeln.
8. Gefunden mit KI, ausgenutzt bald auch mit KI. Die Forscher von Wiz haben die Lücken mithilfe von KI-Modellen gefunden und verkettet. Das BSI erwartet Angriffe binnen Stunden, auch weil KI-Werkzeuge das Schreiben von Angriffscode beschleunigen.
9. Behörden empfehlen, Seiten vom Netz zu nehmen. Die EU-Cybersicherheitsstelle CERT-EU und die US-Behörde CISA raten: Was nicht sofort aktualisiert werden kann, geht offline. Die niederländische Techseite Tweakers und das niederländische NCSC haben genau das getan.
Der Fix
Die gute Nachricht: Es gibt ein Update. Die schlechte: Es kommt nicht bei allen an.
10. Nur vier Versionen sind sicher: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Alles darunter ist offen.
11. PHP 8.1 und älter bekommt keinen offiziellen Patch. Wer noch auf einer alten Version läuft, braucht einen Notfall-Backport vom Hoster oder Linux-Anbieter oder muss auf eine aktuelle Version umziehen. Bei älteren Websites heißt das oft: Plugins und Theme müssen mit.
12. Update allein reicht nicht. Nach dem Einspielen müssen Webserver und PHP-Prozesse neu gestartet werden, sonst läuft der alte, verwundbare Code weiter. Und die bekannten Notlösungen in der PHP-Konfiguration senken nur das Risiko. Sicher macht nur das Update.
Die D!E-Einordnung
Die meisten Website-Betreiber, mit denen wir sprechen, wissen nicht, welche PHP-Version auf ihrer Seite läuft. Das ist kein Vorwurf. PHP ist unsichtbar, bis es kaputtgeht. Genau deshalb trifft PHP2Shell den Mittelstand härter als Konzerne: Dort gibt es ein Team, das noch am selben Abend gepatcht hat. Bei vielen kleineren Unternehmen gibt es einen Hosting-Vertrag und die Hoffnung, dass der Hoster das schon macht.
Oft macht er es auch. Aber nicht immer, und nicht für alles. Auf Managed-Hosting wird PHP meist zentral aktualisiert. Auf eigenen Servern, alten Testsystemen, vergessenen Microsites oder einer Kampagnenseite von 2021 macht es niemand. Gefährlich ist selten die Hauptseite. Gefährlich ist die Seite, an die keiner mehr denkt.
Der zweite Punkt ist die Zeit. Die Lücken waren den PHP-Entwicklern seit August gemeldet, gepatcht wurde am 21. Oktober, angegriffen wurde schon vorher. Das Zeitfenster zwischen Bekanntwerden und Angriff ist praktisch weg. Wer erst updatet, wenn er in der Zeitung davon liest, ist zu spät dran.
Für uns ist das der Unterschied zwischen einer Website und einem Websystem. Eine Website wird gebaut und läuft dann irgendwie. Ein Websystem hat jemanden, der weiß, welche PHP-Version darauf läuft, wer sie aktualisiert und was passiert, wenn es brennt. PHP2Shell ist der Stresstest, der zeigt, was man hat.
Der 5-Fragen-Check für deine Website
Fünf Fragen, ehrlich mit Ja oder Nein beantworten. In WordPress findest du die PHP-Version unter Werkzeuge → Website-Zustand → Bericht → Server.
- Weißt du, welche PHP-Version auf deiner Website läuft?
- Ist es 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder neuer?
- Hat dein Hoster schriftlich bestätigt, dass gepatcht und neu gestartet wurde?
- Bist du sicher, dass nirgends mehr eine alte Seite läuft, etwa eine Testumgebung, eine Microsite oder eine alte Subdomain?
- Weißt du, wer bei euch Admin-Passwörter und API-Schlüssel erneuert, falls die Seite ungepatcht online war?
Ein einziges Nein reicht, um jetzt zu handeln. Diese Lücke wartet nicht auf den nächsten Wartungstermin.
Mindestens ein Nein? Wir prüfen das für dich. Welche PHP-Version läuft auf deiner Website und auf allen Nebenseiten, hat der Hoster wirklich gepatcht, wo laufen noch Altsysteme, welche Zugänge sollten jetzt erneuert werden. Wenn ein Update nötig ist, setzen wir es um, inklusive Test, dass Shop und Formulare danach noch funktionieren. Melde dich über das Beratungsgespräch, Stichwort „PHP2Shell“.
FAQ: PHP-Sicherheitslücke PHP2Shell
Ist meine WordPress-Website von PHP2Shell betroffen?
Sehr wahrscheinlich, wenn die PHP-Version nicht aktualisiert wurde. WordPress läuft auf PHP, und die Lücken betreffen fast jede PHP-Version seit 5.4 in der Standardeinstellung. Sicher sind nur PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Die eigene Version steht in WordPress unter Werkzeuge, Website-Zustand, Bericht, Server.
Sind durch die PHP-Lücke auch meine persönlichen Daten in Gefahr?
Möglicherweise. Eine der beiden Lücken, CVE-2026-109618, erlaubt das Auslesen des Server-Arbeitsspeichers. Darin können Passwörter, Login-Sitzungen, API-Schlüssel und Zertifikatsschlüssel stehen, auch von anderen Besuchern. Betroffen sind also nicht nur die Website selbst, sondern auch Daten, die über eine ungepatchte Seite laufen. Für Besucher gilt: Bei Hinweisen des Anbieters Passwörter ändern.
Welche PHP-Versionen sind sicher?
PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie neuere Versionen. Für PHP 8.1 und ältere Versionen gibt es keine offizielle Sicherheitsversion. Dort helfen nur Notfall-Pakete des Hosters oder Linux-Anbieters oder der Umstieg auf eine aktuelle Version. Nach dem Update müssen Webserver und PHP-Prozesse neu gestartet werden.
Reicht es, wenn mein Hoster PHP aktualisiert?
Für die Hauptseite auf einem gemanagten Hosting oft ja, aber nur, wenn der Hoster das Update tatsächlich eingespielt und die PHP-Prozesse neu gestartet hat. Das sollte man sich bestätigen lassen. Eigene Server, alte Testsysteme, Microsites und Seiten bei anderen Anbietern deckt der Hoster der Hauptseite in der Regel nicht ab.
Das Fazit, ungefiltert
Fast jede PHP-Website ist betroffen. Ein Login ist nicht nötig. Die ersten Angriffe kamen vor dem Update.
PHP2Shell ist nicht die erste kritische Lücke und wird nicht die letzte sein. Neu ist das Tempo. Wenn KI Lücken schneller findet und Angriffscode schneller schreibt, schrumpft die Zeit zum Reagieren von Wochen auf Stunden. Eine Website, um die sich niemand aktiv kümmert, ist unter diesen Bedingungen kein kleines Risiko mehr, sondern ein offenes.
Die Aufgabe für heute ist trotzdem klein: PHP-Version nachsehen, Hoster fragen, alte Seiten finden. Die Aufgabe für morgen ist größer. Sie lautet: Wer ist bei uns dafür zuständig, wenn das nächste Mal so eine Meldung kommt?
Wenn die Antwort darauf „keiner“ ist, dann ist genau das die eigentliche Sicherheitslücke.
Geschrieben von Dag Achtzehn, Gründer von D!E mit Ausrufezeichen. KI-First-Marketing aus Montabaur für den DACH-Raum. Wir reden nicht über KI. Wir arbeiten damit.
Bereit, dein Marketing auf D!E-Niveau zu heben? Lass uns sprechen.
Sag Hallo →