Wie Sie Ihre Webseite jetzt vor der PHP-Lücke PHP2Shell schützen

Zwei kritische Schwachstellen in PHP erlauben Angriffe ohne Passwort. Was Webseitenbetreiber:innen und Hersteller jetzt tun sollten.

Am 21. Oktober 2026 um 16 Uhr hat das PHP-Projekt Sicherheitsupdates für zwei Schwachstellen veröffentlicht. Das BSI hat schon vorab gewarnt, dass die Lücken Webanwendungen weltweit bedrohen. In Fachkreisen heißen sie „PHP2Shell“. Der Name erinnert bewusst an Log4Shell, jene Lücke, die Ende 2021 viele IT-Abteilungen um ihre Weihnachtsferien gebracht hat.

PHP ist eine Programmiersprache für Webanwendungen. Auf ihr laufen etwa WordPress, Shopware, WooCommerce und Magento. Betreibt Ihr Unternehmen eine Webseite oder einen Onlineshop, läuft mit hoher Wahrscheinlichkeit irgendwo PHP. Wir erklären, was Sie heute tun sollten und wann daraus eine rechtliche Meldepflicht wird.

Ein einziger manipulierter Seitenaufruf kann genügen

Die Schwachstellen tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Eine CVE-Nummer funktioniert wie ein Aktenzeichen für Sicherheitslücken. Beide Fehler stecken im Kern von PHP und betreffen den Umgang mit dem Arbeitsspeicher. PHP greift dabei auf Speicherbereiche zu, die halbfertig sind oder bereits wieder freigegeben wurden. Dort können inzwischen Daten liegen, die Angreifer:innen gezielt platziert haben.

Angreifer:innen schicken eine präparierte Anfrage an den Server und bringen ihn dazu, ihren Programmcode auszuführen. Ein Login ist dafür nicht nötig, ein Klick von Nutzer:innen auch nicht. Der Angriff greift, bevor der Code Ihrer eigentlichen Anwendung startet. Ein gut gepflegtes WordPress hilft deshalb nicht. Das PHP-Projekt bewertet beide Lücken mit 9,2 von 10 Punkten auf der CVSS-Skala, dem gängigen Maßstab für den Schweregrad, und damit als sehr kritisch.

Die Fehler liegen seit über einem Jahrzehnt im Code. Gefunden haben sie die Sicherheitsfirmen Calif und Wiz zusammen mit OpenAI, nach Angaben von Wiz mit entscheidender Hilfe von KI-Modellen. Das dürfte nicht das letzte Mal gewesen sein.

Angreifer:innen waren schneller als die Veröffentlichung

Details sind vor dem geplanten Termin durchgesickert. Amazon hat nach eigenen Angaben schon am 17. Oktober 2026 einen Angriffsversuch auf einen Köder-Server registriert, einen sogenannten Honeypot. Am Morgen des 21. Oktober meldete Cloudflare erste Angriffe. Gehen Sie davon aus, dass funktionierender Angriffscode im Umlauf ist.

Diese Schritte sollten Sie heute erledigen

Umsetzen kann das Ihre hausinterne IT oder Ihr Dienstleister. Als Geschäftsleitung sollten Sie aber wissen, wonach Sie fragen.

1. Verschaffen Sie sich einen Überblick, wo bei Ihnen PHP läuft. Denken Sie auch an Testumgebungen, vergessene Altprojekte und Geräte mit Weboberfläche.
2. Spielen Sie die Updates ein. Die bereinigten Versionen lauten 8.5.12, 8.4.27, 8.3.36 und 8.2.35, Linux-Distributionen nummerieren ihre Pakete teils anders. Starten Sie danach die PHP-Dienste neu.
3. Behandeln Sie alte PHP-Versionen gesondert. Für PHP 8.1 und älter gibt es keine offiziellen neuen Versionen, nur Quellcode-Korrekturen für 7.4 bis 8.1 und Backports einzelner Distributionen.
4. Nehmen Sie Systeme vom Netz, die Sie nicht zeitnah aktualisieren können. Das empfiehlt auch das britische National Cyber Security Centre. Kursierende Konfigurationsänderungen schließen nach Angaben von PHP nur einzelne Angriffswege.
5. Klären Sie beim Hosting, wer zuständig ist. Bei klassischem Webhosting aktualisiert in der Regel der Provider, bei eigenen Servern meist Sie selbst.
6. Suchen Sie nach Spuren eines Angriffs. Ein Update schließt die Tür, wirft aber niemanden hinaus, der schon drin ist. Ihre IT sollte die Protokolle ab dem 17. Oktober prüfen und nach versteckten Hintertüren suchen, sogenannten Webshells. Finden sich Hinweise, tauschen Sie alle Zugangsdaten und Schlüssel aus, die auf dem Server lagen.
7. Dokumentieren Sie, wann Sie von der Lücke erfahren und welche Systeme Sie wann aktualisiert haben. Auch falls keine Auffälligkeiten entdeckt wurden, sollte dies dokumentiert werden.

Wer personenbezogene Daten verarbeitet, muss auch rechtlich nachziehen

Art. 32 DSGVO verlangt Schutzmaßnahmen nach dem Stand der Technik. Eine bekannte kritische Lücke offen zu lassen, verträgt sich damit nicht. Haben Angreifer:innen Code auf einem Server ausgeführt, der personenbezogene Daten verarbeitet, müssen Sie prüfen, ob eine Verletzung des Schutzes personenbezogener Daten vorliegt (Art. 4 Nr. 12 DSGVO). Ist das der Fall, melden Sie sie binnen 72 Stunden der Aufsichtsbehörde, es sei denn, ein Risiko für die Betroffenen ist unwahrscheinlich (Art. 33 Abs. 1 DSGVO). Bei hohem Risiko müssen Sie zusätzlich die Betroffenen benachrichtigen (Art. 34 DSGVO).

Für wichtige und besonders wichtige Einrichtungen nach NIS-2 gilt nach den Vorgaben des BSI-Gesetzes zusätzlich § 32 Abs. 1 BSIG. Einen erheblichen Sicherheitsvorfall melden Sie spätestens 24 Stunden nach Kenntnis mit einer frühen Erstmeldung, nach 72 Stunden folgt eine Meldung mit erster Bewertung. Für die Umsetzung des Risikomanagements, zu dem auch das Patchen gehört, ist die Geschäftsleitung verantwortlich (§ 38 Abs. 1 BSIG).

Hersteller müssen prüfen, ob eine ausgenutzte Schwachstelle vorliegt

Seit dem 11. September 2026 gelten die Meldepflichten nach Art. 14 des Cyber Resilience Act (CRA). Sie treffen Hersteller von Produkten mit digitalen Elementen, also von Hard- und Software, die sie unter eigenem Namen in der EU vermarkten. Wer PHP lediglich auf dem eigenen Webserver einsetzt, unterliegt insoweit keinen Herstellerpflichten. Anders liegt es, wenn PHP in Ihrem Produkt steckt, etwa in Routern, Firewalls oder Speichersystemen mit Weboberfläche oder in Software, die Sie samt PHP-Laufzeit als Container-Image ausliefern. Erfasst sind auch Produkte, die schon vor dem Stichtag auf dem Markt waren (Art. 69 Abs. 3 CRA).

Diese Hersteller müssen jetzt prüfen, ob die Lücke in ihrem Produkt aktiv ausgenutzt wird. Das setzt verlässliche Nachweise voraus, dass jemand die Schwachstelle böswillig und ohne Erlaubnis der Betreiber:innen eines Systems ausgenutzt hat (Art. 3 Nr. 42 CRA). Ein veröffentlichter Exploit genügt dafür nach Auffassung des BSI nicht. Angriffe auf fremde Produkte mit derselben Komponente lösen nach Auffassung der Kommission keine eigene Meldepflicht aus, sind aber Anlass zur sofortigen Prüfung. Wie Sie eine ausgenutzte Schwachstelle von einem schwerwiegenden Sicherheitsvorfall abgrenzen, erläutern wir im Beitrag „Wie Hersteller ausgenutzte Schwachstellen und Sicherheitsvorfälle nach dem CRA unterscheiden“.

Haben Sie nach einer unverzüglichen Erstbewertung hinreichende Gewissheit, dass Ihr Produkt angegriffen wurde, laufen die Fristen. Binnen 24 Stunden ist eine Frühwarnung an das BSI als koordinierendes CSIRT und an die ENISA fällig, binnen 72 Stunden die eigentliche Meldung. Außerdem müssen Sie die betroffenen Nutzer:innen informieren (Art. 14 Abs. 8 CRA). Den Ablauf im Einzelnen beschreibt unser Beitrag „Cyber Resilience Act – Die Meldepflichten“.

Wer heute patcht und dokumentiert, steht morgen besser da

Für die meisten Unternehmen heißt PHP2Shell vor allem, sofort zu patchen und nach Angriffsspuren zu suchen. Je nach Lage greifen Meldepflichten nach DSGVO, BSI-Gesetz (NIS-2) und CRA nebeneinander, jede mit eigenen Fristen. Hersteller sollten so schnell wie möglich dokumentieren, wann sie welche Hinweise erhalten und wie sie diese bewertet haben. Wenn Sie unsicher sind, ob Sie melden müssen, unterstützen wir Sie gern. Für akute Fälle erreichen Sie uns über unseren Cyber-Notfall-Kontakt.