PHP2Shell: Wer betroffen ist und was jetzt zu tun ist

PHP2Shell sind zwei kritische Lücken in PHP selbst, und vollständig schützen nur zwei Wege: das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder die Trennung des Systems vom Internet. [1, 2]

Eine Einordnung unter Vorbehalt. Grundlage ist die Cybersicherheitswarnung des BSI in Version 1.2 vom 22.10.2026, die Lage entwickelt sich weiter. Diese Analyse trennt, was BSI und PHP-Projekt belegen, was Medien und Sicherheitsfirmen berichten und was wir einschätzen. Sie gilt bis zum 31.12.2026. [1, 3]

Der Autor ist Gründer und Geschäftsführer von KaitoSec.

Das Wichtigste in Kürze

• PHP2Shell bezeichnet zwei kritische Schwachstellen in PHP selbst (CVE-2026-109618, CVE-2026-109619, CVSS 4.0: 9,2), über die Angreifer ohne Anmeldung und ohne Zutun eines Nutzers Code auf Webservern ausführen können. Schutz vor dieser PHP-Sicherheitslücke bieten nur die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder die Trennung vom Internet. [2, 3]
• Betroffen ist laut BSI jede PHP-Installation, die Webanfragen verarbeitet, zurück bis mindestens PHP 5. Workarounds verringern die Angriffsfläche, schließen die Lücken aber nicht. [1]
• Dem BSI liegen nach Stand vom 22.10.2026 keine bestätigten Meldungen über erfolgreich kompromittierte Systeme aus der regulierten Wirtschaft oder der Bundesverwaltung vor. Versuche gab es schon vor dem Patch: Amazon berichtet einen ersten Ausnutzungsversuch am 17. Oktober und spricht inzwischen von breiter Ausnutzung. [1, 4]
• Betroffen sein kann auch, wer keine eigene PHP-Webseite betreibt. Firewalls, Load Balancer, NAS-Systeme und Hosting-Panels können PHP enthalten; Produkte von F5, Citrix NetScaler, Palo Alto, OPNsense, pfSense, QNAP, Synology und cPanel sind laut BSI mindestens teilweise betroffen. [1]
• Viele Behörden, Kliniken und Hochschulen haben ihre Webseiten seit dem 21. Oktober vorsorglich vom Netz genommen. Das ist eine bewusste Abwägung: Das BSI empfiehlt, eine Trennung zu erwägen, wenn nicht sofort gepatcht werden kann. [1, 5, 6]

Was ist seit dem 20. Oktober passiert?

Am 20. Oktober 2026 kündigte das PHP-Sicherheitsteam einen kritischen Sicherheits-Release an, am Nachmittag des 21. Oktober erschienen die Patches. Noch am selben Tag gab das BSI eine Cybersicherheitswarnung der Stufe 3/Orange heraus, die EU-Cybersicherheitsbehörden veröffentlichten eine gemeinsame Erklärung, und zahlreiche Betreiber nahmen Webseiten vorsorglich vom Netz. [2, 3, 7]

Die Vorankündigung des PHP-Projekts und die GitHub-Advisories bewerten beide Lücken mit CVSS 4.0 9,2, das Security-Advisory des PHP-Projekts folgte am 21. Oktober; angekündigt war der Release für 16 Uhr deutscher Zeit. Die Cybersicherheitswarnung des BSI liegt seit dem 22. Oktober in Version 1.2 vor. [1, 2, 3]

Datum	Ereignis	Belegstufe	Quelle
ab August 2026	Mehrere Forschungsteams, darunter Wiz und Calif (Letztere auf Einladung von OpenAI, teils mit KI-Modellen), finden die Fehler und melden sie dem PHP-Projekt; Calif erstmals am 11.08., Wiz am 24.08.	berichtet (Forscher selbst)	[8, 9]
17.10.	Amazon Threat Intelligence beobachtet einen ersten Ausnutzungsversuch, vier Tage vor der Veröffentlichung	berichtet	[4, 10]
20.10.	Das PHP-Projekt kündigt den Sicherheits-Release für den 21.10. an. Am selben Tag gelangen die Lücken laut SecurityWeek vorab an die Öffentlichkeit; Huntress verweist auf einen inzwischen gelöschten Beitrag auf Hacker News.	belegt / berichtet	[2, 10, 11]
21.10., nachmittags	PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen, dazu Backport-Patches für 7.4, 8.0 und 8.1	belegt	[1, 2]
21.10.	BSI-Warnung in Version 1.0 und 1.1; ENISA, CERT-EU, Europol EC3, EU-Kommission und CSIRTs-Netzwerk veröffentlichen ein Joint Statement	belegt	[3, 7]
21./22.10.	Behörden, Kliniken und Hochschulen in Deutschland und der Schweiz nehmen Webseiten vorsorglich vom Netz	belegt (Sprecher) / berichtet	[5, 6, 12, 13]
22.10.	BSI-Warnung in Version 1.2: Hersteller-Advisories für Netzwerkkomponenten; keine bestätigten Meldungen erfolgreicher Kompromittierung aus regulierter Wirtschaft und Bundesverwaltung (Stand 22.10.2026); Berichte über unvollständige Patches widerlegt	belegt	[1]

Wie funktioniert PHP2Shell, und welche Versionen sind sicher?

Beide Teile dieser PHP-Sicherheitslücke stecken im Kern von PHP, nicht in einer Anwendung. Die eine entsteht, wenn PHP bei Speicherknappheit eine Anfrage nur halb aufgebaut abbricht, die andere, wenn Reste einer früheren Anfrage im Speicher weiterverwendet werden. Ein Update von WordPress, TYPO3 oder Shopware allein schützt deshalb nicht; die PHP-Laufzeitumgebung selbst muss aktualisiert werden. [1, 2]

Beide CVE-Einträge, CVE-2026-109618 und CVE-2026-109619, ermöglichen Remote Code Execution (RCE): Angreifer führen über das Netz eigenen Code auf dem Server aus. Daher das „Shell“ im Namen: Wer das schafft, kann eine Webshell ablegen, also eine Hintertür, über die sich der Server später fernsteuern lässt. Laut Wiz kann schon ein reines „Hello World“-Skript auf einer verwundbaren Version angreifbar sein. [8, 14, 15]

Volker Dusch, Softwareentwickler bei der PHP Foundation, bezeichnete die Lücken gegenüber dem Wall Street Journal als das gravierendste Sicherheitsproblem von PHP seit mehr als zehn Jahren (zitiert nach 20 Minuten/dpa). [12]

Betroffen sind laut BSI alle Installationen, die Webanfragen verarbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php. Dort genügt eine Anfrage ohne Anmeldung, bevor Anwendungscode läuft. [1]

Meist kommt PHP über die Paketverwaltung. Distributionen patchen per Backport, die Versionsnummer zeigt dann nicht den echten Stand: Maßgeblich ist das Advisory von Ubuntu, Debian oder Red Hat. Docker-Images müssen neu gebaut werden, und Workarounds schützen laut PHP-Projekt und BSI nicht vollständig. [1, 2]

Versionszweig	Geschützt ab	Sicherheitsunterstützung durch PHP bis	Hinweis
8.5	8.5.12	31.12.2029	unterstützt
8.4	8.4.27	31.12.2028	unterstützt
8.3	8.3.36	31.12.2027	unterstützt
8.2	8.2.35	31.12.2026	BSI weist auf das Supportende hin
8.1, 8.0, 7.4	Backport-Patches des PHP Security Teams	End-of-Life	Migration empfohlen
älter (bis PHP 5)	kein Patch vom PHP-Projekt	End-of-Life	Distribution oder LTS-Anbieter prüfen, sonst vom Netz trennen oder migrieren

Stand der Tabelle: PHP-Projekt und BSI, 22.10.2026. [1, 2, 14, 16]

Warum schalten Behörden ihre Webseiten ab?

Weil eine Webseite, die nicht sofort gepatcht werden kann, nur zwei Zustände kennt: erreichbar und angreifbar oder offline und geschützt. Das BSI empfiehlt in diesem Fall ausdrücklich, eine vorübergehende Trennung vom Internet zu erwägen, da kein Workaround vollständig schützt. Die Abschaltung tauscht Verfügbarkeit gegen Integrität und Vertraulichkeit. [1]

Die gemeinsame Erklärung der EU-Cybersicherheitsbehörden und CERT-EU empfehlen ebenfalls, Systeme zu isolieren, wenn sich die Behebung verzögert. Wer abschaltet, entscheidet sich nicht gegen den Dienst, sondern gegen eingeschleusten Code und abfließende Daten. [1, 7, 17]

In Berlin waren am 21. und 22. Oktober laut Tagesspiegel unter anderem die Internetwache der Polizei, die Feuerwehr, FU, HU und Charité offline oder eingeschränkt, beim Abgeordnetenhaus einzelne Funktionen; laut heise waren Teile von berlin.de abgeschaltet. Senatssprecherin Christine Richter sagte zu berlin.de: „Wir haben fast alles wieder zum Laufen gebracht.“ Laut Charité-Sprecher Markus Heggen hatten die Einschränkungen keinen Einfluss auf die Arbeit der Klinik. [5, 13]

Kommunal.de nannte am 21. Oktober unter anderem RKI, Bundespolizei, Zoll, Bundesinnenministerium, Mainz, Unna und Datteln; das Landratsamt Dachau und München waren bereits wieder online. Heise berichtete am 22. Oktober unter Berufung auf dpa und NDR von nicht erreichbaren Behörden- und Polizeiseiten in Bayern und Niedersachsen. Das BSI bestätigt vorsorgliche Trennungen. [1, 6, 13]

Unsere Einschätzung: Diese Abwägung gelingt schnell nur, wenn sie vorher geregelt ist. Wer darf eine Bürger-Webseite abschalten, wer informiert über alternative Kontaktwege, wie kommunal.de es empfiehlt, und wer entscheidet über das Wiedereinschalten? Das gehört in die Notfallorganisation, mit klaren Rollen und Eskalationswegen im Krisenstab. [6]

Wer ist betroffen, auch ohne eigene PHP-Webseite?

Betroffen ist jede Organisation, in deren IT irgendwo PHP Webanfragen verarbeitet: auf eigenen Servern, bei Hostern und Dienstleistern oder versteckt in Geräten. Das BSI nennt Firewalls, Router, Load Balancer und Netzwerkkomponenten im Allgemeinen; mindestens teilweise betroffen sind laut BSI, Stand 22.10.2026, Produkte von acht Herstellern, darunter NAS-Systeme von QNAP und Synology. [1]

• Eigene Webanwendungen und CMS: Das BSI nennt WordPress, Drupal, TYPO3, Joomla, Magento und Nextcloud, Deutschland sicher im Netz zusätzlich Shopware für Onlineshops. [1, 18]
• Hoster und Agenturen: Bei Shared Hosting und verwalteten Servern patcht der Dienstleister. Das Risiko bleibt nach unserer Einschätzung beim Betreiber, die Frage nach dem Patchstand gehört deshalb ins Lieferantenrisikomanagement. [1]
• Appliances und Netzwerkkomponenten: Mindestens teilweise betroffen sind laut BSI, Stand 22.10.2026, Produkte von F5, Citrix NetScaler, Palo Alto, OPNsense, Netgate pfSense, QNAP, Synology und cPanel; Cisco, WatchGuard, Sophos und Broadcom führt das BSI als bislang unbekannt oder nicht betroffen. Die Liste ist laut BSI nicht abschließend, das niederländische NCSC pflegt eine laufend aktualisierte. Geschlossen wird die Lücke hier per Firmware-Update des Herstellers, nicht per PHP-Update. [1, 19]
• Industrielle Steuerungen (ICS/OT): Deren Weboberflächen können laut BSI grundsätzlich betroffen sein. [1]

Zur Größenordnung: Censys zählte am 21. Oktober rund 1,58 Millionen Hosts, deren PHP-Version von außen erkennbar war, davon rund 1,57 Millionen ungepatcht. VulnCheck fand über 2,6 Millionen aus dem Internet erreichbare PHP-Hosts, rund eine Million davon mit End-of-Life-Versionen. Beide Zahlen beruhen auf Internet-Scans der Firmen, berichtet von SecurityWeek am 22. Oktober. [10] Viele dieser Altsysteme erhalten laut BSI überhaupt keine Updates mehr. [1]

Welche Pflichten gelten jetzt?

Eine Meldepflicht entsteht nicht durch die Schwachstelle selbst, sondern erst durch einen erheblichen Sicherheitsvorfall. Für Einrichtungen unter NIS2 gehört Schwachstellenmanagement zur Pflicht: § 30 BSIG verlangt es ebenso wie Sicherheit in der Lieferkette. Werden personenbezogene Daten abgegriffen, gilt zusätzlich Art. 33 DSGVO mit 72 Stunden Meldefrist. [20, 21, 22]

Unter NIS2 sind besonders wichtige und wichtige Einrichtungen nach § 30 BSIG verpflichtet, geeignete, verhältnismäßige und wirksame Maßnahmen zu ergreifen. Dazu zählen die Sicherheit der Lieferkette, Wartung „einschließlich Management und Offenlegung von Schwachstellen“ und die Bewertung der Wirksamkeit. Von der öffentlichen Verwaltung erfasst das BSI-Gesetz nur Einrichtungen der Bundesverwaltung; Länder und Kommunen fallen nicht darunter. [20, 23]

Meldepflichtig nach § 32 BSIG ist erst ein erheblicher Sicherheitsvorfall, etwa mit schwerwiegenden Betriebsstörungen oder erheblichen Schäden für andere. Nach unserer Lesart erreicht eine festgestellte Kompromittierung über PHP2Shell diese Schwelle häufig, eine vorsorgliche Abschaltung oder ein abgewehrter Versuch allein nicht. Entscheidend bleibt der Einzelfall. Wege und Inhalte der Meldung erklärt unser Beitrag zu den NIS2-Meldepflichten. [21, 24]

Nach der DSGVO ist eine Datenschutzverletzung unverzüglich und möglichst binnen 72 Stunden ab Kenntnis zu melden, außer sie führt voraussichtlich zu keinem Risiko. Bei hohem Risiko verlangt Art. 34 die Benachrichtigung der Betroffenen. [22]

Für ISO/IEC 27001:2022 und den IT-Grundschutz (Edition 2023) fasst die Tabelle die einschlägigen Anforderungen zusammen; das BSI nennt in seiner Warnung zusätzlich APP.3.1. [1, 25, 26, 27, 28]

Regelwerk	Gilt für	Was es jetzt verlangt	Frist
§ 30 BSIG	Besonders wichtige und wichtige Einrichtungen	Schwachstellenmanagement, Sicherheit der Lieferkette, Wirksamkeitsprüfung	keine feste Frist, risikobasiert
§ 32 BSIG	Besonders wichtige und wichtige Einrichtungen	Meldung erheblicher Sicherheitsvorfälle an das BSI	24 h Erstmeldung, 72 h Meldung, 1 Monat Abschlussmeldung
Art. 33/34 DSGVO	Verantwortliche für personenbezogene Daten	Meldung an die Aufsichtsbehörde, bei hohem Risiko Benachrichtigung Betroffener	72 h (Art. 33)
ISO/IEC 27001 A 8.8	Organisationen mit ISMS nach ISO 27001	Handhabung von technischen Schwachstellen	keine feste Frist, risikobasiert
IT-Grundschutz OPS.1.1.3/APP.3.2	Anwender des IT-Grundschutzes	Patch- und Änderungsmanagement, Absicherung von Webservern	keine feste Frist, risikobasiert

Was sollten Organisationen jetzt prüfen?

Klären Sie zuerst, wo überall PHP läuft, auch in Appliances und bei Dienstleistern. Gleichen Sie danach die Versionen mit den gepatchten Ständen ab, patchen oder trennen Sie, prüfen Herstelleradvisories, untersuchen die Systeme auf Kompromittierung und dokumentieren jede Entscheidung. Das BSI rät, auch nach dem Patch auf eine bereits erfolgte Kompromittierung zu prüfen. [1, 2]

Schritt	Prüffrage	Verantwortlich	Nachweis/Quelle
1. Inventar	Wo verarbeitet PHP Webanfragen: eigene Server, Container-Images, CMS und Shops, Appliances mit Weboberfläche, gehostete Seiten?	IT-Betrieb mit ISB	Asset-Liste [1]
2. Version	Entspricht die installierte Version 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder dem Backport der Distribution?	IT-Betrieb	Abgleich mit php.net bzw. Distributions-Advisory [1, 2]
3. Patchen oder trennen	Ist jedes erreichbare System gepatcht oder vom Internet getrennt? Sind Container neu gebaut?	IT-Betrieb, Dienstleister	Changelog, Ticket [1]
4. Appliances	Haben Hersteller eigener Firewalls, Gateways und NAS ein Advisory veröffentlicht?	Netzwerk/Security	BSI-Herstellerliste, NCSC-NL [1, 19]
5. Dienstleister	Haben Hoster, Agenturen und Rechenzentren gepatcht und eine Kompromittierung geprüft? Liegt die Antwort schriftlich vor?	ISB, Einkauf	Lieferantenantwort [7]
6. Kompromittierung prüfen	Gibt es Hinweise auf eine abgelegte Webshell: ungewöhnliche Prozesse, die der Webserver startet, neue oder veränderte PHP-Dateien, gehäufte HTTP-500-Fehler nach Upload-Anfragen?	Security/SOC	BSI-Indikatoren [1]
7. End-of-Life	Welche Anwendungen laufen auf PHP vor 8.2 oder auf 8.2 (Support bis 31.12.2026)?	Anwendungsverantwortliche	Migrationsplan [1, 16]
8. Entscheidung dokumentieren	Wer hat Abschaltung, Workaround oder Restrisiko entschieden? Ist die Meldepflicht (§ 32 BSIG, Art. 33 DSGVO) geprüft?	ISB, Geschäftsleitung bzw. Behördenleitung, DSB	Risikoentscheidung [20, 21, 22]

Schritt 2 und 3 gehören ins reguläre Patch-Management. Schritt 1, 5 und 8 sind Dokumentationsarbeit, die im Ernstfall schon fertig sein sollte.

In KaitoSec liegen die Angaben zu diesen drei Schritten an einer Stelle. Das Asset-Inventar erfasst Hardware, Software, Cloud und Netzwerk, auch per CSV-Import, und zeigt, welche Systeme und Prozesse von einem Asset abhängen und mit welchem Lieferanten es verknüpft ist.

Im Lieferantenmanagement verschicken Sie Fragebögen an Hoster und Agenturen, offene Punkte werden zu Aufgaben mit Verantwortlichem. Risikoentscheidungen halten Sie als Behandlung fest, mit Verantwortlichem, Fälligkeit und Freigabe. Wie Sie solche Maßnahmen verfolgen, zeigt der Beitrag zum Nachverfolgen von ISMS-Maßnahmen.

Wie wir zu dieser Einschätzung kommen

Diese Einordnung stützt sich vorrangig auf die BSI-Cybersicherheitswarnung in Version 1.2, das Security-Advisory des PHP-Projekts und die GitHub-Advisories zu beiden CVEs. Medienberichte und Beobachtungen von Sicherheitsfirmen kennzeichnen wir als berichtet, eigene Ableitungen als Einschätzung. [1, 2, 3, 14, 15]

Eingeschätzt sind die Meldeschwelle nach § 32 BSIG, die Abschalt-Abwägung und die Reihenfolge der Prüfschritte. Das Verfahren ist dasselbe wie in unseren Fallanalysen zur Stadt Wien und zum Landesnetz Berlin.

Was ist zu PHP2Shell noch offen?

Offen ist vor allem, ob und wo PHP2Shell bereits erfolgreich ausgenutzt wurde. Dem BSI liegen (Stand 22.10.2026) keine bestätigten Meldungen erfolgreich kompromittierter Systeme aus regulierter Wirtschaft und Bundesverwaltung vor. Amazon berichtet dagegen von breiter Ausnutzung, Reuters unter Berufung auf Cloudflare von Millionen Angriffsversuchen; Cloudflares eigener Blog nennt keine Zahl. Diese Messungen einzelner Anbieter sind nicht unabhängig geprüft, und Versuche sind keine bestätigten Kompromittierungen. [1, 4, 13, 29]

Die Liste betroffener Produkte ist im Aufbau: Das BSI nennt seine Aufstellung ausdrücklich nicht abschließend, das NCSC-NL aktualisiert seine laufend. Das BSI hält weitere Funde in PHP für möglich, auch wegen des verstärkten KI-Einsatzes bei der Schwachstellensuche. Auch die Liste abgeschalteter Organisationen ist unvollständig; wir nennen nur, wen Quellen nennen. [1, 19]

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell?

PHP2Shell ist der Sammelname für zwei kritische Schwachstellen in PHP selbst, CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 4.0 von 9,2. Sie erlauben Codeausführung ohne Anmeldung. Schutz bieten nur die gepatchten Versionen oder die Trennung vom Internet. Der Name lehnt sich laut BSI an Log4Shell an. [1, 2, 3]

Welche PHP-Versionen sind sicher?

Geschützt sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 hat das PHP Security Team Backport-Patches bereitgestellt. Wer PHP über eine Linux-Distribution bezieht, gleicht den Stand mit deren Advisory ab, weil die Versionsnummer den Patchstand nicht immer zeigt. [1, 2]

Reicht es, WordPress oder TYPO3 zu aktualisieren?

Nein. Die Lücken stecken in der PHP-Laufzeitumgebung, nicht in der Anwendung. Ein Update des CMS lässt die verwundbare PHP-Version unverändert. Laut BSI muss PHP selbst aktualisiert werden, bei Containern gehört dazu, die Images neu zu bauen. [1]

Schützt eine Web Application Firewall vor PHP2Shell?

Eine Web Application Firewall kann Angriffe erschweren, aber nicht ausschließen. Vollständigen Schutz bieten laut BSI nach aktuellem Stand nur das Patchen oder die Trennung vom Internet. Auch Cloudflare rät in seinem eigenen Blog, trotz Filterregeln zu patchen. [1, 29]

Muss ich PHP2Shell nach NIS2 melden?

Die Schwachstelle selbst ist nicht meldepflichtig. Meldepflichtig ist ein erheblicher Sicherheitsvorfall nach § 32 BSIG: Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussmeldung nach einem Monat. Fließen personenbezogene Daten ab, gilt zusätzlich Art. 33 DSGVO mit 72 Stunden. [21, 22, 24]

Wurde PHP2Shell schon ausgenutzt?

Versuche gibt es: Amazon beobachtete den ersten am 17. Oktober, vier Tage vor der Veröffentlichung der Patches. Amazon spricht inzwischen von breiter Ausnutzung. Bestätigte Meldungen erfolgreich kompromittierter Systeme aus regulierter Wirtschaft und Bundesverwaltung liegen dem BSI nach eigenen Angaben (Stand 22.10.2026) nicht vor. [1, 4]

Quellen

1. BSI, IT-Sicherheitshinweis zur Cybersicherheitswarnung PHP (PDF, TLP:CLEAR), Version 1.2, 22.10.2026. bsi.bund.de
2. PHP-Projekt, Security advisory: Critical remote code execution vulnerabilities, update now, 21.10.2026, mit Vorankündigung vom 20.10.2026. php.net, Advisory, php.net, Vorankündigung
3. BSI, Cybersicherheitswarnung „PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.2, 22.10.2026. bsi.bund.de
4. Amazon Web Services, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, 21.10.2026. aws.amazon.com
5. Tagesspiegel, Berliner Polizei und weitere Behörden waren betroffen: Etliche Webseiten nach schwerer IT-Sicherheitslücke wieder verfügbar, 22.10.2026. tagesspiegel.de
6. KOMMUNAL, IT-Sicherheitslücke PHP: Bundesamt warnt Kommunen, 21.10.2026. kommunal.de
7. ENISA, EU-Kommission, CERT-EU, Europol EC3 und CSIRTs-Netzwerk, Joint statement on critical PHP vulnerabilities, 21.10.2026. enisa.europa.eu
8. Wiz, PHP2Shell: AI uncovers critical RCE vulnerabilities, 21.10.2026. wiz.io
9. Calif, A tale of two PHP remote vulnerabilities, 21.10.2026 (calif.io; enthält technische Details zur Ausnutzung, deshalb hier nicht verlinkt).
10. SecurityWeek, PHP2Shell Exploitation Started Days Before Patches, 22.10.2026. securityweek.com
11. Huntress, Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities, 20.10.2026. huntress.com
12. 20 Minuten (mit dpa), «PHP2Shell»: «Gravierendstes Sicherheitsproblem»: Auch CH-Websites offline, 21.10.2026. 20min.ch
13. heise online, php2shell: Updates roll out as websites go offline and attacks begin, 22.10.2026. heise.de
14. PHP-Projekt, GitHub Security Advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618 „RCE via OOM corruption“, 21.10.2026. github.com
15. PHP-Projekt, GitHub Security Advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619 „RCE via stale global state“, 21.10.2026. github.com
16. PHP-Projekt, Supported Versions, abgerufen 22.10.2026. php.net
17. CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP, 21.10.2026. cert.europa.eu
18. Deutschland sicher im Netz, PHP2Shell: Kritische Sicherheitslücken gefährden Webseiten und Onlineshops, 21.10.2026. sicher-im-netz.de
19. NCSC-NL, php2shell: Produktliste und Hinweise zu Erkennung und Schutz, Stand 22.10.2026. github.com
20. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 30 Risikomanagementmaßnahmen. gesetze-im-internet.de
21. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 32 Meldepflichten. gesetze-im-internet.de
22. Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), Art. 33 und 34. eur-lex.europa.eu
23. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 29 Einrichtungen der Bundesverwaltung. gesetze-im-internet.de
24. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, § 2 Begriffsbestimmungen. gesetze-im-internet.de
25. ISO/IEC 27001:2022, Informationssicherheits-Managementsysteme, Anforderungen. iso.org
26. BSI, IT-Grundschutz-Kompendium Edition 2023, OPS.1.1.3 Patch- und Änderungsmanagement. bsi.bund.de
27. BSI, IT-Grundschutz-Kompendium Edition 2023, APP.3.2 Webserver. bsi.bund.de
28. BSI, IT-Grundschutz-Kompendium Edition 2023, APP.3.1 Webanwendungen und Webservices. bsi.bund.de
29. Cloudflare, Cloudflare deploys protections against php2shell vulnerability, 21.10.2026. blog.cloudflare.com

Stand und Aktualisierungen

Stand: 22.10.2026 (BSI-Warnung Version 1.2) · Gültig bis: 31.12.2026

• 22.10.2026, Erstveröffentlichung als Einordnung unter Vorbehalt. Belegt sind Lücken, Patches und BSI-Empfehlungen; Ausnutzung ist von Sicherheitsfirmen berichtet, erfolgreiche Kompromittierungen sind vom BSI nicht bestätigt.

Bis zum Stichtag prüfen wir vier Punkte: neue Versionen der BSI-Warnung, bestätigte Kompromittierungen in Deutschland, weitere Herstelleradvisories und die Wiederinbetriebnahme abgeschalteter Webseiten. Wir aktualisieren diesen Artikel am selben Ort, wenn sich die Lage ändert.

---

Wie wir arbeiten: In unseren Fallanalysen ordnen wir Vorfälle und Sicherheitslagen nach einem festen Verfahren ein: Quellen mit Belegstufe, Folgen, Pflichten, Prüfschritte, offene Fragen. Daraus leiten wir Maßnahmen für Organisationen mit gewachsener IT und regulatorischem Druck ab. Gespräch dazu vereinbaren.