PHP2Shell im Rückblick: Was die kritischen PHP-Lücken gelehrt haben

Q: Was war PHP2Shell?

PHP2Shell bezeichnet in öffentlichen Berichten zwei kritische PHP-Lücken (CVE-2026-109618 und CVE-2026-109619). Laut PHP-Team können sie Remote Code Execution ohne Anmeldung ermöglichen. Das PHP-Projekt hat am 21. Oktober 2026 Sicherheitsupdates veröffentlicht, CISA nahm die Lücken am 26. Oktober in den Katalog bekannter ausgenutzter Schwachstellen auf.

Q: Was lehrt PHP2Shell langfristig?

Das Zeitfenster zwischen Veröffentlichung und Angriffen ist auf Stunden geschrumpft. Betreiber brauchen einen Überblick über ihre PHP-Systeme, einen geübten Update-Ablauf, einen Plan für Altversionen und Monitoring, das Angriffe jenseits der Anwendungslogs erkennt.

Q: Wurden Websites tatsächlich übernommen?

Bestätigt ist erfolgreiche Codeausführung auf Honeypots unter einem bewusst günstigen Profil (24. Oktober). Massenhafte Kompromittierungen sind öffentlich bisher nicht belegt. Cloudflare nannte Millionen Versuche, Wiz beobachtete in eigener Telemetrie nur begrenzte Versuche und keine erfolgreiche End-to-End-Ausnutzung. Weil Angriffe kaum Spuren hinterlassen, kann die tatsächliche Zahl höher liegen.

Q: Welche PHP-Versionen schließen die Lücken?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gab es kein offizielles Release, nur Backports von Distributionen und Hostern sowie minimale Quellcode-Backports des PHP-Sicherheitsteams für 7.4 bis 8.1. Hier ist meist ein Upgrade auf eine unterstützte Version nötig.

Q: Wie viele Systeme waren eine Woche später noch verwundbar?

Laut Wiz blieben eine Woche nach der Offenlegung weniger als 53 % der ursprünglich betroffenen Organisationen verwundbar, die Zahl erreichbarer verwundbarer Rechner sank um rund 67 %. Das sind Trendwerte aus Wiz-Telemetrie, keine Zählung des gesamten Internets.

Q: Muss ich meine Website vom Netz nehmen?

Wenn Ihr PHP gepatcht ist, ist ein Abschalten laut Sansec nicht nötig. Wenn ein sofortiges Update nicht möglich ist oder PHP 8.1 oder älter läuft, empfiehlt CISA, PHP-basierte Systeme vom Netz zu nehmen. Das BSI rät laut Medienberichten, eine vorübergehende Trennung zu erwägen. Informieren Sie in dem Fall betroffene Nutzer.

Q: Gab es weitere Lücken im Zusammenhang?

Am 23. Oktober gab das PHP-Team einen informationalen Hinweis zu CVE-2026-115560 heraus, der eine ungewöhnliche Kombination von Session-Einstellungen betrifft. Am 26. Oktober erschienen Windows-Builds mit einem Fix für die separate Brotli-Lücke CVE-2026-111497.

Q: Reichte ein Update von WordPress, Shopware oder Laravel?

Nein. Die Lücken lagen in PHP selbst. Entscheidend war die PHP-Version auf dem Server, ein Update der Anwendung oder ihrer Erweiterungen allein schützte nicht.

Im Oktober 2026 wurden zwei kritische Sicherheitslücken in PHP bekannt, der Programmiersprache hinter einem Großteil aller Websites, darunter WordPress, Shopware, Magento und Laravel. Über die unter dem Namen PHP2Shell bekannten Lücken (CVE-2026-109618 und CVE-2026-109619, CVSS 9,2) konnte ein Angreifer unter bestimmten Bedingungen ohne Anmeldung Code auf einem Server ausführen.

Das PHP-Team veröffentlichte am 21. Oktober Sicherheitsupdates. Am 26. Oktober nahm die US-Behörde CISA die Lücken in ihren Katalog bestätigt ausgenutzter Schwachstellen auf. Dieser Rückblick erklärt, was die Lücken bedeuteten, wie sich die Lage entwickelte, was sich bestätigt hat und was Betreiber von PHP-Systemen daraus mitnehmen sollten.

InnoGE hat 200 Kundensysteme in weniger als zwei Stunden vorbereitet und nach der Veröffentlichung der Patches um 16:00 Uhr aktualisiert. Stand: 28. Oktober 2026.

KI in Ihrem Unternehmen richtig einführen?

Strategie, Befähigung, Architektur – von Entwicklern umgesetzt.

Jetzt kostenlosen Termin vereinbaren

Das Thema kurz und kompakt

Was war das? Zwei kritische PHP-Lücken, über die ein Angreifer unter bestimmten Bedingungen ohne Anmeldung Code auf einem Server ausführen konnte. Betroffen war PHP selbst, also jede Anwendung darauf.
Wie schnell ging es? Die Details waren schon vor dem Patch öffentlich, der Patch erschien am 21. Oktober, innerhalb von zwei Stunden zählte Cloudflare laut seinem CEO Hunderttausende Angriffsversuche, am nächsten Tag Millionen. Als bestätigt ausgenutzt führt CISA die Lücken seit dem 26. Oktober.
Was bleibt? Ein bekannter Bestand, ein geübter Update-Ablauf und ein Plan für Altversionen. Auch eine Woche nach der Offenlegung war laut Wiz noch rund die Hälfte der betroffenen Organisationen verwundbar.

Wie lief PHP2Shell ab?

Der Fall begann mit einem Leck, nicht mit einem Angriff. Bevor die Patches erschienen, waren Einzelheiten zu den Lücken öffentlich, und Angreifer sondierten bereits: Amazon bemerkte am 17. Oktober einen ersten Versuch auf seinen Köder-Servern, vier Tage vor dem Patch. Die Chronik zeigt, wie schnell sich die Lage danach entwickelte.

Chronik der ersten zehn Tage

Zusammengestellt aus php.net, Berichten von Tenable, SecurityWeek, The Hacker News, Wiz, ZfK und den Beiträgen von Cloudflare und Amazon.

Datum (2026)	Ereignis
17. Oktober	Amazon meldet einen ersten Ausnutzungsversuch auf seinem Honeypot-Netz (Köder-Server, die Angriffe aufzeichnen), vier Tage vor dem Patch.
20. Oktober	Details werden vorab öffentlich, das PHP-Team kündigt Sicherheitsupdates für den 21. Oktober an.
21. Oktober	PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das BSI warnt (Warnstufe 3 / Orange laut Medienberichten), CISA veröffentlicht einen Alert, Cloudflare meldet erste Angriffe.
22. Oktober	Cloudflare-CEO Matthew Prince nennt tausende Versuche vor der Bekanntgabe, Hunderttausende innerhalb von zwei Stunden danach und inzwischen Millionen. Das BSI meldet keine erfolgreich kompromittierten Systeme aus regulierter Wirtschaft und Bundesverwaltung.
23. Oktober	Das PHP-Team veröffentlicht einen informationalen Hinweis zu CVE-2026-115560. CISA meldet noch keine erfolgreiche Ausnutzung.
24. Oktober	Ein Forscher bei Perplexity bestätigt erfolgreiche Codeausführung auf Honeypots: 35 gestartete Shells, unter einem bewusst günstigen Profil (einzelner Worker, mod_php).
26. Oktober	CISA nimmt beide Lücken in den Katalog bekannter ausgenutzter Schwachstellen auf, Frist für Bundesbehörden 29. Oktober. Das PHP-Projekt veröffentlicht Windows-Builds mit einem Brotli-Fix (CVE-2026-111497, eine separate Lücke).
27. Oktober	Wiz beobachtet in eigener Telemetrie nur begrenzte Versuche und keine erfolgreiche End-to-End-Ausnutzung. Die Zahl erreichbarer verwundbarer Rechner sank laut Wiz-Telemetrie um rund 67 %.

17. Oktober

Ereignis: Amazon meldet einen ersten Ausnutzungsversuch auf seinem Honeypot-Netz (Köder-Server, die Angriffe aufzeichnen), vier Tage vor dem Patch.

20. Oktober

Ereignis: Details werden vorab öffentlich, das PHP-Team kündigt Sicherheitsupdates für den 21. Oktober an.

21. Oktober

Ereignis: PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das BSI warnt (Warnstufe 3 / Orange laut Medienberichten), CISA veröffentlicht einen Alert, Cloudflare meldet erste Angriffe.

22. Oktober

Ereignis: Cloudflare-CEO Matthew Prince nennt tausende Versuche vor der Bekanntgabe, Hunderttausende innerhalb von zwei Stunden danach und inzwischen Millionen. Das BSI meldet keine erfolgreich kompromittierten Systeme aus regulierter Wirtschaft und Bundesverwaltung.

23. Oktober

Ereignis: Das PHP-Team veröffentlicht einen informationalen Hinweis zu CVE-2026-115560. CISA meldet noch keine erfolgreiche Ausnutzung.

24. Oktober

Ereignis: Ein Forscher bei Perplexity bestätigt erfolgreiche Codeausführung auf Honeypots: 35 gestartete Shells, unter einem bewusst günstigen Profil (einzelner Worker, mod_php).

26. Oktober

Ereignis: CISA nimmt beide Lücken in den Katalog bekannter ausgenutzter Schwachstellen auf, Frist für Bundesbehörden 29. Oktober. Das PHP-Projekt veröffentlicht Windows-Builds mit einem Brotli-Fix (CVE-2026-111497, eine separate Lücke).

27. Oktober

Ereignis: Wiz beobachtet in eigener Telemetrie nur begrenzte Versuche und keine erfolgreiche End-to-End-Ausnutzung. Die Zahl erreichbarer verwundbarer Rechner sank laut Wiz-Telemetrie um rund 67 %.

Illustration: Zeitleiste mit sieben Punkten, die nach rechts größer und grüner werden, am Ende ein grüner Schutzschild mit Haken

Was ist PHP2Shell, kurz erklärt?

„PHP2Shell" ist der Name, unter dem öffentliche Berichte zwei Sicherheitslücken in PHP zusammenfassen. Das PHP-Team bewertet beide als kritisch (CVSS 9,2) und beschreibt sie als Wege zu Remote Code Execution ohne Anmeldung: Unter bestimmten Bedingungen kann ein Angreifer Code auf dem Server ausführen lassen.

CVE-2026-109618: Korruption bei Speicherknappheit. Die Behandlung eines Out-of-Memory-Fehlers kann die Initialisierung interner Request-Daten unterbrechen, sodass ungültige Daten bei der Bereinigung als gültig behandelt werden.
CVE-2026-109619: Veralteter globaler Zustand. Ein Request-Zustand überlebt die Freigabe seines Speichers, und ein späterer Request im selben Worker kann ihn nutzen, bevor er zurückgesetzt wird.

Das größte Risiko sah das PHP-Team bei mod_php. Der betroffene Code stammt laut Sansec und Tenable aus PHP 5.4.0. Offizielle Fixes gab es für PHP 8.2 bis 8.5, für 7.4 bis 8.1 nur minimale Quellcode-Backports des PHP-Sicherheitsteams sowie Backports von Distributionen und Hostern.

9,2

CVSS-v4.0-Wert beider Lücken (kritisch)

Tage vom ersten Ausnutzungsversuch (17. Oktober) bis zur Aufnahme in den CISA-Katalog (26. Oktober)

<53 %

der ursprünglich betroffenen Organisationen waren laut Wiz eine Woche nach der Offenlegung noch verwundbar

200

Kundensysteme hat InnoGE in unter 2 Stunden vorbereitet und nach 16:00 Uhr gepatcht

Experten-Tipp von InnoGE: „Der nächste kritische Patch kommt bestimmt. Entscheidend ist, ob Sie bis dahin wissen, wo PHP läuft, wer es aktualisiert und wie lange das dauert."

Tim Geisendörfer

Founder & CEO

Was hat sich bestätigt, was nicht?

Die ersten Tage waren von Warnungen geprägt. Im Rückblick lassen sich Erwartungen und Beobachtungen gegenüberstellen.

Erwartung: sofortige Massenausnutzung. Versuche kamen tatsächlich sofort: Cloudflare nannte laut Matthew Prince innerhalb von zwei Stunden nach der Bekanntgabe Hunderttausende, später Millionen. Erfolgreiche Angriffe blieben dagegen lange unbestätigt.
Erwartung: Standardinstallationen sind angreifbar. Die ersten Beobachter bestätigten das nicht. Sansec wies darauf hin, dass öffentliche Exploits gegen Standardinstallationen nicht funktionierten. Erst am 24. Oktober meldete ein Forscher funktionierende Ausnutzung, aber ausdrücklich unter einem bewusst günstigen Profil mit einem einzelnen mod_php-Worker.
Wiz: Ausnutzbarkeit hängt vom Setup ab. In der Telemetrie von Wiz scheiterte ein Versuch schon an der Grenze von 8 MB für post_max_size. Build, Speicherlimit und Erweiterungen beeinflussten laut Wiz, ob die Kette funktionierte. Das ersetzt kein Update, zeigt aber, dass Härtung wirkt.
Erwartung: Websites gehen in Massen verloren. Öffentlich belegt sind vor allem vorsorgliche Abschaltungen, etwa bei Kommunen und Kliniken, und schnelle Updates bei Hostern. Massenhafte Kompromittierungen sind bisher nicht belegt.
Weiter offen: Wie viele Systeme tatsächlich kompromittiert wurden, lässt sich schwer sagen, weil Angriffe laut CrowdStrike kaum Spuren in Anwendungslogs hinterlassen.

Welche Lehren bleiben?

PHP2Shell ist weniger ein einmaliger Vorfall als ein Muster. Sechs Erkenntnisse gelten über den Anlass hinaus:

1. Das Zeitfenster ist auf Stunden geschrumpft

Zwischen erstem Versuch und Patch lagen vier Tage, zwischen Patch und den ersten Hunderttausenden Versuchen nur zwei Stunden. Amazon verweist darauf, dass KI-gestützte Analyse von Patches die Hürde senkt, aus einem Fix einen Exploit abzuleiten. Updates müssen in Stunden möglich sein, nicht in Wochen.
2. Koordinierte Veröffentlichung ist keine Garantie

Die Details waren vorab öffentlich, der Patch-Termin wurde vorgezogen. Ein Notfallablauf muss auch außerhalb der Bürozeiten funktionieren und darf nicht vom angekündigten Termin abhängen.
3. Altversionen sind das größte Risiko

Für PHP 8.1 und älter gab es kein offizielles Release. Laut Shodan waren rund 884.000 Server mit PHP 8.1 oder älter aus dem Internet erreichbar, Censys schätzt über 32 Millionen PHP-Dienste mit betroffener Version. Wer solche Systeme betreibt, braucht einen Upgrade-Plan oder Backports.
4. Der Bestand muss bekannt sein

Betroffen waren nicht nur Websites, sondern auch Geräte mit PHP-Weboberfläche wie Router, Firewalls oder NAS-Systeme. Wer nicht weiß, wo PHP läuft, kann nicht gezielt patchen.
5. Härtung wirkt als zweite Schicht

Speicherlimits, Request-Größen und Worker-Konfiguration beeinflussen, ob ein Angriff gelingt. In einem von Wiz beobachteten Fall scheiterte ein Versuch an der Request-Größe. Das ersetzt kein Update, verschafft aber Zeit.
6. Angriffe sind schwer zu sehen

Sie hinterlassen laut CrowdStrike kaum Spuren in Anwendungslogs. Überwachung auf Prozessebene und eine Firewall als zusätzliche Schicht gehören dazu.

Wie bleiben Sie beim nächsten Mal handlungsfähig?

Die Empfehlungen folgen den Hinweisen von PHP, Tenable, KELA und Wiz und ergänzen sie um das, was sich im Betrieb bewährt.

Bestand erfassen

Wo läuft PHP, in welcher Version, wer ist zuständig? Mit php -v und php-fpm -v prüfen, da Kommandozeile und Webserver unterschiedliche Builds nutzen können. Bei Linux-Paketen im Changelog nach CVE-2026-109618 suchen, weil Distributionen Fixes zurückportieren.
Update-Ablauf festlegen

Wer entscheidet, wer spielt ein, wo wird getestet, wann ist das Wartungsfenster? Ein Ablauf, der Sicherheitsupdates in wenigen Stunden schafft, muss vorher geübt werden.
Supportzeiträume im Kalender

PHP 8.2 bekommt Sicherheitsfixes bis 31. Dezember 2026, 8.3 bis 31. Dezember 2027, 8.4 bis 31. Dezember 2028 und 8.5 bis 31. Dezember 2029. Upgrades gehören ein Jahr vor dem Ende in die Planung.
Monitoring ergänzen

Auf PHP-Prozesse achten, die unerwartet eine Shell starten oder Dateien herunterladen, auf neue Dateien im Webroot und auf Memory-Limit-Fehler im Webserver-Log. Logs ab dem 17. Oktober auf auffällige Multipart-Anfragen prüfen.
In Schichten absichern

Zugriffsrechte auf das Nötigste, getrennte Backups mit getesteter Wiederherstellung, Speicherlimits und Request-Größen begrenzen, eine Web Application Firewall als zusätzliche Schicht. Ursprungs-Adressen dürfen nicht direkt erreichbar sein, sonst lässt sich die Firewall umgehen.
Notfallplan schreiben

Wann nehmen wir ein System vom Netz, wer informiert Kunden, wer meldet an die Aufsicht? Bei abgegriffenen personenbezogenen Daten gilt in der Regel die Meldepflicht nach Art. 33 DSGVO binnen 72 Stunden.

Was gilt für noch ungepatchte Systeme?

Wer noch Systeme auf einer Version vor dem Fix betreibt, sollte sofort auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren und danach PHP-FPM beziehungsweise den Webserver neu starten. Das PHP-Team betont, dass nur das Update die Lücken vollständig schließt. Als Übergang nennt es Einstellungen in php.ini oder im FPM-Pool, nicht per ini_set():

memory_limit: Auf -1 setzen, möglichst nicht überschreibbar (php_admin_value), und nur zusammen mit Container- oder cgroup-Limits. RLIMIT_AS und RLIMIT_DATA nicht verwenden.
post_max_size begrenzen: 8M ohne Datei-Uploads, 32M mit Uploads.
session.upload_progress.enabled deaktivieren: Auf 0 setzen. Das gilt seit dem Hinweis zu CVE-2026-115560 vom 23. Oktober auch als Zwischenlösung bis zum nächsten Bugfix-Release.
PHP 8.5: Zusätzlich fatal_error_backtraces auf 0 setzen.

CISA empfiehlt, PHP-basierte Systeme vom Netz zu nehmen, wenn ein sofortiges Update nicht möglich ist oder PHP 8.1 oder älter läuft. Das BSI rät laut Medienberichten, eine vorübergehende Trennung vom Internet zu erwägen. Seit der Aufnahme in den CISA-Katalog gilt die Ausnutzung als bestätigt, Systeme mit Altversionen sollten Vorrang haben.

Welche Systeme waren betroffen?

Die Lücken lagen in PHP selbst, nicht in den Anwendungen. Betroffen waren deshalb alle Systeme auf einer ungepatchten PHP-Version, darunter CMS wie WordPress, Joomla, Drupal, TYPO3 und Statamic, Shopsysteme wie Magento und Shopware, Laravel-Anwendungen sowie Anwendungen wie Nextcloud. Auch Geräte mit PHP-basierter Weboberfläche, etwa Router, Firewalls oder NAS-Systeme, konnten betroffen sein.

Ein Update der Anwendung oder ihrer Erweiterungen allein reichte nicht aus. Entscheidend war die PHP-Version des Servers. Bei Managed Hosting oder Plattformen mussten Betreiber beim Anbieter nachfragen, ob und wann gepatcht wurde. Mehr zur laufenden Betreuung von Unternehmenssoftware finden Sie in unseren Beiträgen zu Software-Wartung und IT-Betreuung.

Wie hat InnoGE reagiert?

Wir haben 200 Kundensysteme in weniger als zwei Stunden vorbereitet und nach der Veröffentlichung der Patches um 16:00 Uhr aktualisiert.

Möglich ist das nur, wenn Systeme und Anwendungen bekannt sind und ein Update-Ablauf besteht, bevor ein Notfall eintritt. Genau das gehört zu laufender Betreuung: ein Überblick über PHP-Versionen und Abhängigkeiten, ein eingeübter Ablauf für Sicherheitsupdates und Ansprechpersonen, die im Ernstfall sofort handeln.

Sind Ihre Systeme für das nächste Mal gerüstet?

Wir prüfen in einem kostenlosen Erstgespräch, welche PHP-Version bei Ihnen läuft, wo Altversionen stehen und wie ein verlässlicher Update-Ablauf aussehen kann.

Erstgespräch vereinbaren Mehr zur Software-Wartung

Was die Quellen zeigen

Die Angaben stammen aus den offiziellen Meldungen des PHP-Projekts und von CISA, ergänzt um Einordnungen von Sicherheitsfirmen und Medien. Mit direktem Link, damit Sie sich selbst ein Bild machen können.

Belege zu PHP2Shell

Stand: 28. Oktober 2026. Die Lage kann sich weiter ändern, bitte vor Maßnahmen die Angaben auf php.net prüfen.

Quelle	Kernaussage
PHP-Projekt Release-Meldungen (21. bis 26. Oktober 2026)	Sicherheitsupdates 8.5.12, 8.4.27, 8.3.36 und 8.2.35, Backports für 7.4 bis 8.1, informationaler Hinweis zu CVE-2026-115560, Windows-Builds mit Brotli-Fix. Zur Quelle
PHP-Projekt Sicherheitshinweise	Beschreibung beider Schwachstellen. CVE-2026-109618 · CVE-2026-109619
PHP-Projekt Unterstützte Versionen	Ende des Sicherheitssupports: 8.2 am 31. Dezember 2026, 8.3 2027, 8.4 2028, 8.5 2029. Zur Quelle
CISA Alert (21. Oktober 2026) und KEV-Aufnahme (26. Oktober 2026)	Aufforderung zum sofortigen Patchen, später Aufnahme beider CVEs in den Katalog bekannter ausgenutzter Schwachstellen. Zum Alert · Bericht zur KEV-Aufnahme
SecurityWeek (26./27. Oktober 2026)	Entwicklung von Sonden zu funktionierenden Shells auf Honeypots, Bedingungen des Nachweises. Zur Quelle
Wiz (27. Oktober 2026)	Beobachtete Versuche in eigener Telemetrie, Rückgang erreichbarer verwundbarer Rechner, Einfluss von Konfiguration auf die Ausnutzbarkeit. Zur Quelle
Tenable (bis 23. Oktober 2026)	Chronologie, Ausnutzungsversuche, betroffene Versionen, Backports, CISA-Status. Zur Quelle
Sansec (21./22. Oktober 2026)	Einordnung zur Ausnutzung: Öffentliche Exploits funktionierten nicht gegen Standardinstallationen. Zur Quelle
KELA (22. Oktober 2026)	Untergrundaktivität: Proofs of Concept ohne Verifizierung, keine bestätigten Zugangsangebote. Zur Quelle
The Hacker News (Oktober 2026)	Früher Versuch am 17. Oktober (Amazon), Aussagen von Cloudflare, CrowdStrike und weiteren. Zur Quelle
ZfK (22. Oktober 2026)	BSI-Einschätzung vom 22. Oktober, abgeschaltete Webportale, Shodan-Zahl zu Servern mit PHP 8.1 oder älter. Zur Quelle
Matthew Prince (Cloudflare) Beitrag auf X (22. Oktober 2026)	Beobachtungen zu Ausnutzungsversuchen im Cloudflare-Netzwerk. Zum Profil

PHP-Projekt
Release-Meldungen (21. bis 26. Oktober 2026)

Kernaussage: Sicherheitsupdates 8.5.12, 8.4.27, 8.3.36 und 8.2.35, Backports für 7.4 bis 8.1, informationaler Hinweis zu CVE-2026-115560, Windows-Builds mit Brotli-Fix.
Zur Quelle

PHP-Projekt
Sicherheitshinweise

Kernaussage: Beschreibung beider Schwachstellen.
CVE-2026-109618 · CVE-2026-109619

PHP-Projekt
Unterstützte Versionen

Kernaussage: Ende des Sicherheitssupports: 8.2 am 31. Dezember 2026, 8.3 2027, 8.4 2028, 8.5 2029.
Zur Quelle

CISA
Alert (21. Oktober 2026) und KEV-Aufnahme (26. Oktober 2026)

Kernaussage: Aufforderung zum sofortigen Patchen, später Aufnahme beider CVEs in den Katalog bekannter ausgenutzter Schwachstellen.
Zum Alert · Bericht zur KEV-Aufnahme

SecurityWeek
(26./27. Oktober 2026)

Kernaussage: Entwicklung von Sonden zu funktionierenden Shells auf Honeypots, Bedingungen des Nachweises.
Zur Quelle

Wiz
(27. Oktober 2026)

Kernaussage: Beobachtete Versuche in eigener Telemetrie, Rückgang erreichbarer verwundbarer Rechner, Einfluss von Konfiguration auf die Ausnutzbarkeit.
Zur Quelle

Tenable
(bis 23. Oktober 2026)

Kernaussage: Chronologie, Ausnutzungsversuche, betroffene Versionen, Backports, CISA-Status.
Zur Quelle

Sansec
(21./22. Oktober 2026)

Kernaussage: Einordnung zur Ausnutzung: Öffentliche Exploits funktionierten nicht gegen Standardinstallationen.
Zur Quelle

KELA
(22. Oktober 2026)

Kernaussage: Untergrundaktivität: Proofs of Concept ohne Verifizierung, keine bestätigten Zugangsangebote.
Zur Quelle

The Hacker News
(Oktober 2026)

Kernaussage: Früher Versuch am 17. Oktober (Amazon), Aussagen von Cloudflare, CrowdStrike und weiteren.
Zur Quelle

ZfK
(22. Oktober 2026)

Kernaussage: BSI-Einschätzung vom 22. Oktober, abgeschaltete Webportale, Shodan-Zahl zu Servern mit PHP 8.1 oder älter.
Zur Quelle

Matthew Prince (Cloudflare)
Beitrag auf X (22. Oktober 2026)

Kernaussage: Beobachtungen zu Ausnutzungsversuchen im Cloudflare-Netzwerk.
Zum Profil

FAQ – PHP2Shell im Rückblick