PHP-Alarm vom 21. Oktober: Ist das schon eine Datenpanne gemäß DSGVO?

Zwei Lücken, fast jede Webseite

Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßige Sicherheitsupdates veröffentlicht. Sie schließen zwei Lücken im Kern der Programmiersprache, geführt unter den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide erlauben es einem Angreifer, ohne Anmeldung eigenen Code auf dem Webserver auszuführen, im schlimmsten Fall mit einer einzigen präparierten Anfrage, bevor die eigentliche Webanwendung überhaupt startet. Wer das schafft, kann Daten auslesen, Dateien verändern und sich dauerhaft einnisten. Das PHP-Sicherheitsteam bewertet beide Lücken mit 9,2 von 10 Punkten als kritisch.

Die Tragweite ergibt sich aus der Verbreitung. Nach den Zählungen von W3Techs läuft PHP auf gut 69 Prozent aller Webseiten, deren Servertechnik bekannt ist. Dazu gehören die verbreiteten Content-Management-Systeme und viele Shopsysteme. Betroffen ist deshalb fast jedes Unternehmen mit eigener Webseite, auch wenn dort niemand weiß, dass im Hintergrund PHP arbeitet. Die Fehler stecken in Codeteilen, die seit mehr als zehn Jahren bestehen; nach Angaben der Entdecker ist jede PHP-Version seit 5.4 von mindestens einer der beiden Lücken betroffen.

Update ist da, aber nicht überall

Sicherheitsforscher hatten die Lücken im August 2026 an das PHP-Projekt gemeldet. Weil am 20. Oktober erste Details durchsickerten, zog das Projekt die geplante Veröffentlichung um einen Tag auf den 21. Oktober, 16 Uhr deutscher Zeit, vor. Sicher sind seitdem die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und ältere Versionen liefert das Projekt keine fertigen Updates mehr, nur Quellcode-Korrekturen; einige Linux-Distributionen bieten eigene Pakete an. Nach W3Techs läuft mehr als ein Drittel aller PHP-Webseiten noch mit PHP 7 oder 5. Für sie bleibt häufig nur der Umstieg auf eine neuere Version.

Die Lage ist ernst. Ein großer Anbieter von Netzwerkdiensten meldete schon am Vormittag des 21. Oktober erste Angriffsversuche. Das Bundesamt für Sicherheit in der Informationstechnik rät, die Updates unverzüglich einzuspielen, und das IT-Notfallteam der EU-Institutionen empfiehlt, Systeme vom Internet zu trennen, bis das Update installiert ist. Die Übergangseinstellungen, die im Netz kursieren, machen eine Installation nach Angaben des PHP-Projekts nicht sicher.

Sicherheitslücke ist keine Datenpanne

Für den Datenschutz stellt sich zuerst eine Frage: Muss ein Unternehmen die Lücke der Aufsichtsbehörde melden? In den meisten Fällen nein, jedenfalls nicht wegen der Lücke allein. Die DSGVO versteht unter einer Datenschutzverletzung, umgangssprachlich Datenpanne, eine Verletzung der Sicherheit, die dazu geführt hat, dass personenbezogene Daten vernichtet, verloren, verändert, unbefugt offengelegt oder unbefugt abgerufen wurden. Es kommt also darauf an, dass mit den Daten etwas geschehen ist.

Eine offene Tür ist noch kein Einbruch. Solange niemand die Lücke genutzt hat, liegt ein Sicherheitsvorfall vor, aber keine Datenpanne. Der Europäische Datenschutzausschuss sagt das in seinen Leitlinien zur Meldung von Datenschutzverletzungen ausdrücklich: Jede Datenpanne ist ein Sicherheitsvorfall, aber nicht jeder Sicherheitsvorfall ist eine Datenpanne. Er bringt sogar ein passendes Beispiel. Ein Hoster entdeckt einen Fehler, durch den jeder Nutzer die Kontodaten anderer Nutzer sehen könnte. Gibt es keine Hinweise, dass jemand den Fehler genutzt hat, ist eine meldepflichtige Panne wohl nicht eingetreten. Der Vorfall gehört trotzdem in die interne Dokumentation, und er kann ein Verstoß gegen die Pflicht zu angemessener Sicherheit sein, wenn das Unternehmen die Lücke nicht zügig schließt.

Betroffenheit prüfen und Lücke schließen

Prüfen Sie als Erstes über Ihre eigene IT, intern oder beim Dienstleister, ob Ihre Systeme von der Lücke betroffen sind und ob jemand sie bereits genutzt hat. Haben Sie einen Datenschutzbeauftragten, binden Sie ihn bereits in diese Prüfung ein; die DSGVO verlangt seine frühzeitige Beteiligung bei allen Fragen des Datenschutzes. Hinweise liefern Ihnen die Protokolle des Webservers, ungewöhnliche Anfragen, unbekannte Dateien im Webverzeichnis, neue Benutzerkonten und Mitteilungen Ihres Hosters. Die Entdecker der Lücke warnen, dass die Angriffe unterhalb der Anwendung ablaufen und in den üblichen Anwendungsprotokollen wenig Spuren hinterlassen. Beziehen Sie deshalb Ihren Hoster ein, der Zugriff auf die Serverprotokolle hat. Ein IT-Forensiker lohnt sich erst bei größeren Systemen oder einem konkreten Verdacht.

Parallel dazu müssen Sie die Lücke als Sofortmaßnahme umgehend schließen. Betreiben Sie Ihre Webseite bei einem Webhosting-Anbieter, fragen Sie dort nach, ob die neue PHP-Version eingespielt ist, und lassen Sie sich das bestätigen. Betreiben Sie einen eigenen Server, aktualisieren Sie selbst oder beauftragen Sie Ihren Dienstleister. Dafür brauchen Sie eine Liste aller Systeme, auf denen PHP läuft: Webseite, Shop, Kundenportal, Intranet, Testumgebungen und Erweiterungen, die PHP mitbringen. 

Datenschutzverletzung festgestellt, Frist im Blick

Stellt sich heraus, dass jemand die Lücke genutzt hat, bewerten Sie die Lage gemeinsam mit Ihrem Datenschutzbeauftragten. Haben Sie keinen benannt, ziehen Sie jetzt einen auf Datenschutzrecht spezialisierten Rechtsanwalt hinzu. Denn mit dem Zugriff ist eine Datenschutzverletzung eingetreten, und es gelten die Pflichten aus Artikel 33 und 34 DSGVO. Eine solche Verletzung müssen Sie in jedem Fall intern dokumentieren: was passiert ist, welche Daten betroffen sind, welche Folgen das haben kann und was Sie dagegen unternommen haben. Melden müssen Sie zudem eine Datenschutzverletzung der Datenschutzaufsichtsbehörde binnen 72 Stunden, es sei denn, ein Risiko für die betroffenen Personen ist unwahrscheinlich. Bei voraussichtlich hohem Risiko benachrichtigen Sie zusätzlich die Betroffenen. Wie hoch das Risiko ist, hängt von Art und Menge der Daten ab: Kontaktdaten aus einem Newsletter-Formular wiegen weniger als Zahlungsdaten, Gesundheitsangaben, Zugangsdaten oder Bewerbungsunterlagen, und zehntausend Kunden wiegen mehr als zehn. Lassen Sie sich auf jeden Fall zur Frage der Meldepflicht fachkundigt beraten.

Die 72 Stunden laufen ab dem Zeitpunkt, zu dem Sie hinreichend sicher wissen, dass Daten betroffen sind. Der Europäische Datenschutzausschuss räumt Ihnen eine kurze Untersuchung ein, bevor die Frist beginnt, verlangt aber, dass Sie sofort damit anfangen. Verschleppen Sie die Prüfung, riskieren Sie, dass die Behörde Ihre Meldung später als verspätet wertet. Und entscheiden Sie sich gegen eine Meldung, halten Sie auch das fest: welche Systeme Sie geprüft haben, wann, durch wen und mit welchem Ergebnis. Diese Notiz belegt, dass Sie auf die Schwachstelle angemessen reagiert haben; liegt eine Datenpanne vor, gehört sie zusätzlich in Ihr Verzeichnis der Datenschutzverletzungen.

Hoster meldet, Unternehmen haftet

Lassen Sie Ihre Webseite bei einem Hoster betreiben, haben Sie rechtlich einen Auftragsverarbeiter: Der Hoster verarbeitet die Daten in Ihrem Auftrag, Verantwortlicher bleiben Sie. Stellt der Hoster fest, dass auf seinen Servern Daten abgeflossen sind, muss er Sie unverzüglich informieren. Mit dieser Information gelten Sie als wissend, und die oben genannte 72 Stunden-Frist beginnt spätestens hiermit. 

Die Meldung an die Datenschutzaufsichtsbehörde bleibt Aufgabe Ihres Unternehmens, ebenso die Entscheidung, ob Sie die betroffenen Personen benachrichtigen. Bleibt eine Mitteilung des Hosters aus, entbindet Sie das nicht von Ihren Pflichten. Holen Sie deshalb jetzt gezielt Auskunft ein: Welche PHP-Version ist im Einsatz, seit wann ist das Update eingespielt, gab es auffällige Zugriffe? Die Antworten nehmen Sie in Ihre Dokumentation auf.