PHP2Shell: Was NIS2-Einrichtungen jetzt tun müssen

Verfasst von der NIS2Compass Redaktion · Stand: Oktober 2026 (Stand der Berichterstattung: 22.10.2026)

Die am 21. Oktober 2026 geschlossenen PHP-Lücken PHP2Shell (CVSS 9.2) müssen Sie allein nicht melden. Nach der Einordnung von NIS2Compass greift die Meldepflicht nach § 32 BSIG erst, wenn daraus ein erheblicher Sicherheitsvorfall wird. Patchen und dokumentieren verlangt § 30 BSIG dagegen schon jetzt.

Was ist PHP2Shell?

Hinter dem Namen stehen CVE-2026-109618 und CVE-2026-109619, zwei Fehler im PHP-Kern. Laut BSI-IT-Sicherheitshinweis vom 21.10.2026 können Angreifer darüber aus der Ferne Code auf Webservern ausführen, ohne Anmeldung und ohne Zutun eines Nutzers. Das BSI stuft den Hinweis in die Kritikalität 3 / Orange ein: „Maßnahmen müssen unverzüglich ergriffen werden.“

Betroffen sind nach dem Advisory des PHP-Projekts alle Installationen, die Webanfragen verarbeiten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php. Dort genügt eine einzige nicht authentifizierte Anfrage, noch bevor Anwendungscode läuft.

Die Fehler stecken in der Sprache selbst, nicht in einem einzelnen Produkt. Das BSI nennt als Beispiele für PHP-basierte Software unter anderem WordPress, TYPO3, Nextcloud und OPNsense. Behoben sind die Lücken in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es keine regulären Releases mehr. Das PHP-Team hat für 7.4, 8.0 und 8.1 minimale Quellcode-Backports bereitgestellt, daneben liefern Distributionen und LTS-Anbieter eigene Backports.

Bestätigte Angriffe waren dem BSI zum Zeitpunkt seines Hinweises nicht bekannt. Es geht aber von einer kurzfristigen Ausnutzung verwundbarer Systeme aus. Einige Betreiber in Deutschland haben ihre Server vorsorglich vom Netz genommen. Laut Help Net Security zeichnete ein Honeypot von Amazon bereits am 17. Oktober, vor der Veröffentlichung, einen Ausnutzungsversuch auf.

Muss ich PHP2Shell dem BSI melden?

Die Schwachstelle allein löst keine Meldepflicht aus. Das BSIG trennt drei Begriffe: Eine Schwachstelle ist eine ausnutzbare Eigenschaft eines Produkts (§ 2 Nr. 38 BSIG). Ein Sicherheitsvorfall ist ein Ereignis, das Verfügbarkeit, Integrität oder Vertraulichkeit tatsächlich beeinträchtigt (Nr. 40). Meldepflichtig ist erst der erhebliche Sicherheitsvorfall (Nr. 11).

Erheblich ist ein Vorfall, wenn er „schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste“ verursacht oder verursachen kann oder anderen Personen erheblichen Schaden zufügen kann. Finden Sie auf einem ungepatchten Server Spuren einer Kompromittierung, müssen Sie diese Frage beantworten. Dann laufen die Fristen aus § 32 BSIG: frühe Erstmeldung binnen 24 Stunden nach Kenntnis, Meldung binnen 72 Stunden, Abschlussmeldung spätestens einen Monat danach.

Wie Sie die Schwelle prüfen, erläutert der Beitrag zum erheblichen Sicherheitsvorfall. Fließen personenbezogene Daten ab, kommt in der Regel parallel die Meldung an die Datenschutzaufsicht nach Art. 33 DSGVO hinzu.

Ein abgewehrter Angriffsversuch ist meist ein Beinahevorfall (§ 2 Nr. 1). Ihn können Sie dem BSI nach § 5 BSIG melden, eine Pflicht besteht nicht.

Was verlangt § 30 BSIG wegen PHP2Shell?

PHP2Shell trifft vor allem fünf der zehn Mindestbereiche aus § 30 Abs. 2 BSIG. Die Maßnahmen müssen geeignet, verhältnismäßig und wirksam sein und sollen den Stand der Technik einhalten. Bei einer Lücke dieser Schwere heißt das: kurzfristig handeln und das Vorgehen dokumentieren.

• Schwachstellenmanagement (Nr. 5): Die Vorschrift umfasst ausdrücklich „Management und Offenlegung von Schwachstellen“. Dazu gehört ein Inventar, das zeigt, wo PHP läuft: auf Webservern, in Docker-Images und in Appliances wie Firewalls.
• Lieferkette (Nr. 4): Betreibt ein Hoster, eine Agentur oder ein Managed-Service-Provider Ihre PHP-Anwendungen, fragen Sie den Patchstand aktiv ab und lassen ihn sich bestätigen.
• Vorfallsbewältigung und Betrieb (Nr. 2 und 3): Lässt sich ein System nicht sofort patchen, brauchen Sie eine Entscheidung, ob es vorübergehend vom Netz geht. Vollständigen Schutz bieten laut BSI nur der Patch oder die Trennung vom Internet.
• Wirksamkeit prüfen (Nr. 6): Distributionen liefern oft Backports mit eigener Versionsnummer. Das BSI weist darauf hin, dass dann ein Abgleich der installierten Version mit dem Advisory der Distribution nötig sein kann.

Verletzt eine NIS2-pflichtige Einrichtung diese Pflichten, kommt § 65 BSIG in Betracht. Der Rahmen läge bei bis zu 10 Mio. € für besonders wichtige und bis zu 7 Mio. € für wichtige Einrichtungen, bei einem weltweiten Gesamtumsatz von mehr als 500 Mio. € alternativ bei 2 % bzw. 1,4 % davon. Die Systematik erklärt der Beitrag zu den Bußgeldstufen nach § 65 BSIG, eine Schätzung liefert der Bußgeldrechner.

Was gilt für Hersteller, die PHP in ihren Produkten nutzen?

Das BSI weist darauf hin, dass Hersteller unter Umständen neue Firmware mit gepatchtem PHP veröffentlichen müssen. Seit dem 11. September 2026 kommt für sie zudem eine Meldepflicht hinzu. Erfährt ein Hersteller, dass eine Schwachstelle in seinem Produkt aktiv ausgenutzt wird, meldet er sie nach Art. 14 des Cyber Resilience Act binnen 24 Stunden als Frühwarnung. Die Pflicht knüpft an die Ausnutzung im eigenen Produkt an, nicht an die Bekanntgabe von PHP2Shell.

Wie sich diese Meldung von § 32 BSIG unterscheidet, zeigt der Vergleich CRA-Meldepflicht nach Art. 14 und § 32 BSIG.

Welche drei Schritte sind nach PHP2Shell sinnvoll?

1. Inventar: alle Systeme mit PHP erfassen, auch Container, Appliances und Anwendungen bei Dienstleistern. Ob Ihr Hoster selbst NIS2-pflichtig ist, zeigt die Branchenseite für IT-Dienstleister.
2. Patch und Neustart: auf eine behobene Version aktualisieren, PHP-Dienste neu starten, Docker-Images neu bauen, den Stand gegen das Advisory prüfen. Die Konfigurationsänderungen aus dem PHP-Advisory verringern das Risiko nur, sie ersetzen das Update nicht.
3. Prüfen und dokumentieren: Logs ungepatchter Systeme mindestens ab dem 17. Oktober auf Auffälligkeiten durchsehen und festhalten, wann welches System gepatcht wurde. Diese Dokumentation brauchen Sie, falls das BSI später Nachweise zu Ihren Maßnahmen anfordert.

Ob Ihr Unternehmen überhaupt unter das BSIG fällt, zeigt die Betroffenheitsprüfung von NIS2Compass. Für alle anderen bleibt PHP2Shell ein Grund zum Patchen, aber kein Fall für das BSIG.

Quellen:

• BSI, IT-Sicherheitshinweis, Version 1.1 vom 21.10.2026: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit
• PHP-Projekt, Security Advisory vom 21.10.2026: php.net News Archive 2026
• Help Net Security, 21.10.2026: PHP2Shell: Critical PHP vulnerabilities patched, update now!
• § 2 BSIG (Begriffsbestimmungen), gesetze-im-internet.de
• § 5 BSIG (Allgemeine Meldestelle), gesetze-im-internet.de
• § 30 BSIG (Risikomanagementmaßnahmen), gesetze-im-internet.de
• § 32 BSIG (Meldepflichten), gesetze-im-internet.de
• § 65 BSIG (Bußgeldvorschriften), gesetze-im-internet.de
• Verordnung (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
• Verordnung (EU) 2016/679 (DSGVO), EUR-Lex