PHP2Shell · Meldepflicht
PHP2Shell: Wann die PHP-Lücke zur meldepflichtigen Datenpanne wird
Seit dem 21. Oktober gibt es Patches für zwei kritische PHP-Lücken. Damit ist die IT-Seite klar. Die Frage danach beantwortet kaum jemand: Müssen Sie den Vorfall der Aufsichtsbehörde melden – und ab wann läuft Ihre Frist?
Was PHP2Shell ist
Am 21. Oktober 2026 hat das PHP-Team außerplanmäßige Sicherheitsupdates veröffentlicht. Dahinter stehen zwei Schwachstellen, die seit dem Vortag unter dem Namen PHP2Shell kursieren – in Anlehnung an Log4Shell:
- CVE-2026-109618 – ein Speicherfehler, der auftritt, wenn der Arbeitsspeicher erschöpft ist, während Anfragedaten noch nicht vollständig initialisiert sind.
- CVE-2026-109619 – Zustandsdaten einer Anfrage bleiben in einem dauerhaft laufenden Worker-Prozess liegen und können von einer späteren Anfrage genutzt werden.
Beide bewertet das PHP-Team nach CVSS v4.0 mit 9,2 von 10. Beide lassen sich ohne Anmeldung und ohne Zutun eines Nutzers allein über das Netz ausnutzen. Wer das schafft, führt eigenen Code auf dem Webserver aus – und erreicht damit grundsätzlich alles, was die Anwendung dort verarbeitet: Formulareingaben, Bestelldaten, Kundenkonten, Datenbankzugänge.
Das BSI hat am selben Tag eine Cybersicherheitswarnung dazu veröffentlicht. Wichtig für die Einordnung: Die Lücken stecken in PHP selbst, nicht in einer bestimmten Anwendung. Ein Update von WordPress, Shopware, Joomla oder TYPO3 allein genügt also nicht.
| PHP-Zweig | Betroffen | Behoben in |
|---|---|---|
| 8.5.x | vor 8.5.12 | 8.5.12 |
| 8.4.x | vor 8.4.27 | 8.4.27 |
| 8.3.x | vor 8.3.36 | 8.3.36 |
| 8.2.x | vor 8.2.35 | 8.2.35 |
| 8.1 und älter | End of Life | keine regulären Updates |
Betroffen sind alle Betriebsarten, die Webanfragen verarbeiten – PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed. Am höchsten ist das Risiko bei mod_php, weil ein Angriff dort greifen kann, bevor überhaupt Anwendungscode läuft. CERT-EU hält alle Versionen ab PHP 5 für möglicherweise betroffen.
Wichtig zur Einordnung: Zur Frage, ob die Lücken bereits ausgenutzt werden, gehen die Quellen auseinander. Das BSI schreibt in seiner Warnung vom 21.10.2026 (Version 1.1), es seien keine bestätigten Ausnutzungen bekannt, es gebe aber unbestätigte Berichte über existierende Exploits. Der Sicherheitsanbieter watchTowr meldet dagegen aktive Angriffsversuche gegen beide CVEs, und bei Patchstack meldeten mehrere Hoster bereits am Vormittag des 21.10. – also vor der Veröffentlichung der Patches um 16 Uhr – entsprechende Angriffe. Wir geben beides so wieder, wie es ist: Es gibt belastbare Hinweise auf Angriffsversuche, aber keine offiziell bestätigte erfolgreiche Ausnutzung. Für Ihre Risikobewertung heißt das: nicht in Panik verfallen, aber auch nicht davon ausgehen, dass nichts passiert sein kann.
Warum das auf Ihrem Schreibtisch landet und nicht nur beim Hoster
Die naheliegende Reaktion ist, die Sache an die IT oder den Hoster zu geben: Patch einspielen, fertig. Das ist richtig und notwendig – aber es ist nur die halbe Aufgabe.
Denn eine Lücke, die Codeausführung auf dem Webserver erlaubt, ist aus Datenschutzsicht keine technische Randnotiz. Sie betrifft unmittelbar die Schutzziele, zu denen Artikel 32 DSGVO Sie verpflichtet: Vertraulichkeit, Integrität und Verfügbarkeit der Daten, die Sie verarbeiten. Läuft über Ihre Website ein Kontaktformular, ein Bewerbungsportal, ein Kundenkonto oder ein Shop, dann liegen dort personenbezogene Daten – und für die sind Sie als Verantwortlicher zuständig, nicht Ihr Dienstleister.
Zwei Dinge folgen daraus. Erstens: Dass Sie die Lücke zügig geschlossen haben, gehört dokumentiert – es ist der Nachweis, dass Ihre technischen und organisatorischen Maßnahmen funktionieren. Zweitens, und das wird häufiger übersehen: Sie müssen beantworten, ob in der Zeit vor dem Patch etwas passiert ist. Und wenn ja, ob daraus eine meldepflichtige Verletzung des Schutzes personenbezogener Daten geworden ist.
Die eigentliche Frage: liegt eine meldepflichtige Verletzung vor?
Artikel 4 Nummer 12 DSGVO beschreibt eine Verletzung des Schutzes personenbezogener Daten als eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von oder zum unbefugten Zugang zu personenbezogenen Daten führt. In der Praxis landen Unternehmen bei PHP2Shell in einem von drei Fällen.
Fall 1: Gepatcht, keine Anzeichen für einen Zugriff
Sie haben aktualisiert, die Logs geprüft, keine fremden Dateien, keine unbekannten Prozesse, keine neuen Konten gefunden. Dann liegt nach aller Wahrscheinlichkeit keine Verletzung vor – es gab eine Schwachstelle, aber keinen Vorfall. Wichtig ist trotzdem: Halten Sie schriftlich fest, was Sie geprüft haben, wann und mit welchem Ergebnis. Wer später gefragt wird, warum nicht gemeldet wurde, braucht genau diese Aufzeichnung.
Fall 2: Es gibt Anzeichen für eine Kompromittierung
Eine unbekannte PHP-Datei im Upload-Verzeichnis, ein Cronjob, den niemand angelegt hat, ein neues Administratorkonto, auffälliger ausgehender Datenverkehr. Dann ist der Zugriff auf die Daten der Anwendung in aller Regel nicht mehr auszuschließen – und damit liegt eine Verletzung im Sinne des Artikel 4 Nummer 12 vor, auch wenn Sie keinen konkreten Datenabfluss nachweisen können. Der Artikel verlangt keinen Nachweis, dass Daten abgeflossen sind, sondern knüpft bereits am unbefugten Zugang an.
Fall 3: Sie wissen es nicht, weil die Logs fehlen
Das ist der unangenehmste und zugleich häufigste Fall im Mittelstand. Die Zugriffsprotokolle reichen nur sieben Tage zurück, es gibt keine Dateiintegritätsprüfung, der Server wurde beim Patchen gleich neu gestartet. Dann lässt sich nachträglich kaum noch feststellen, ob etwas passiert ist.
„Wir wissen es nicht“ ist in dieser Lage kein Argument gegen eine Meldung – es ist umgekehrt genau der Grund, warum Aufsichtsbehörden in Zweifelsfällen eine Meldung erwarten. Die Entscheidung gehört dokumentiert und begründet, in beide Richtungen.
Rechtlicher Hinweis: Dieser Beitrag beschreibt die Systematik der Meldepflichten allgemein und ersetzt keine Rechtsberatung im Einzelfall. Ob in Ihrem konkreten Fall eine meldepflichtige Verletzung vorliegt, hängt von den Umständen ab – welche Daten betroffen sind, was die Protokolle hergeben, welche Maßnahmen gegriffen haben. Genau diese Prüfung machen wir mit Ihnen, bevor eine Frist abläuft.
Die 72 Stunden laufen ab Kenntnis – nicht ab dem Patch
Artikel 33 Absatz 1 DSGVO sieht vor, dass eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde gemeldet wird – es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Entscheidend ist der Zeitpunkt, zu dem Sie hinreichende Kenntnis vom Vorfall erlangen, nicht der Zeitpunkt des Patches und nicht der Abschluss Ihrer Analyse.
Zwei Punkte, die in der Praxis immer wieder für Ärger sorgen:
- Die Dokumentationspflicht gilt immer. Artikel 33 Absatz 5 verlangt, alle Verletzungen zu dokumentieren – auch die, die Sie nach eigener Bewertung nicht melden. Diese Dokumentation muss der Aufsichtsbehörde die Überprüfung Ihrer Entscheidung ermöglichen.
- Eine Meldung kann nachgereicht werden. Liegen nach 72 Stunden noch nicht alle Informationen vor, ist das kein Grund zu warten. Artikel 33 Absatz 4 lässt eine schrittweise Meldung ausdrücklich zu.
Kommt bei hohem Risiko für die Betroffenen hinzu: Nach Artikel 34 DSGVO sind dann auch die betroffenen Personen zu benachrichtigen – bei einem Shop also potenziell Ihre Kundinnen und Kunden.
Für NIS-2-pflichtige Unternehmen gelten kürzere Fristen
Fallen Sie als wichtige oder besonders wichtige Einrichtung unter NIS-2, kommt eine zweite Meldelinie dazu – mit einer deutlich schärferen Uhr: eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden und ein Abschlussbericht binnen eines Monats. Beide Pflichten laufen nebeneinander und gehen an verschiedene Stellen. Wer unsicher ist, ob das eigene Unternehmen betroffen ist, kann das mit unserem NIS-2-Betroffenheitscheck in zwei Minuten einordnen – und die Einschätzung passt gut zu dem, was wir zur angekündigten Durchsetzungsinitiative des BSI geschrieben haben.
Bevor Sie aufräumen: Spuren sichern
Der häufigste Fehler in den ersten Stunden ist gut gemeint: Server patchen, Dienste neu starten, verdächtige Dateien löschen, weitermachen. Damit ist die Lücke zu – und die Grundlage für jede spätere Bewertung gleich mit beseitigt.
Sichern Sie deshalb vor der Bereinigung, was Sie später brauchen: Zugriffs- und Fehlerprotokolle des Webservers, die PHP-Konfiguration, verdächtige Dateien im Original, den Zeitpunkt der letzten bekannten sauberen Sicherung. Das ist derselbe Reflex, den auch watchTowr an erste Stelle seiner Empfehlungen setzt – und es ist der Unterschied zwischen einer Meldung, die Hand und Fuß hat, und einer, in der Sie der Behörde schreiben müssen, dass sich der Sachverhalt nicht mehr aufklären lässt.
Fünf Schritte, in dieser Reihenfolge
- PHP-Bestand erfassen. Alle Installationen, die Webanfragen verarbeiten – inklusive Testumgebungen, Containern, Altprojekten und Systemen, an die seit Jahren niemand gedacht hat. Was Sie nicht auf der Liste haben, patchen Sie auch nicht.
- Spuren sichern, dann patchen. Protokolle und auffällige Dateien wegsichern, anschließend auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren und die PHP-Worker neu starten. Bei Managed Hosting nach dem Zeitplan des Anbieters fragen – und sich die Bestätigung schriftlich geben lassen.
- Auf Kompromittierung prüfen. Unbekannte Dateien in beschreibbaren Verzeichnissen, neue Cronjobs, neu angelegte Konten, ungewöhnliche ausgehende Verbindungen. Im Zweifel IT-Forensik hinzuziehen, bevor weiter aufgeräumt wird.
- Datenschutzrechtlich bewerten. Welche personenbezogenen Daten verarbeitet die betroffene Anwendung? Was sagen die Protokolle? Daraus folgt die Entscheidung über die Meldung – und die gehört in beide Richtungen begründet und datiert ins Verzeichnis der Datenschutzverletzungen.
- Altsysteme einplanen. PHP 8.1 und älter bekommt keine regulären Updates mehr. Wer dort noch produktiv läuft, braucht einen Termin für die Migration – und bis dahin eine Abschottung vom offenen Netz. Ein bekanntes, offenes Risiko ohne Plan ist für sich genommen schon ein Problem mit Artikel 32.
Als Übergangslösung nennt das PHP-Team memory_limit=-1 gegen CVE-2026-109618 und session.upload_progress.enabled=0 gegen CVE-2026-109619, betont aber ausdrücklich, dass das keine Installation sicher macht. Von inoffiziellen „Fix“-Plugins und kopierten Code-Schnipseln raten alle Quellen ab, die wir gesichtet haben.
Wie groß ist das Ganze?
Eine belastbare Zahl kompromittierter Systeme gibt es nicht, und wer sie nennt, rät. Was es gibt, sind Größenordnungen: PHP läuft nach Erhebungen von Mitte 2026 auf rund 70 Prozent aller Websites, deren serverseitige Sprache bekannt ist; WordPress allein kommt auf über 40 Prozent aller Websites. Eine Auswertung von Shodan-Bannern vom 20. Oktober 2026 zählte rund 884.000 erreichbare Hosts mit einer End-of-Life-PHP-Version – etwa 59 Prozent der rund 1,5 Millionen Hosts, die ihre Version überhaupt preisgeben; weitere rund 740.000 verbergen sie.
Diese Zahlen sagen nichts darüber aus, wie viele Systeme tatsächlich angegriffen wurden. Sie sagen etwas anderes: Die Angriffsfläche ist groß genug, dass sich automatisierte Scans lohnen. Und automatisierte Scans unterscheiden nicht zwischen einem Konzern und einem Handwerksbetrieb mit 30 Beschäftigten.
Häufige Fragen
Muss ich PHP2Shell der Aufsichtsbehörde melden?
Die Schwachstelle selbst ist kein meldepflichtiger Vorfall. Meldepflichtig wird es erst, wenn es Anzeichen dafür gibt, dass jemand sie bei Ihnen ausgenutzt hat – oder wenn sich das mangels Protokollen nicht ausschließen lässt und ein Risiko für die betroffenen Personen besteht. Entscheidend ist also nicht die Lücke, sondern was auf Ihrem Server passiert ist.
Ab wann laufen die 72 Stunden?
Ab dem Zeitpunkt, zu dem Sie hinreichende Kenntnis von der Verletzung erlangen – nicht ab Veröffentlichung der Lücke und nicht ab Abschluss Ihrer Untersuchung. Wer am Freitagnachmittag eine fremde Datei auf dem Webserver findet, hat die Uhr damit gestartet. Liegen nach 72 Stunden noch nicht alle Informationen vor, kann schrittweise gemeldet werden.
Mein Hoster sagt, es sei alles gepatcht. Reicht das?
Für die Schwachstelle ja, für Ihre Nachweispflicht nicht ganz. Lassen Sie sich schriftlich bestätigen, welche Systeme wann auf welche Version aktualisiert wurden, und ob der Hoster Auffälligkeiten festgestellt hat. Verantwortlich für die Bewertung bleiben Sie – ein Auftragsverarbeiter muss Ihnen nach Artikel 33 Absatz 2 DSGVO eine Verletzung unverzüglich melden, die Entscheidung über die Meldung an die Behörde trifft er aber nicht.
Wir nutzen noch PHP 8.1 oder älter. Was jetzt?
Diese Zweige bekommen keine regulären Sicherheitsupdates mehr. Prüfen Sie, ob Ihre Linux-Distribution einen Backport bereitstellt – viele Distributionen korrigieren, ohne die Versionsnummer zu ändern. Wenn nicht, bleibt kurzfristig nur, das System vom offenen Netz zu nehmen oder nur über VPN erreichbar zu machen, und mittelfristig die Migration auf einen unterstützten Zweig.
Müssen wir unsere Kunden informieren?
Nach Artikel 34 DSGVO nur dann, wenn die Verletzung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der Betroffenen mit sich bringt. Bei einem Shop mit Bestell- und Zahlungsdaten liegt das näher als bei einer reinen Visitenkartenseite. Die Bewertung ist Einzelfallarbeit und sollte dokumentiert werden – auch wenn sie am Ende gegen eine Benachrichtigung ausfällt.
Wurde die Lücke wirklich mit KI gefunden?
Das BSI verweist in seiner Warnung auf Beiträge von Wiz.io und Calif.io, die gemeinsam mit OpenAI an der Entdeckung beteiligt waren. Mehr lässt sich daraus seriös nicht ableiten. Praktisch relevanter ist ein anderer Punkt der Chronologie: Details sickerten am 20. Oktober vor der abgestimmten Veröffentlichung durch, woraufhin das PHP-Team die Patches um einen Tag vorzog.
Quellen
- BSI: Cybersicherheitswarnung zu kritischen PHP-Schwachstellen, 21.10.2026, Version 1.1
- watchTowr Labs: PHP Remote Code Execution – PHP2Shell, Oktober 2026
- Greenbone: PHP2Shell – Schwachstelle patchen, Oktober 2026
- Deutschland sicher im Netz: PHP2Shell gefährdet Webseiten und Onlineshops, 21.10.2026
- Dr. Web: Hoster melden Angriffe vor dem Update, 21.10.2026
Unsicher, ob Sie melden müssen? Wir prüfen es mit Ihnen.
Die 72 Stunden laufen ab dem Moment, in dem Sie es wissen. Rufen Sie an, bevor die Frist arbeitet – wir sortieren den Sachverhalt, bewerten das Risiko und halten die Entscheidung so fest, dass sie einer Nachfrage standhält.