Zwei kritische Schwachstellen in der Programmiersprache PHP bedrohen weltweit Webanwendungen und digitale Produkte. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat vor einer möglichen kurzfristigen und großflächigen Ausnutzung der als PHP2Shell bezeichneten Schwachstellen gewarnt und zu unverzüglichen Schutzmaßnahmen aufgerufen. Für unterstützte PHP-Versionen stehen bereits Sicherheitsupdates zur Verfügung. Unternehmen sollten nicht nur ihre technische Betroffenheit prüfen, sondern auch mögliche rechtliche Handlungs- und Meldepflichten sowie Haftungsrisiken in den Blick nehmen.
Die am 21. Oktober 2026 veröffentlichten Schwachstellen CVE-2026-109618 und CVE-2026-109619 betreffen eine der weltweit am häufigsten eingesetzten Technologien für den Betrieb von Webanwendungen.
Die unter der Bezeichnung „PHP2Shell“ bekannt gewordenen Sicherheitslücken erreichen jeweils einen CVSS-Wert von 9,2. Unter bestimmten technischen Voraussetzungen können Angreifer sie aus der Ferne und ohne vorherige Authentifizierung ausnutzen, um Schadcode auf betroffenen Systemen auszuführen.
Die möglichen Auswirkungen reichen von der Kompromittierung einzelner Websites bis zur Übernahme betroffener Server und dem Zugriff auf darin verarbeitete Informationen. Neben klassischen Internetauftritten können auch Unternehmensportale, Onlineshops, Verwaltungssysteme und andere digitale Produkte betroffen sein.
Für die aktuell unterstützten PHP-Versionszweige stehen seit dem 21. Oktober 2026 Sicherheitsupdates zur Verfügung. Die Schwachstellen sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Für ältere PHP-Versionen sowie in Produkte eingebettete PHP-Komponenten ist gesondert zu prüfen, ob der jeweilige Hersteller oder Distributor Sicherheitsupdates beziehungsweise Backports bereitstellt.
Die Gefahr beschränkt sich nicht auf theoretisch denkbare Angriffe. Sicherheitsunternehmen haben bereits konkrete Ausnutzungsversuche dokumentiert, teilweise sogar vor der offiziellen Veröffentlichung der Schwachstellen.
BSI warnt vor großflächigen Angriffen
Das BSI hat am 21. Oktober 2026 eine Cyber-Sicherheitswarnung zu den PHP-Schwachstellen veröffentlicht und die Bedrohung mit Warnstufe 3 („Orange“) bewertet.
BSI-Vizepräsident Thomas Caspers warnte vor einer möglichen kurzfristigen und großflächigen Ausnutzung. Seine Schlussfolgerung war eindeutig: „Es besteht also unverzüglicher Handlungsbedarf!“
Das BSI empfiehlt insbesondere, verfügbare Sicherheitsupdates unverzüglich einzuspielen, den Patchstatus zu kontrollieren und betroffene Systeme verstärkt zu überwachen. Können Systeme nicht zeitnah aktualisiert werden, ist auch ihre vorübergehende Trennung vom Internet als Schutzmaßnahme zu erwägen.
Am 22. Oktober 2026 war dem BSI noch keine erfolgreiche Ausnutzung der Schwachstellen in der Breite bekannt. Eine Entwarnung folgt daraus nicht. Das Risiko betrifft zudem nicht ausschließlich klassische Websites. Auch Netzwerkkomponenten können verwundbar sein, wenn sie entsprechende PHP-basierte Schnittstellen einsetzen.
Für Unternehmen bedeutet das: Noch nicht abgesicherte Systeme erfordern unverzügliche Aufmerksamkeit. Bereits aktualisierte Systeme sollten zudem auf mögliche frühere Kompromittierungen untersucht werden.
Risiko und Abhilfemaßnahme erhöhen den Handlungsdruck
Die BSI-Warnung ist nicht nur technisch, sondern auch rechtlich relevant. Denn sie erhöht die Anforderungen an die gebotene Sorgfalt.
Art. 32 DSGVO verpflichtet Verantwortliche und Auftragsverarbeiter zu angemessenen technischen und organisatorischen Maßnahmen. Für besonders wichtige und wichtige Einrichtungen verlangt § 30 BSIG angemessene Cybersicherheitsrisikomanagementmaßnahmen und adressiert dabei ausdrücklich auch die Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen sowie das Management von Schwachstellen.
Besonders relevant ist bei PHP2Shell, dass die Gefahr nicht nur öffentlich bekannt ist, sondern für unterstützte PHP-Versionen bereits Sicherheitsupdates zur Verfügung stehen. Dadurch lässt sich eine verzögerte Reaktion schwerer rechtfertigen. Je eindeutiger ein erhebliches Sicherheitsrisiko erkennbar ist und je wirksamer geeignete Abhilfemaßnahmen verfügbar sind, desto eher sind Unternehmen verpflichtet, diese auch schnellstmöglich zu ergreifen.
Maßgeblich sind unter anderem die konkrete Betroffenheit und Exponiertheit des Systems, die Umsetzbarkeit des Updates, verfügbare Zwischenmaßnahmen und die möglichen Auswirkungen eines Angriffs.
Unternehmen sollten deshalb nicht nur technische Maßnahmen ergreifen, sondern auch nachvollziehbar dokumentieren, wann die Bedrohung erkannt, welche Systeme untersucht und welche Entscheidungen getroffen wurden.
Ein Angriff kann Meldungen nach CRA, BSIG und DSGVO auslösen
Unternehmen müssen prüfen, ob ein Vorfall eine Meldepflicht auslöst. Die gute Nachricht: Die bloße Existenz einer verwundbaren PHP-Installation ist noch nicht meldepflichtig. Eine Meldung ist nur erforderlich, wenn die Schwachstelle auch tatsächlich ausgenutzt wurde und wenn die gesetzlichen Voraussetzungen erfüllt sind. Die jeweiligen Meldepflichten nach CRA, BSIG und DSGVO unterscheiden sich.
CRA: Meldepflicht bei aktiv ausgenutzten Schwachstellen
Für Hersteller Produkten mit digitalen Elementen gelten bereits seit dem 11. September 2026 die Meldepflichten des Art. 14 CRA. Bei PHP-basierten Produkten ist insbesondere zu prüfen, ob eine aktiv ausgenutzte Schwachstelle vorliegt, die im konkreten Produkt enthalten ist. Die bloße Verwendung einer verwundbaren Drittanbieter- oder Open-Source-Komponente sollte deshalb nicht ohne Prüfung der konkreten Produktbetroffenheit mit einer CRA-Meldepflicht gleichgesetzt werden.
BSIG: Meldepflicht bei erheblichen Sicherheitsvorfällen
Besonders wichtige und wichtige Einrichtungen müssen nach § 32 BSIG erhebliche Sicherheitsvorfälle melden. Auch hier begründet die bloße Existenz einer verwundbaren PHP-Version für sich genommen noch keinen erheblichen Sicherheitsvorfall.
DSGVO: Meldepflicht bei Datenschutzverletzungen
Nach der DSGVO kommt eine Meldepflicht insbesondere dann in Betracht, wenn ein Angriff zu einer Verletzung des Schutzes personenbezogener Daten führt. Hierfür ist kein nachgewiesener Datenabfluss erforderlich. Auch etwa die Veränderung, Löschung oder der Verlust der Verfügbarkeit personenbezogener Daten kann eine Datenschutzverletzung darstellen.
Unternehmen sollten deshalb technische Angriffsuntersuchung und rechtliche Bewertung möglicher Meldeschwellen parallel durchführen. Die vollständige forensische Aufklärung sollte nicht abgewartet werden, wenn eine gesetzliche Meldefrist bereits zu laufen begonnen hat.
Die unterschiedlichen Auslöser, Fristen und das Zusammenspiel der Meldepflichten nach DSGVO, BSIG und CRA erläutern wir ausführlich in unserem Beitrag „Meldefristen bei Cybervorfällen nach DSGVO, BSIG und CRA – jede Stunde zählt“.
Hersteller können nach dem Produkthaftungsrecht zu Sicherheitsupdates verpflichtet sein
Hersteller von Software und Produkten mit digitalen Elementen können auch produkthaftungsrechtlich dafür verantwortlich sein, erforderliche Sicherheitsupdates nach dem Inverkehrbringen bereitzustellen.
Mit der Reform des Produkthaftungsrechts wird Software ausdrücklich als Produkt erfasst. Zugleich berücksichtigt das neue Recht, dass Hersteller die Sicherheit digitaler Produkte auch nach dem Inverkehrbringen durch Softwareupdates und verbundene Dienste beeinflussen können.
Fehlen Sicherheitsupdates, die zur Aufrechterhaltung der Produktsicherheit erforderlich sind und der Kontrolle des Herstellers unterliegen, kann dies zur Fehlerhaftigkeit eines Produkts führen.
Die Neuregelungen sollen im Wesentlichen am 9. Dezember 2026 in Kraft treten. Für zuvor in Verkehr gebrachte Produkte bleibt allerdings grundsätzlich das bisherige Produkthaftungsrecht maßgeblich; daneben können insbesondere vertragliche, deliktsrechtliche oder datenschutzrechtliche Schadensersatzansprüche in Betracht kommen.
PHP2Shell zeigt damit beispielhaft, warum Hersteller ihre Softwareabhängigkeiten kennen und über funktionsfähige Prozesse zur Bewertung von Schwachstellen und zur Bereitstellung von Sicherheitsupdates verfügen sollten.
Cybersicherheit ist Verantwortung der Geschäftsleitung
Der Umgang mit einer bekannten kritischen Schwachstelle ist auch Sache der Geschäftsleitung und nicht nur der IT-Abteilung.
Für besonders wichtige und wichtige Einrichtungen wird dies durch § 38 Abs. 1 BSIG besonders deutlich: Die Geschäftsleitung ist verpflichtet, die nach § 30 BSIG erforderlichen Risikomanagementmaßnahmen umzusetzen und deren Umsetzung zu überwachen.
Auch außerhalb des Anwendungsbereichs dieser speziellen Regelung können gesellschaftsrechtliche Organisations- und Überwachungspflichten gelten. Bei einer kritischen und ausdrücklich durch das BSI adressierten Sicherheitslücke kommt es daher auch darauf an, dass Zuständigkeiten, Eskalationswege und Entscheidungsprozesse funktionieren.
Im Schadensfall kann die Geschäftsleitung auch persönlich haften, wenn kein angemessenes Risikomanagement und funktionierende Entscheidungsprozesse sichergestellt waren.
Was Unternehmen jetzt konkret tun sollten
Aus technischer und rechtlicher Sicht stehen insbesondere folgende Maßnahmen im Vordergrund:
1. Betroffenheit feststellen
PHP-Versionen, exponierte Server, Webanwendungen und digitale Produkte sollten überprüft werden. Dabei sind auch eingebettete PHP-Komponenten, Netzwerkkomponenten sowie externe Hosting- und IT-Dienstleister zu berücksichtigen.
2. Sicherheitsupdates priorisieren
Für die unterstützten PHP-Versionen stehen Sicherheitsupdates zur Verfügung. Betroffene Systeme sollten entsprechend der konkreten Gefährdungslage priorisiert aktualisiert und der tatsächliche Patchstatus kontrolliert werden. Bei älteren oder eingebetteten PHP-Versionen sollte geprüft werden, ob Hersteller oder Distributoren Updates oder Backports bereitstellen.
3. Frühere Kompromittierungen untersuchen
Auch bereits aktualisierte Systeme können zuvor angegriffen worden sein. Sicherheitsprotokolle und andere Angriffsindikatoren sollten deshalb rückwirkend untersucht werden.
4. Meldepflichten parallel prüfen
Bei Hinweisen auf eine Ausnutzung sollten mögliche Pflichten insbesondere nach CRA, BSIG und DSGVO frühzeitig bewertet werden. Die technische Untersuchung und die rechtliche Bewertung sollten parallel erfolgen.
5. Entscheidungen dokumentieren und Verantwortliche einbinden
Betroffenheit, Kenntniszeitpunkte, Maßnahmen und wesentliche Entscheidungen sollten nachvollziehbar dokumentiert werden. IT-Sicherheit, Datenschutz, Rechtsabteilung, Produktsicherheit und erforderlichenfalls die Geschäftsleitung sollten frühzeitig ein gemeinsames Lagebild herstellen.
PHP2Shell erhöht den Handlungsdruck für Unternehmen auch aus rechtlicher Sicht
Die Kombination aus einer hochkritischen Schwachstelle bei PHP2Shell, einer ausdrücklichen Warnung des BSI und bereits verfügbaren Sicherheitsupdates erhöht den Handlungsdruck auch in rechtlicher Hinsicht erheblich.
Eine bekannte Schwachstelle oder eine behördliche Warnung erhöhen die Anforderungen an die Sorgfaltspflichten und das Haftungsrisiko. Unternehmen können bereits vor Eintritt eines Schadens verpflichtet sein, ihre konkrete Betroffenheit zu untersuchen und angemessen auf erkennbare Risiken zu reagieren.
Selbst wenn kein Angriff nachgewiesen wurde, müssen Unternehmen ggf. nachweisen können, dass sie ein bekanntes erhebliches Risiko rechtzeitig erkannt, bewertet und angemessen behandelt haben.
