Kritische PHP-Schwachstellen am 21. Oktober 2026: Was Unternehmen aus Compliance-Sicht jetzt beachten müssen

Sicherheitsupdates, Meldepflichten und Risikomanagement: Wie Unternehmen auf die kritischen PHP-Schwachstellen reagieren und ihre Compliance-Pflichten belastbar prüfen.

Stand: 21. Oktober 2026

1. Ausgangslage: Kritische Sicherheitslücken in PHP

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht: CVE-2026-109618 und CVE-2026-109619. Beide wurden mit CVSS 4.0 mit 9,2 von 10 Punkten bewertet. Nach Angaben des PHP-Projekts können die Schwachstellen unter bestimmten Voraussetzungen eine unauthentifizierte Remote Code Execution ermöglichen, also die Ausführung von Schadcode ohne vorherige Anmeldung.

Betroffen sein können PHP-Installationen, die Webanfragen verarbeiten. Das PHP-Projekt nennt unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Als besonders hoch bewertet das Projekt das Risiko bei Apache mit mod_php, für das ein Exploit demonstriert wurde, der bereits vor der Ausführung des Anwendungscodes ansetzen kann.

Das PHP-Projekt hat folgende Sicherheitsversionen veröffentlicht:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Das Projekt empfiehlt dringend, betroffene Installationen unverzüglich zu aktualisieren. Es weist ausdrücklich darauf hin, dass keine vollständigen alternativen Schutzmaßnahmen zur Verfügung stehen.

Primärquelle: Offizielle PHP-Sicherheitsankündigung vom 21. Oktober 2026.

Für Unternehmen ergibt sich daraus unmittelbarer technischer Handlungsbedarf. Die Compliance-Frage geht jedoch über die Installation eines Updates hinaus: Es muss geprüft werden, welche Systeme betroffen sind, welche Risiken bestehen, ob ein Sicherheitsvorfall vorliegt und ob gesetzliche oder vertragliche Informations- und Meldepflichten ausgelöst werden.

2. Die zentrale Compliance-Frage: Schwachstelle oder Sicherheitsvorfall?

Eine kritische Schwachstelle ist nicht automatisch ein meldepflichtiger Sicherheitsvorfall.

Für eine sachgerechte Bewertung müssen drei Sachverhalte unterschieden werden:

Erstens: Eine Schwachstelle ist vorhanden. Eine betroffene PHP-Version wird eingesetzt, aber es liegen keine konkreten Hinweise auf einen Angriff vor. Das begründet dringenden Handlungsbedarf im Schwachstellenmanagement. Eine externe Meldung folgt daraus nicht automatisch.

Zweitens: Eine Ausnutzung wird vermutet oder untersucht. Es gibt beispielsweise auffällige Protokolleinträge, ungewöhnliche Prozesse oder Hinweise auf unberechtigte Zugriffe. Jetzt muss der Incident-Response-Prozess aktiviert und geprüft werden, ob bereits ein meldepflichtiger Vorfall vorliegt. Ein abschließender Nachweis sämtlicher Auswirkungen muss nicht in jedem Fall abgewartet werden, bevor gesetzliche Fristen zu laufen beginnen.

Drittens: Ein Sicherheitsvorfall ist eingetreten. Ein Angreifer hat beispielsweise Schadcode ausgeführt, Systeme kompromittiert oder Daten unbefugt abgerufen beziehungsweise verändert. In diesem Fall sind die Auswirkungen, die betroffenen Dienste und Daten sowie die einschlägigen gesetzlichen und vertraglichen Meldepflichten unverzüglich zu bewerten.

Entscheidend ist stets das jeweils anwendbare Regelwerk. Insbesondere NIS2 beziehungsweise das deutsche Umsetzungsgesetz, die DSGVO und der Cyber Resilience Act verfolgen unterschiedliche Zwecke und haben unterschiedliche Voraussetzungen für Meldepflichten.

3. NIS2 und das deutsche BSIG: Wann ist eine Meldung erforderlich?

Das deutsche NIS2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten. Die Anforderungen des neuen BSI-Gesetzes gelten für die jeweils erfassten Einrichtungen und Sachverhalte. Ob eine Organisation darunter fällt, muss anhand ihrer Tätigkeiten, ihres Status, ihrer Größe und der einschlägigen gesetzlichen Ausnahmen geprüft werden.

Für besonders wichtige und wichtige Einrichtungen enthält § 32 BSIG ein gestuftes Meldeverfahren für erhebliche Sicherheitsvorfälle.

Welche Fristen gelten?

Zeitpunkt	Gesetzliche Anforderung
Unverzüglich, spätestens 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls	Frühe Erstmeldung mit den gesetzlich vorgesehenen Angaben, insbesondere zur möglichen rechtswidrigen oder böswilligen Ursache und zu grenzüberschreitenden Auswirkungen
Unverzüglich, spätestens 72 Stunden nach Kenntnis	Meldung mit aktualisierten Informationen und einer ersten Bewertung von Schweregrad und Auswirkungen; gegebenenfalls einschließlich Kompromittierungsindikatoren
Auf Ersuchen des BSI	Zwischenmeldung zu relevanten Statusänderungen
Grundsätzlich spätestens einen Monat nach Übermittlung der 72-Stunden-Meldung	Abschlussmeldung mit ausführlicher Beschreibung, wahrscheinlicher Ursache, Abhilfemaßnahmen und gegebenenfalls grenzüberschreitenden Auswirkungen

Dauert der Sicherheitsvorfall zum Zeitpunkt der vorgesehenen Abschlussmeldung noch an, ist stattdessen eine Fortschrittsmeldung vorzulegen. Die Abschlussmeldung folgt nach der abschließenden Bearbeitung des Vorfalls.

Wichtig ist die gesetzliche Einschränkung in § 32 BSIG: Die dort geregelte Meldepflicht gilt frühestens ab Einrichtung des vorgesehenen Meldewegs. Für einen konkreten Fall ist deshalb auch das aktuell verfügbare offizielle Meldeverfahren zu prüfen.

Rechtsquelle: § 32 BSIG – Meldepflichten.

Was bedeutet das für die PHP-Schwachstellen?

Die Veröffentlichung einer kritischen PHP-Sicherheitswarnung löst für sich genommen nicht automatisch eine NIS2-Meldung aus. Es muss festgestellt werden, ob die Organisation betroffen ist und ob ein erheblicher Sicherheitsvorfall im Sinne der gesetzlichen Definition vorliegt.

Dabei dürfen die möglichen Auswirkungen nicht ausgeblendet werden: Die Bewertung muss auch die gesetzlich relevanten erheblichen Auswirkungen auf Dienste und andere Personen berücksichtigen. Ein Unternehmen sollte deshalb nicht allein deshalb von einer Meldepflicht absehen, weil noch kein bestätigter finanzieller Schaden oder vollständiger Produktionsausfall vorliegt.

Die technische Untersuchung und die rechtliche Bewertung sollten parallel erfolgen. Ist ein meldepflichtiger Vorfall bekannt geworden, darf die Fristprüfung nicht bis zum Abschluss einer umfassenden forensischen Untersuchung aufgeschoben werden.

Zusätzlich sind gegebenenfalls besondere Anforderungen für Betreiber kritischer Anlagen und branchenspezifische Regelungen zu prüfen.

4. DSGVO: Wann muss die Datenschutzaufsichtsbehörde informiert werden?

Eine PHP-Schwachstelle kann den unbefugten Zugriff auf personenbezogene Daten ermöglichen. Beispiele sind Kundenkonten, Kontaktdaten, Mitarbeiterinformationen oder andere personenbezogene Datensätze.

Allerdings ist zwischen einer Sicherheitslücke und einer Verletzung des Schutzes personenbezogener Daten im Sinne der DSGVO zu unterscheiden. Die Datenschutzpflichten hängen davon ab, ob tatsächlich eine Verletzung der Sicherheit personenbezogener Daten eingetreten ist und welche Risiken daraus entstehen.

Meldung nach Art. 33 DSGVO

Der Verantwortliche muss eine Datenschutzverletzung grundsätzlich unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde melden, sofern nicht voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen besteht.

Kann die Meldung nicht innerhalb von 72 Stunden erfolgen, müssen die Gründe für die Verzögerung angegeben werden.

Benachrichtigung betroffener Personen nach Art. 34 DSGVO

Besteht voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen, müssen die betroffenen Personen grundsätzlich unverzüglich informiert werden. Dabei sind die gesetzlichen Ausnahmen und Voraussetzungen zu beachten.

Dokumentation nach Art. 33 Abs. 5 DSGVO

Der Verantwortliche muss Datenschutzverletzungen dokumentieren. Die Dokumentation umfasst die mit der Verletzung zusammenhängenden Fakten, ihre Auswirkungen und die ergriffenen Abhilfemaßnahmen. Sie muss der Aufsichtsbehörde ermöglichen, die Einhaltung der gesetzlichen Anforderungen zu überprüfen.

Pflichten von Auftragsverarbeitern

Auch die Rolle externer IT-Dienstleister ist zu berücksichtigen. Wird eine Datenschutzverletzung bei einem Auftragsverarbeiter bekannt, muss dieser den Verantwortlichen nach Art. 33 Abs. 2 DSGVO unverzüglich informieren.

Bei extern betriebenen PHP-Anwendungen sollten deshalb die Informationswege, vertraglich vereinbarten Fristen und Zuständigkeiten zwischen Kunde, Hosting-Anbieter und sonstigen Dienstleistern geklärt sein.

Primärquelle: DSGVO, insbesondere Art. 33 und 34.

5. Cyber Resilience Act: Zusätzliche Pflichten für bestimmte Hersteller

Der Cyber Resilience Act (CRA), die Verordnung (EU) 2024/2847, enthält eigenständige Meldepflichten für Hersteller bestimmter Produkte mit digitalen Elementen.

Nach Art. 14 CRA müssen erfasste Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten, von denen sie Kenntnis erlangen, über die vorgesehene zentrale Meldeplattform sowohl dem zuständigen CSIRT als auch der ENISA melden.

Für die Meldung einer aktiv ausgenutzten Schwachstelle sieht Art. 14 unter anderem folgende Fristen vor:

• Innerhalb von 24 Stunden nach Kenntnis: Frühwarnung.
• Innerhalb von 72 Stunden nach Kenntnis: Schwachstellenmeldung mit den verfügbaren Informationen.
• Spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme:Abschlussbericht.

Diese Fristen beziehen sich auf die spezifischen CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen. Daneben enthält die Vorschrift gesonderte Anforderungen an die Meldung bestimmter Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit eines Produkts.

Die CRA-Meldepflicht darf nicht pauschal auf jedes Unternehmen übertragen werden, das PHP verwendet. Entscheidend ist unter anderem, ob das Unternehmen als Hersteller eines erfassten Produkts mit digitalen Elementen handelt und ob die gesetzlichen Voraussetzungen im konkreten Fall erfüllt sind.

Die CRA-Meldung ist außerdem von einer Meldung nach NIS2 oder einer Datenschutzmeldung nach der DSGVO zu unterscheiden. Ein Sachverhalt kann mehrere Regelwerke berühren; jede Pflicht muss gesondert geprüft werden.

Primärquelle: Verordnung (EU) 2024/2847 – Cyber Resilience Act, insbesondere Art. 14.

6. Weitere Pflichten: Verträge und branchenspezifische Regelungen

Neben den genannten Gesetzen können weitere Anforderungen gelten. Welche davon einschlägig sind, hängt vom konkreten Unternehmen und seiner Rolle ab.

Vertragliche Informationspflichten

Kundenverträge, Hosting-Verträge, Cloud-Vereinbarungen und Service-Level-Agreements können Meldefristen, Informationspflichten oder Anforderungen an die Behebung von Sicherheitsproblemen enthalten.

Diese Verpflichtungen sind unabhängig von gesetzlichen Meldepflichten zu prüfen. Ein Vorfall kann daher vertraglich relevant sein, auch wenn keine gesetzliche externe Meldung erforderlich ist.

Branchenspezifische Regelungen

Unternehmen in regulierten Branchen müssen gegebenenfalls zusätzliche aufsichtsrechtliche Anforderungen berücksichtigen. Für Finanzunternehmen ist beispielsweise zu prüfen, ob die Verordnung über die digitale operationale Resilienz im Finanzsektor (DORA) einschlägig ist.

Dabei darf nicht unterstellt werden, dass alle Branchen denselben Meldepflichten oder Fristen unterliegen. Maßgeblich sind die jeweilige Rechtsgrundlage, der Unternehmensstatus und die Art des Ereignisses.

Konsequenz für die Compliance-Organisation

Die Prüfung sollte in einem nachvollziehbaren Verfahren erfolgen. Für jede potenziell anwendbare Regelung sind die Voraussetzungen, die zuständigen Verantwortlichen, die relevanten Fristen und das Ergebnis der Einzelfallbewertung festzuhalten.

7. Was Unternehmen jetzt konkret tun sollten

Eine belastbare Reaktion auf die PHP-Schwachstellen verbindet technische Sofortmaßnahmen mit einer dokumentierten Compliance-Bewertung.

Schritt 1: Betroffene Systeme erfassen

Ermitteln Sie, welche PHP-Versionen und Laufzeitumgebungen tatsächlich betrieben werden. Berücksichtigen Sie produktive Systeme, Testumgebungen, Container-Images, CMS-Installationen und Anwendungen, die von externen Dienstleistern betrieben werden.

Priorisieren Sie Systeme, die öffentlich erreichbar sind oder kritische Geschäftsprozesse unterstützen.

Schritt 2: Sicherheitsupdates einspielen

Prüfen Sie die betroffenen Versionen und aktualisieren Sie auf eine geeignete korrigierte Version. Die offiziellen PHP-Sicherheitsmeldungen sind dabei maßgeblich.

PHP 8.2 erhält laut PHP-Projekt nur noch bis zum 31. Dezember 2026 Sicherheitskorrekturen. Unternehmen, die diese Version einsetzen, sollten deshalb neben dem unmittelbaren Patch auch die Migration auf eine weiterhin unterstützte PHP-Version planen.

Nach der Aktualisierung muss geprüft werden, ob die Korrektur tatsächlich auf allen betroffenen Systemen wirksam ist. Bei Container- und Deployment-Umgebungen umfasst dies auch die Aktualisierung der verwendeten Images und die Bereitstellung der korrigierten Laufzeitversion.

Schritt 3: Risiken bis zur Behebung reduzieren

Ist eine sofortige Aktualisierung technisch nicht möglich, sollten angemessene vorübergehende Schutzmaßnahmen geprüft werden. Dazu können die Einschränkung des Zugriffs und bei entsprechendem Risiko die Isolation exponierter Systeme gehören.

Solche Maßnahmen ersetzen den vom PHP-Projekt empfohlenen Sicherheitsfix nicht. Das Projekt weist ausdrücklich darauf hin, dass keine vollständigen alternativen Schutzmaßnahmen verfügbar sind.

Schritt 4: Auf mögliche Ausnutzung untersuchen

Prüfen Sie geeignete Sicherheitsdaten, insbesondere:

• Webserver- und PHP-Protokolle,
• Firewall- und WAF-Ereignisse,
• EDR- und Server-Telemetrie,
• ungewöhnliche Prozesse und ausgehende Netzwerkverbindungen,
• verdächtige Datei- oder Konfigurationsänderungen,
• auffällige Kontoaktivitäten und Zugriffe auf sensible Daten.

Sichern Sie relevante Beweise und dokumentieren Sie die Untersuchung. Bei Hinweisen auf eine Kompromittierung sollte der Incident-Response-Prozess aktiviert werden.

Schritt 5: Meldepflichten parallel prüfen

Bewerten Sie systematisch:

1. Fällt die Organisation unter das BSIG und die einschlägigen NIS2-Pflichten?
2. Liegt ein erheblicher Sicherheitsvorfall im Sinne des anwendbaren Rechts vor?
3. Ist eine Verletzung des Schutzes personenbezogener Daten eingetreten?
4. Bestehen besondere Pflichten aus Verträgen oder branchenspezifischen Regelungen?
5. Ist das Unternehmen Hersteller eines vom CRA erfassten Produkts und sind die besonderen Voraussetzungen der Herstellermeldung erfüllt?

Halten Sie die Ergebnisse und die Gründe für die jeweilige Entscheidung fest. Bestehen mehrere potenzielle Meldepflichten, sind die Fristen und Meldewege getrennt zu überwachen.

Schritt 6: Zuständigkeiten und Dokumentation sicherstellen

Binden Sie je nach Lage IT-Betrieb, Informationssicherheit, Datenschutzbeauftragte, Compliance, Rechtsabteilung und Management ein.

Die Dokumentation sollte insbesondere enthalten:

• Zeitpunkt der Kenntnisnahme und erste Risikobewertung,
• betroffene Systeme und Geschäftsprozesse,
• Ergebnisse der technischen Untersuchung,
• Patch- und Testnachweise,
• Bewertung gesetzlicher und vertraglicher Pflichten,
• Entscheidungen und ihre Begründung,
• gegebenenfalls Meldungen und Kommunikation mit Behörden, Kunden oder Dienstleistern,
• offene Maßnahmen, Verantwortliche und Fristen.

So lässt sich nachvollziehen, wie das Unternehmen die Schwachstelle bewertet, die Risiken begrenzt und seine Pflichten erfüllt hat.

8. Governance: Schwachstellenmanagement als überprüfbarer Prozess

Kritische Schwachstellen zeigen, ob die Prozesse für Informationssicherheit und Compliance tatsächlich funktionieren.

Ein belastbarer Prozess braucht definierte Zuständigkeiten, klare Eskalationskriterien und nachvollziehbare Entscheidungswege. Es muss feststehen, wer kritische Schwachstellen bewertet, wer Sofortmaßnahmen veranlassen darf und wer die rechtliche Bewertung möglicher Meldepflichten verantwortet.

Ebenso wichtig ist die Zusammenarbeit mit externen Dienstleistern. Wenn PHP-Systeme ausgelagert betrieben werden, müssen technische Informationen und mögliche Vorfallmeldungen rechtzeitig bei den zuständigen Stellen im Unternehmen ankommen.

Regelmäßige Übungen, verbindliche Reaktionszeiten und eine nachvollziehbare Dokumentation helfen, Verzögerungen und Zuständigkeitslücken zu vermeiden.

Unsere Empfehlung: Sofort beheben und Meldepflichten sachgerecht bewerten

Die kritischen PHP-Schwachstellen vom 21. Oktober 2026 erfordern eine unverzügliche technische Prüfung und priorisierte Behebung. Das PHP-Projekt empfiehlt ausdrücklich, betroffene Installationen zu aktualisieren, da keine vollständigen alternativen Schutzmaßnahmen verfügbar sind.

Aus Compliance-Sicht sind darüber hinaus vier Grundsätze entscheidend:

• Technische Sicherheit: Betroffene Systeme identifizieren, Updates einspielen und die Wirksamkeit der Korrektur nachweisen.
• Vorfallmanagement: Mögliche Ausnutzung untersuchen, Beweise sichern und erforderlichenfalls den Incident-Response-Prozess aktivieren.
• Rechtliche Bewertung: NIS2 beziehungsweise BSIG, DSGVO, CRA sowie gegebenenfalls vertragliche und branchenspezifische Pflichten anhand der tatsächlichen Umstände prüfen.
• Nachvollziehbarkeit: Entscheidungen, Fristen, Maßnahmen und Meldebewertungen dokumentieren.

Die entscheidende Compliance-Frage lautet daher nicht allein: „Ist der Patch installiert?“ Sie lautet ebenso: „Haben wir die tatsächlichen Risiken angemessen bewertet, mögliche Vorfall- und Meldepflichten geprüft und unsere Entscheidungen nachvollziehbar dokumentiert?“

Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine rechtliche Einzelfallprüfung. Die Anwendbarkeit gesetzlicher Pflichten hängt insbesondere vom Status der Organisation, den betroffenen Systemen, den tatsächlichen Vorfallumständen und der jeweils geltenden Rechtslage ab.

Quellen

1. PHP-Projekt: Offizielle Website und Sicherheitsankündigungen
2. Bundesministerium der Justiz: § 32 BSIG – Meldepflichten
3. Bundesministerium der Justiz: BSI-Gesetz (BSIG)
4. Europäische Union: Datenschutz-Grundverordnung (EU) 2016/679
5. Europäische Union: Cyber Resilience Act (EU) 2024/2847