PHP2Shell: Was die PHP-Sicherheitslücke für ISO 27001 und NIS2 bedeutet

Das Wichtigste in Kürze

• PHP2Shell bezeichnet zwei kritische Schwachstellen im PHP-Interpreter, CVE-2026-109618 und CVE-2026-109619, beide mit 9.2 nach CVSS v4.0 bewertet. Angreifer können darüber ohne Anmeldung Code auf Webservern ausführen.
• Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 7.4 bis 8.1 hat das PHP-Projekt nur Quellcode-Backports veröffentlicht, ältere Versionen erhalten keinen Fix.
• Das BSI hat am 21. Oktober 2026 eine Cybersicherheitswarnung der Warnstufe "3 / Orange" herausgegeben. Erste Angriffsversuche hat Amazon bereits am 17. Oktober beobachtet, vier Tage vor den Patches.
• Die Schwachstelle allein ist unter NIS2 kein meldepflichtiger Vorfall. Führt sie zu einem erheblichen Sicherheitsvorfall, ist innerhalb von 24 Stunden eine Erstmeldung an die gemeinsame Meldestelle von BSI und BBK fällig.
• In einem ISMS nach ISO 27001 fällt die Reaktion unter Control A.8.8 (Management technischer Schwachstellen). Im nächsten Audit sollten Sie belegen können, welche Systeme Sie geprüft und wann Sie gepatcht haben.

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Lücken veröffentlicht, die unter dem Namen PHP2Shell bekannt geworden sind. Die PHP-Sicherheitslücke steckt nicht in einem Plugin oder Framework, sondern im Interpreter selbst. Betroffen ist damit jede Anwendung, die auf PHP läuft: WordPress, Drupal, Typo3, Joomla, Magento, Shopware, Moodle und viele interne Eigenentwicklungen. Laut BSI betrifft die Lücke nicht nur Websites, sondern auch Firewalls, Load Balancer und andere Netzwerkkomponenten, sofern sie eine PHP-basierte Weboberfläche haben.

Das BSI sprach von einem "herausragenden Bedrohungspotenzial". Universitäten, Stadtverwaltungen und Kliniken haben ihre Websites vorsorglich vom Netz genommen, die meisten waren am Folgetag wieder erreichbar.

Dieser Artikel richtet sich an IT-Verantwortliche, CISOs und Compliance-Teams. Er erklärt, was technisch passiert ist, was Sie jetzt tun sollten und was PHP2Shell für Unternehmen bedeutet, die nach ISO 27001 zertifiziert sind oder unter NIS2 fallen.

Was ist PHP2Shell?

PHP2Shell ist der Sammelname für zwei Schwachstellen im PHP-Interpreter, über die Angreifer aus der Ferne und ohne Zugangsdaten eigenen Code auf einem Webserver ausführen können. Fachleute nennen das Remote Code Execution. Wer das schafft, kann Daten und Passwörter abgreifen, Websites manipulieren, Schadsoftware einschleusen oder den Server für weitere Angriffe nutzen.

Die zwei Schwachstellen

CVE-2026-109618 entsteht, wenn PHP während einer Anfrage der Arbeitsspeicher ausgeht. Die Anfrage bricht dann ab, während interne Daten erst teilweise aufgebaut sind. Die anschließende Aufräumroutine behandelt diese unvollständigen Daten als gültig, und genau dort setzt der Angriff an.

CVE-2026-109619 betrifft den Zustand zwischen zwei Anfragen. Interne Daten einer Anfrage bleiben bestehen, obwohl der zugehörige Speicher schon freigegeben ist. Bearbeitet derselbe Worker die nächste Anfrage, kann er diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird.

Warum Ihre Anwendung den Angriff nicht abfangen kann

Der Angriff läuft ab, bevor Ihre Anwendung überhaupt startet. Sicherheitsforscher von Datadog haben beide Lücken nachgestellt: Eine einzige nicht authentifizierte HTTP-POST-Anfrage an ein beliebiges PHP-Skript reicht aus, selbst wenn dieses Skript nur eine Seite ausgibt.

Ein Login, ein Sicherheits-Plugin oder sauber geprüfter Anwendungscode schützen deshalb nicht. Betroffen sind alle gängigen Betriebsarten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php.

Wie sich die Lage entwickelt hat

Laut Amazon Threat Intelligence gab es den ersten Angriffsversuch auf Amazons Honeypot-Netzwerk bereits am 17. Oktober 2026, als die Lücken noch unter Verschluss standen. Am 20. Oktober kündigte das PHP-Projekt die Patches an, nachdem technische Details vorab an die Öffentlichkeit gelangt waren. Am Nachmittag des 21. Oktober erschienen die korrigierten Versionen.

Cloudflare-CEO Matthew Prince berichtete, dass die Zahl der Angriffsversuche innerhalb von zwei Stunden nach der Veröffentlichung auf Hunderttausende und kurz darauf auf Millionen stieg. Sicherheitsfachleute rechnen damit, dass automatisierte Angriffe noch über Wochen und Monate weiterlaufen. Stand 22. Oktober lagen dem BSI nach eigenen Angaben keine Meldungen über erfolgreich kompromittierte Systeme aus der regulierten Wirtschaft oder der Bundesverwaltung vor. Erfolgreiche Angriffe schließt das BSI aber ausdrücklich nicht aus.

Welche PHP-Versionen betroffen sind

Betroffen sind alle PHP-Versionen vor den Notfall-Releases vom 21. Oktober 2026, bis zurück zu PHP 5. Ob ein Server geschützt ist, hängt davon ab, welchen Versionszweig er nutzt und woher er seine Updates bezieht.

Ein häufiger Fehlschluss: Die Versionsnummer allein sagt nicht, ob ein Server sicher ist. Linux-Distributionen spielen Sicherheitskorrekturen oft als Backport ein, ohne dass sich die angezeigte PHP-Version ändert. Prüfen Sie deshalb die Sicherheitshinweise Ihrer Distribution oder lassen Sie sich von Ihrem Hoster schriftlich bestätigen, dass beide CVEs behoben sind.

Ebenso verbreitet war vor den Patches der Rat, session.upload_progress abzuschalten. Datadog hat gezeigt, dass diese Maßnahme den Angriff nicht verhindert. Auch neue WAF-Regeln, wie Cloudflare sie für alle Tarife ausgerollt hat, überbrücken nur die Zeit bis zum Update. Schutz bietet allein der Patch.

Was Sie jetzt tun sollten

Die wichtigste Aufgabe ist ein vollständiger Überblick darüber, wo in Ihrem Unternehmen PHP läuft. Erfahrungsgemäß sind das mehr Systeme, als die IT auf Anhieb nennen kann.

1. Inventar erstellen (Tag 1, IT-Betrieb). Erfassen Sie jeden Server, jedes Container-Image und jedes Hosting-Paket mit PHP. Denken Sie an Staging-Umgebungen, alte Kampagnenseiten, das Intranet und Websites, die eine Agentur für Sie betreut. Dazu gehören auch Firewalls, Load Balancer, NAS-Systeme und andere Geräte mit PHP-basierter Verwaltungsoberfläche. Bei diesen Geräten kommt die Korrektur als Firmware-Update des Herstellers, nicht als PHP-Update.
2. Patchen oder bestätigen lassen (Tag 1 bis 2, IT-Betrieb oder Hoster). Spielen Sie auf eigenen Servern die korrigierten Versionen ein. Große Hoster wie Ionos haben ihre Systeme bereits aktualisiert. Lassen Sie sich das trotzdem für jede Website bestätigen.
3. Veraltete Systeme isolieren (Tag 1 bis 2, IT-Leitung). Was auf PHP 8.1 oder älter läuft und sich nicht kurzfristig aktualisieren lässt, nehmen Sie vom Netz oder schotten es ab. Das empfiehlt unter anderem das britische NCSC. Verwaltungsoberflächen von Firewalls, NAS-Systemen und anderen Netzwerkgeräten sollten bis zum Update nicht aus dem Internet erreichbar sein.
4. Logs prüfen (Tag 2 bis 3, Security). Werten Sie die Logs ab dem 17. Oktober aus. Auffällig sind sehr große Formular-Uploads, Speicherfehler beim Start einer Anfrage, Shell-Prozesse, die von PHP gestartet werden, neue Admin-Konten und unerwartete Dateiänderungen.
5. Vorfallprozess auslösen (sofort bei Verdacht, ISB oder CISO). Gibt es Hinweise auf eine Kompromittierung, greift Ihr Incident-Response-Prozess, einschließlich der Prüfung möglicher Meldepflichten.
6. Dokumentieren (laufend, ISB). Halten Sie fest, wann Sie von der Lücke erfahren haben, welche Systeme betroffen waren, wann Sie gepatcht haben und was die Log-Analyse ergeben hat.

Ein weiterer Irrtum betrifft WordPress. Viele Betreiber verlassen sich auf automatische Updates. Diese aktualisieren aber WordPress, Plugins und Themes, nicht die PHP-Version des Servers. Die Korrektur muss vom Hoster oder vom Server-Betrieb kommen.

Was PHP2Shell für NIS2 bedeutet

Unter NIS2 ist der Umgang mit Schwachstellen eine ausdrückliche Pflicht. Artikel 21 Absatz 2 Buchstabe e der Richtlinie verlangt Maßnahmen für die Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen, einschließlich der Behandlung von Schwachstellen. In Deutschland steht diese Pflicht in § 30 BSI-Gesetz. Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft und hat das BSI-Gesetz neu gefasst. Einen Überblick über alle Pflichten finden Sie in unserem Leitfaden zu den NIS2-Anforderungen.

Meldepflicht: wann sie greift und wann nicht

Viele Unternehmen gehen davon aus, dass sie PHP2Shell an das BSI melden müssen, weil ihre Server betroffen sind. Das stimmt so nicht. Eine Schwachstelle allein ist kein Sicherheitsvorfall. Meldepflichtig ist erst ein erheblicher Sicherheitsvorfall, etwa wenn Angreifer über die Lücke Daten abgegriffen oder einen Dienst gestört haben.

Tritt dieser Fall ein, gelten in Deutschland die Fristen aus § 32 BSI-Gesetz: eine Erstmeldung spätestens 24 Stunden, nachdem Sie von dem erheblichen Sicherheitsvorfall Kenntnis erlangt haben, eine Meldung mit erster Bewertung innerhalb von 72 Stunden und eine Abschlussmeldung spätestens einen Monat nach dieser Meldung. Die Meldungen gehen an die gemeinsame Meldestelle von BSI und BBK.

Die Geschäftsleitung ist in der Pflicht

Nach § 38 BSI-Gesetz muss die Geschäftsleitung die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen. Bei einer Lücke dieser Größenordnung sollte die Geschäftsführung wissen, wie viele Systeme betroffen waren und bis wann sie gepatcht sind. Was das konkret bedeutet, beschreibt unser Beitrag zu den Pflichten der Geschäftsleitung unter NIS2.

Was PHP2Shell für ISO 27001 bedeutet

In einem ISMS nach ISO 27001:2022 ist PHP2Shell ein Testfall für mehrere Controls aus Anhang A. Im Mittelpunkt steht A.8.8, das Management technischer Schwachstellen: Sie müssen Informationen über Schwachstellen rechtzeitig erhalten, Ihre Gefährdung bewerten und angemessene Maßnahmen ergreifen.

Daneben sind weitere Controls betroffen. A.5.9 verlangt ein Inventar der Werte, ohne das Sie nicht wissen, wo überall PHP läuft, auch in Netzwerkgeräten. A.5.7 betrifft Threat Intelligence, also die Frage, wie schnell Sie von der BSI-Warnung erfahren haben. A.8.16 regelt die Überwachung, die Sie für die Log-Analyse brauchen, und A.5.24 bis A.5.28 decken das Vorfallmanagement ab. Wie diese ISO-27001-Controls zusammenspielen, erklären wir in einem eigenen Beitrag.

Was Auditoren sehen wollen

Im nächsten Überwachungsaudit wird die Frage kommen, wie Ihr Unternehmen auf PHP2Shell reagiert hat. Ein Auditor erwartet keine Perfektion, aber einen nachvollziehbaren Prozess: Wann haben Sie von der Lücke erfahren? Wer hat die Betroffenheit bewertet? Welche Systeme wurden bis wann gepatcht? Wo ist das dokumentiert?

Ein Beispiel: Ein SaaS-Unternehmen mit 60 Beschäftigten betreibt seine Plattform auf PHP 8.3 in 14 Container-Images, dazu eine Marketing-Website bei einem Hoster und ein altes Kundenportal auf PHP 7.4. Die Container sind nach sechs Stunden aktualisiert, die Website bestätigt der Hoster am nächsten Morgen. Das Kundenportal nimmt das Team vom Netz und plant die Migration. Liegen dafür Tickets mit Zeitstempeln vor, ist der Nachweis für A.8.8 in wenigen Minuten erbracht. Fehlen sie, rekonstruiert das Team Wochen später aus Chatverläufen und Erinnerungen.

DSGVO: wenn personenbezogene Daten betroffen sind

Unabhängig von NIS2 gilt die DSGVO. Haben Angreifer über PHP2Shell Zugriff auf Kundendaten, Passwörter oder Kontaktdaten erlangt, liegt eine Verletzung des Schutzes personenbezogener Daten vor. Nach Artikel 33 DSGVO ist sie innerhalb von 72 Stunden an die zuständige Datenschutzaufsicht zu melden, sofern ein Risiko für die Betroffenen besteht. Prüfen Sie diese Frage parallel zur technischen Analyse, nicht erst danach.

Schwachstellen beheben und nachweisen, ohne Screenshots zu sammeln

Nach einer Lücke wie PHP2Shell müssen Sie die Behebung nicht nur umsetzen, sondern im Audit auch belegen. Kertos verbindet beide Schritte über die Integration von Aikido und Kertos. Aikido Security erkennt verwundbare Komponenten in Code, Container-Images und Cloud-Umgebungen. Kertos liest diese Befunde und ihre Behebungsfristen täglich aus und hinterlegt das Ergebnis als Nachweis für die passenden Anforderungen aus ISO 27001, NIS2 und SOC 2.

Für Ihr Audit bedeutet das: Der Nachweis, wann eine Schwachstelle gefunden und wann sie behoben wurde, entsteht dort, wo die Arbeit passiert. Die erfahrenen Experten von Kertos unterstützen Sie dabei, Ihren Schwachstellen- und Vorfallprozess so aufzusetzen, dass er der nächsten kritischen Lücke standhält.

Wenn Sie sehen möchten, wie das in Ihrer Umgebung aussieht, vereinbaren Sie eine Demo.

Häufig gestellte Fragen

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei kritische Schwachstellen im PHP-Interpreter, CVE-2026-109618 und CVE-2026-109619, beide mit 9.2 nach CVSS v4.0 bewertet. Sie erlauben es Angreifern, ohne Anmeldung Code auf Webservern auszuführen. Das PHP-Projekt hat am 21. Oktober 2026 korrigierte Versionen veröffentlicht.

Welche PHP-Versionen sind von PHP2Shell betroffen?

Betroffen sind alle Versionen vor den Notfall-Releases vom 21. Oktober 2026, bis zurück zu PHP 5. Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Für PHP 7.4 bis 8.1 gibt es nur Backports über Distributionen und LTS-Anbieter, ältere Versionen erhalten keinen Fix.

Ist meine WordPress-Seite von der PHP-Sicherheitslücke betroffen?

Wenn der Server eine ungepatchte PHP-Version nutzt, ja. Automatische WordPress-Updates helfen nicht, weil sie nur WordPress, Plugins und Themes aktualisieren. Die PHP-Version sehen Sie unter Werkzeuge, Website-Zustand, Bericht, Server, und die Korrektur muss Ihr Hoster oder Server-Betrieb einspielen.

Muss ich PHP2Shell unter NIS2 an das BSI melden?

Nicht allein deshalb, weil Ihre Server die Schwachstelle hatten. Meldepflichtig ist ein erheblicher Sicherheitsvorfall, etwa ein Datenabfluss oder eine Störung Ihrer Dienste. Dann ist eine Erstmeldung innerhalb von 24 Stunden fällig, eine Meldung mit erster Bewertung innerhalb von 72 Stunden und eine Abschlussmeldung spätestens einen Monat danach.

Schützt eine Web Application Firewall vor PHP2Shell?

Nur vorübergehend. Anbieter wie Cloudflare haben Regeln für bekannte Angriffsmuster ausgerollt, die die Zeit bis zum Update überbrücken. Abwandlungen des Angriffs können solche Regeln umgehen, daher schützt dauerhaft allein das PHP-Update.