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

Seit dem 20. Oktober 2026 warnen das PHP-Projekt, das BSI und die IT-Sicherheitsbehörde der EU vor zwei kritischen Lücken in PHP. In der Fachpresse heißen sie „PHP2Shell“, angelehnt an die Log4j-Lücke „Log4Shell“ von 2021. PHP ist die Programmiersprache, auf der WordPress, Joomla, TYPO3, die meisten Shops und unzählige eigene Webanwendungen laufen. Hier steht, was bekannt ist, ob Sie selbst etwas tun müssen und wann es sich lohnt, das abzugeben.

Aktueller Stand

Stand: 22. Oktober 2026. Die meisten Webhoster haben das Update inzwischen auf ihren Servern eingespielt. Liegt Ihre Website in einem gewöhnlichen Webhosting-Paket mit PHP 8.2 bis 8.5, ist sie damit in aller Regel geschützt, ohne dass Sie etwas tun mussten. Vorsorglich abgeschaltete Seiten gehen nach und nach wieder ans Netz.

Offen sind jetzt vor allem drei Fälle:

• Eigene Server, virtuelle Server und Docker-Container, um die sich niemand außer Ihnen oder Ihrem Dienstleister kümmert.
• Websites auf PHP 8.1 oder älter. Die US-Cybersicherheitsbehörde CISA rät, solche Systeme vom Netz zu nehmen, wenn sie sich nicht sofort absichern lassen.
• Seiten, die vor dem Update offen waren. Amazon hat in seinen Lockfallen schon am 17. Oktober einen Angriffsversuch registriert, vier Tage vor der Veröffentlichung, und stuft die Lücke inzwischen als breit ausgenutzt ein. Ob einer der Versuche bei echten Websites Erfolg hatte, ist laut Amazon noch unklar, öffentlich bestätigte Einbrüche gibt es bisher nicht. Amazon rät aber, Server mindestens ab dem 17. Oktober auf Spuren zu prüfen, nicht erst ab dem Tag des Updates.

Was ist passiert?

Am 20. Oktober kündigte das PHP-Sicherheitsteam auf php.net ein Sicherheitsupdate für Mittwoch, den 21. Oktober 2026, 16 Uhr deutscher Zeit an. Es schließt zwei Lücken, beide mit 9,2 von 10 Punkten nach dem Bewertungssystem CVSS eingestuft. Am selben Tag waren erste Details vorzeitig an die Öffentlichkeit gelangt. Das Update kam am 21. Oktober schließlich etwas früher als angekündigt.

Stand: 21. Oktober 2026. Diese Versionen schließen beide Lücken:

PHP-Zweig	Sichere Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1, 8.0 und 7.4	kein offizielles Update, nur ein Quellcode-Flicken für Hoster und Distributionen
PHP 7.3 und älter	keine Korrektur vom PHP-Projekt

Das PHP-Projekt schreibt dazu ausdrücklich, dass es keine vollständige Abhilfe gibt und nur das Update sicher ist.

Das BSI hat am 21. Oktober einen Sicherheitshinweis mit der zweithöchsten Stufe „Orange“ veröffentlicht: Maßnahmen müssen unverzüglich ergriffen werden. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Nach der Bewertung könnten Angreifer damit aus der Ferne eigenen Code auf dem Webserver ausführen, ohne Login und ohne dass jemand etwas anklicken muss.

Wer Code auf dem Server ausführen kann, kann Daten auslesen, Schadcode in die Website einbauen, Spam verschicken oder die Seite auf fremde Angebote umleiten.

Ist meine Website betroffen?

Wahrscheinlich ja, sofern sie mit PHP läuft und nicht schon auf einer der Versionen oben steht. Laut PHP-Projekt betroffen sind alle PHP-Installationen, die Webanfragen beantworten, egal in welcher Betriebsart (PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed); am höchsten ist das Risiko bei mod_php. Laut BSI reichen die Lücken zurück bis mindestens PHP 5. Nicht betroffen sind Websites, die als fertige HTML-Dateien ausgeliefert werden und auf dem Server gar kein PHP brauchen.

Entscheidend ist nicht, ob Sie betroffen sind, sondern wer das Update einspielt und ob es für Ihre Version überhaupt eins gibt:

Ihre Lage	Wer handeln muss
Website im Webhosting-Paket (z. B. bei IONOS, STRATO, mittwald, all-inkl) mit PHP 8.2 bis 8.5	Der Hoster spielt das Update auf seinen Servern ein. Sie prüfen, ob er es bestätigt hat.
Website auf PHP 8.1 oder älter, auch mit gebuchtem „Extended Support“	Kein offizielles Update. Der Hoster muss den Flicken selbst einbauen; sonst bleibt nur die Umstellung auf eine aktuelle Version.
Eigener Server oder virtueller Server (VPS)	Sie bzw. Ihr Dienstleister aktualisieren PHP über die Paketverwaltung des Betriebssystems.
Anwendung in Docker-Containern	Das Image muss mit dem neuen PHP neu gebaut und ausgerollt werden.
Geräte und Programme mit eingebautem PHP (z. B. Firewalls wie pfSense oder OPNsense)	Der Hersteller muss ein Update liefern.

Beim Webhoster mittwald zum Beispiel werden die Patches automatisch ausgerollt; Kunden müssen dafür nichts tun. Bei anderen Anbietern lohnt der Blick auf die Statusseite.

Welche PHP-Version Ihre Seite nutzt, steht im Kundenbereich Ihres Hosters, meist unter „PHP-Version“ oder „PHP-Einstellungen“ der Domain. In WordPress zeigt es auch der Menüpunkt „Werkzeuge → Website-Zustand → Bericht“.

Vorsicht beim Ablesen: Auf Servern mit Ubuntu, Debian oder Red Hat bauen die Hersteller die Korrektur in ihre eigenen PHP-Pakete ein, die Versionsnummer bleibt dabei oft die alte. Ubuntu 24.04 etwa liefert die geschützte Fassung weiter als PHP 8.3.6 aus. Eine Nummer, die nicht in der Tabelle oben steht, heißt deshalb nicht automatisch, dass die Seite offen ist. Verlässlich ist nur die Bestätigung des Hosters oder ein Blick in das Änderungsprotokoll des Pakets.

Was ist mit PHP 8.1 und älter?

Das ist der eigentliche Knackpunkt. Das PHP-Projekt pflegt nur die Versionen 8.2 bis 8.5; alles darunter bekommt seit Jahren keine Sicherheitsupdates mehr (die Übersicht steht im Beitrag zum Support-Ende von PHP 8.2). Ein fertiges Update gibt es für sie deshalb auch diesmal nicht. Für PHP 7.4, 8.0 und 8.1 hat das Sicherheitsteam immerhin einen minimalen Quellcode-Flicken veröffentlicht; einige Linux-Distributionen und Anbieter mit Langzeit-Support liefern eigene Korrekturen. Ubuntu zum Beispiel hat am 21. Oktober das mitgelieferte PHP 8.1 von Ubuntu 22.04 abgesichert; für Ubuntu 20.04 und älter gibt es die Korrektur nur über das Zusatzangebot Ubuntu Pro.

Ob Ihr Hoster diesen Flicken für Ihre Version einbaut, hängt allein von ihm ab. Wer für „Extended Support“ bezahlt, sollte genau das jetzt schriftlich nachfragen. Kommt keine klare Antwort, ist die Seite offen, und zwar so lange, bis sie auf einer gepflegten Version läuft.

Der Wechsel lässt sich nicht einfach per Klick im Kundenbereich erledigen: Alte Themes, Plugins und eigener Code brechen oft auf neuem PHP. Ohne Test kann die Seite danach weiß bleiben oder Formulare funktionieren nicht mehr.

Wie gefährlich ist es, abzuwarten?

Sehr. Das BSI hält eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich, weil Angreifer Updates inzwischen mit KI-Werkzeugen schnell auswerten. Bei der WordPress-Lücke „wp2shell“ im Juli lagen zwischen Patch und ersten Angriffen ebenfalls nur Stunden (Einzelheiten im Beitrag zu den WordPress-Sicherheitslücken 2026).

Laut Sansec hat der Netzwerkdienst Cloudflare schon am Morgen des 21. Oktober frühe Angriffe gesehen und für alle Kunden Filterregeln eingeschaltet. Bestätigte erfolgreiche Angriffe waren zum Zeitpunkt des BSI-Hinweises noch nicht bekannt. Kurz nach dem Update, am Nachmittag des 21. Oktober, meldete das Sicherheitsunternehmen watchTowr aktive Angriffsversuche auf beide Lücken. Amazon berichtete am selben Tag sogar von einem Versuch am 17. Oktober, vier Tage bevor die Lücken öffentlich bekannt wurden. Die Angriffe laufen damit nicht mehr nur in der Theorie.

Wie ernst die Lage genommen wird, zeigen die Abschaltungen am 21. Oktober: Die Stadt Mainz und die Berliner Charité nahmen ihre Websites vom Netz (tagesschau.de), ebenso Landesregierungen in Baden-Württemberg, Bayern, Hessen und Thüringen sowie die Stadt Dresden (dpa). In den Niederlanden ging unter anderem das Parlament offline. Auch Webhoster haben vorsorglich PHP-Dienste ihrer Kunden abgeschaltet, bis das Update eingespielt war.

Meine Website ist plötzlich offline – was heißt das?

Ist Ihre Seite seit dem 21. Oktober nicht erreichbar oder zeigt eine Wartungsseite, steckt sehr wahrscheinlich eine solche Vorsichtsmaßnahme dahinter und kein Angriff. Sehen Sie auf der Statusseite oder im Kundenbereich Ihres Hosters nach, ob er Abschaltungen meldet. Meist geht die Seite wieder ans Netz, sobald das Update auf dem Server ist.

Bleibt sie länger weg, fragen Sie konkret nach, ob es an Ihrer PHP-Version liegt. Für PHP 8.1 und älter gibt es kein fertiges Update (siehe oben), dann hilft nur die Umstellung auf eine aktuelle Version. Wie andere Ursachen für einen Ausfall aussehen, zeigt der Beitrag Website nicht erreichbar.

Hilft etwas, bis das Update drauf ist?

Nur eingeschränkt. Weder das BSI noch das PHP-Projekt kennen einen Workaround, der zuverlässig schützt. Das PHP-Projekt nennt als Teilschutz Einstellungen, die vor allem große Formularanfragen und die Upload-Fortschrittsanzeige betreffen. Meine Empfehlung bis zum Update deshalb: PHP komplett von Uploads abschirmen. Formulare mit Datei-Anhang liest PHP ein, bevor WordPress oder der Shop überhaupt etwas davon mitbekommt. Uploads nur in der Website oder in den PHP-Einstellungen abzuschalten, reicht deshalb nicht. Solche Anfragen (Fachbegriff „multipart/form-data“) dürfen PHP gar nicht erst erreichen. Am besten fängt sie der Reverse Proxy ab, also der Server, der vor der eigentlichen Website sitzt und alle Anfragen entgegennimmt; ohne Proxy übernimmt das der Webserver selbst. Der Preis: Upload-Felder in Formularen und manche Shop-Kassen funktionieren solange nicht. Das sollte vorher jemand testen, der die Seite kennt.

Eine Web Application Firewall, also ein Filter vor der Website, kann Angriffe abfangen, sofern sie passende Regeln für diese Lücken hat. Wo das Update nicht kurzfristig eingespielt werden kann, rät das BSI, den Webserver vorübergehend vom Internet zu trennen. Für eine Firmenwebsite heißt das: lieber einen Tag eine Wartungsseite als eine gekaperte Seite, die wochenlang Spam verschickt.

Was jetzt zu tun ist

1. PHP-Version herausfinden, im Kundenbereich des Hosters oder in WordPress.
2. Bei Webhosting: beim Hoster nachsehen, ob er das Update (8.5.12, 8.4.27, 8.3.36 oder 8.2.35) eingespielt hat. Viele Anbieter melden so etwas auf ihrer Statusseite oder per Mail; steht dort nichts, fragen Sie nach.
3. Bei PHP 8.1 oder älter: den Hoster nach einer 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 und prüfen, ob die Distribution die Korrektur schon ausliefert. Bei Debian und Ubuntu kommt sie oft als Nachbesserung der alten Versionsnummer.
5. Danach auf Spuren prüfen, zurück bis zum 17. Oktober: unbekannte PHP-Dateien, neue Admin-Konten, geänderte Dateien im Theme. Das Update schließt nur die Lücke, eine bereits eingebaute Hintertür bleibt.

Wann es sich lohnt, das abzugeben

Websites auf meinen eigenen Servern bekommen das Update umgehend nach Erscheinen, dafür müssen Sie nichts tun.

Wenn Sie nicht wissen, auf welcher PHP-Version Ihre Seite läuft, wer den Server betreut oder ob der Hoster für Ihre Version noch etwas liefert, kostet die Klärung schnell mehr Zeit als das eigentliche Update. Läuft die Seite auf altem PHP, hebe ich sie mit dem PHP-Update auf eine Version mit Sicherheitsupdates, vorher in einer Testumgebung geprüft. Lief sie tagelang ungeschützt oder verhält sie sich merkwürdig, prüfe und bereinige ich sie bei der Soforthilfe für gehackte Websites. Und wer solche Tage künftig nicht selbst verfolgen will, gibt Updates und Überwachung an die Website-Pflege ab. Den Preis nenne ich vorab.