PHP2Shell: Kritische PHP-Lücken — was Sie jetzt tun müssen
PHP2Shell kurz erklärt: was passiert ist und was jetzt zählt.
Live-Updates
- 21.10.2026, vormittags: Erstveröffentlichung. Der Patch ist für heute 16:00 Uhr MESZ (14:00 UTC) angekündigt. Betroffene und gefixte Versionen sowie die technische Ursache sind noch nicht offiziell bestätigt — wir ergänzen sie hier, sobald php.net sie veröffentlicht.
Security Advisory · Stand 21. Oktober 2026
Zwei kritische Lücken im PHP-Kern — und die Details sind schon draußen
Das PHP-Sicherheitsteam hat für den 21. Oktober 2026 um 16:00 Uhr MESZ ein Notfall-Release für zwei kritische Schwachstellen angekündigt (CVE-2026-109618 und CVE-2026-109619, beide CVSS 9.2). Sie erlauben nach bisherigem Stand die Ausführung von Code auf dem Server. Eigentlich sollten die Details bis zum Patch geheim bleiben. Sie sind aber einen Tag früher geleakt, samt Screenshot eines Exploit-Werkzeugs namens „PHP2Shell“.
Die Kernaussage: PHP läuft auf einem großen Teil aller Websites, von WordPress bis Shopware. Ein Plugin-Update hilft hier nicht, gepatcht werden muss PHP selbst. Sansec rechnet mit Massenangriffen innerhalb von 15 Minuten nach dem Release. Wer heute erst herausfindet, wo überall PHP läuft, ist zu spät dran.
Was bisher passiert ist
20. Oktober 2026, vormittags
Der Leak
Ein Beitrag auf Hacker News kündigt zwei bevorstehende Remote-Code-Execution-Lücken im PHP-Kern an und wird kurz darauf gelöscht. Screenshots verbreiten sich trotzdem, darunter das Banner eines Exploit-Werkzeugs namens „PHP2Shell“, das dem Sicherheitsforschungsunternehmen Calif.IO zugeschrieben wird und angeblich gegen jede PHP-Version ab 5.4.0 funktioniert.
20. Oktober 2026
Bestätigung durch watchTowr und das PHP-Team
Das Sicherheitsunternehmen watchTowr bestätigt, dass die Lücken echt sind, und gibt an, CVE-2026-109618 reproduziert zu haben. Eigentlich sollte die koordinierte Veröffentlichung erst am Donnerstag erfolgen. Das PHP-Sicherheitsteam zieht den Termin vor und kündigt ein kritisches Sicherheitsrelease an: zwei Lücken, beide mit CVSS v4.0 9.2 bewertet.
21. Oktober 2026, 16:00 Uhr MESZ
Angekündigtes Sicherheitsrelease
Mit dem Release will das PHP-Team betroffene Versionen, gefixte Versionen und technische Details veröffentlichen. Es behält sich vor, früher zu veröffentlichen, falls Details öffentlich werden oder Angriffe auftauchen.
Was bekannt ist — und was nicht
Vor dem Release kursieren viele Zahlen und Gerüchte. Wir trennen bewusst zwischen bestätigt und offen.
Bestätigt oder gut belegt
- Zwei Lücken im PHP-Kern selbst, nicht in WordPress, Shopware oder einem Plugin
- Beide vom PHP-Sicherheitsteam mit CVSS v4.0 9.2 bewertet (kritisch); die kursierende „10.0“ stammt nicht vom PHP-Team
- Laut Sicherheitsforschern führen beide zu Remote Code Execution, also zur Codeausführung auf dem Server
- Nach CERT-EU-Lesart des CVSS-Vektors vermutlich ohne Anmeldung ausnutzbar
- watchTowr hat CVE-2026-109618 nach eigenen Angaben reproduziert
- Bis zum Vormittag des 21. Oktober melden weder Huntress noch watchTowr Angriffe in freier Wildbahn
Noch offen
- Welche Versionen genau betroffen sind: Berichte reichen von „nur PHP 8“ bis „alles ab PHP 5.4“
- Welche Komponente und welcher Angriffsweg: Ein Bericht spricht von einem Use-after-free, inoffizielle Rekonstruktionen von Multipart-Uploads — beides unbestätigt
- Ob bestimmte Konfigurationen (PHP-FPM, mod_php, CGI) Voraussetzung sind
- Ob die CVE-Nummern final sind: Sie stammen aus Sicherheitsberichten, nicht aus der php.net-Ankündigung
Bin ich betroffen?
Bis die betroffenen Versionen offiziell feststehen, gilt: Behandeln Sie jedes PHP-System als verwundbar. Die schwierigere Frage ist meist, wo überall PHP läuft. Diese sechs Stellen werden am häufigsten vergessen.
Eigene Server und VMs
Jeder Webserver mit PHP, egal ob Apache mit mod_php, Nginx mit PHP-FPM oder IIS unter Windows. Prüfen Sie auch interne Werkzeuge, die niemand mehr auf dem Schirm hat: Wikis, Ticketsysteme, Monitoring-Oberflächen, alte Intranets.
Container und Docker-Images
Ein Image wie php:8.1-fpm wird nicht dadurch sicher, dass der Host gepatcht ist. Jedes Image muss neu gebaut und ausgerollt werden — inklusive der Images in Staging, CI-Runnern und alten Kubernetes-Namespaces.
Shared Hosting und Managed Hosting
Hier patcht der Anbieter, nicht Sie. Fragen Sie aktiv nach, wann das Update eingespielt wird und welche PHP-Version Ihr Paket nutzt. Bei Paketen mit wählbarer PHP-Version laufen oft mehrere Versionen parallel.
PHP-Versionen ohne Support
Das PHP-Projekt unterstützt nur noch 8.2 und neuer. Laut Sansec gibt es für 8.1 und älter keinen offiziellen Fix. Wer noch PHP 7 betreibt, braucht einen Backport des Distributors oder Hosters — oder ein Upgrade.
Appliances und Fremdsoftware
Huntress weist darauf hin, dass PHP oft unsichtbar mitgeliefert wird: in Control Panels wie cPanel und Plesk, in Windows-Software, in Netzwerk- und Speicher-Appliances. Diese Systeme aktualisiert nur der Hersteller.
Shops und CMS
Magento, Shopware, WooCommerce, WordPress, Drupal, Joomla, TYPO3: Alle laufen auf PHP. Ein Plugin-Update hilft hier nicht. Die Lücke sitzt eine Schicht tiefer, und Sansec betont, dass der Angriff PHP selbst trifft, bevor Shop-Code oder eine Anwendungs-Firewall überhaupt läuft.
Checkliste: Was Sie jetzt tun sollten
Die erste Hälfte erledigen Sie vor dem Release, die zweite danach. Nichts davon braucht ein großes Budget, nur jemanden, der heute Zeit dafür hat.
Vor dem Patch
Inventar erstellen — heute, nicht morgen
Listen Sie jedes System mit PHP auf, mit Version, Betriebsart (FPM, mod_php, CGI), Erreichbarkeit aus dem Internet und verantwortlichem Team. Ein schneller Anfang: php -v auf jedem Host, und in den Repositories nach FROM php: in Dockerfiles und nach der PHP-Anforderung in composer.json suchen.
Patch-Pfad vorbereiten
Klären Sie jetzt, woher das Update kommt: offizielle Builds, Distributionspakete (Debian, Ubuntu, RHEL und Remi liefern oft mit Verzögerung) oder neu gebaute Container-Images. Wer darf heute Abend Produktionssysteme neu starten? Wer gibt frei?
Übergangsmaßnahmen setzen
Sansec empfiehlt bis zum Patch session.upload_progress.enabled = 0 und session.use_strict_mode = 1. Bei PHP-FPM per php_admin_flag in jeder Pool-Datei, dann den Dienst neu laden und den Wert in einer echten FPM-Anfrage prüfen, nicht auf der Kommandozeile. Sansec sagt ausdrücklich, dass das einen Angriff nicht sicher verhindert.
Was nicht ins Internet muss, raus aus dem Internet
Admin-Oberflächen, Staging-Systeme, alte Instanzen mit PHP 7: hinter VPN, IP-Filter oder abschalten. Jedes System, das von außen nicht erreichbar ist, fällt aus der ersten Angriffswelle heraus.
Erkennung scharf schalten
Huntress empfiehlt, Alarme auszulösen, wenn PHP-Prozesse (php-fpm, php-cgi, apache2, httpd) eine Shell oder Werkzeuge wie curl, wget, nc, python oder perl starten — und auf typische Reverse-Shell-Muster wie /dev/tcp/ oder mkfifo zu achten.
Nach dem Patch
Internet-erreichbare Systeme zuerst patchen
Sansec rechnet mit Massenangriffen innerhalb von 15 Minuten nach dem Release. Die Reihenfolge ist deshalb klar: erst alles, was von außen erreichbar ist, dann interne Systeme.
Den Patch überprüfen, nicht nur einspielen
Kontrollieren Sie die laufende Version in einer echten Webanfrage, nicht per php -v auf der Konsole: CLI und FPM sind oft unterschiedliche Pakete. Bei Distributionspaketen im Changelog nach den CVE-Nummern suchen, denn Backports ändern die Versionsnummer nicht immer.
Auf Einbruchsspuren prüfen
Wer zwischen Leak und Patch exponiert war, sollte nachsehen: neue oder geänderte PHP-Dateien im Web-Root, unbekannte Cronjobs, neue Benutzerkonten, ungewöhnliche ausgehende Verbindungen. Bei Verdacht: System isolieren, Logs sichern, nicht einfach neu aufsetzen.
Zugangsdaten rotieren, wenn Zweifel bleiben
Eine Webshell liest als Erstes die .env-Datei oder die Konfiguration: Datenbankpasswörter, API-Schlüssel, Cloud-Zugänge. War ein System verwundbar und lässt sich ein Einbruch nicht ausschließen, rotieren Sie diese Geheimnisse.
Den Altbestand angehen
Systeme auf PHP 8.1 und älter werden diesmal womöglich gar nicht gepatcht. Planen Sie das Upgrade jetzt, solange die Dringlichkeit allen klar ist.
Wenn Ihnen für das Inventar oder die Prüfung nach dem Patch die Hände fehlen: Melden Sie sich. Wir helfen kurzfristig beim Patchen und prüfen von außen, ob noch verwundbare Systeme erreichbar sind.
Warum KI das Tempo verändert
Früher lagen zwischen einem Patch und dem ersten funktionierenden Exploit oft Wochen. Ein Angreifer musste den Patch verstehen, die Lücke nachvollziehen und einen zuverlässigen Angriff bauen. Das dauert heute nicht mehr lange.
Der Patch ist die Anleitung
Sobald der Fix veröffentlicht ist, zeigt der Vergleich mit dem alten Code, wo die Lücke sitzt. KI-Modelle lesen solche Diffs, erklären die Ursache und schreiben erste Exploits in einem Bruchteil der Zeit, die ein Mensch dafür bräuchte. Darum rechnet Sansec mit Angriffen nach 15 Minuten statt nach Wochen.
KI findet die Lücken selbst
Calif.IO, dem das PHP2Shell-Werkzeug zugeschrieben wird, betreibt KI-gestützte Schwachstellenforschung und hat im Mai 2026 eine 21 Jahre alte Lücke in PHP veröffentlicht. Ob PHP2Shell ebenfalls mit KI gefunden wurde, ist nicht bekannt. Die Richtung ist aber klar: Code, den Menschen jahrzehntelang übersehen haben, wird jetzt systematisch durchsucht — von Verteidigern und Angreifern.
Angreifer nutzen das schon
Im Mai 2026 hat Googles Threat Intelligence Group den ersten Zero-Day-Exploit in einer kriminellen Kampagne gemeldet, der mit hoher Wahrscheinlichkeit mit KI entwickelt wurde. Die Cloud Security Alliance dokumentiert eine Lücke in einem KI-Agenten-Framework, die knapp vier Stunden nach der Veröffentlichung ausgenutzt wurde.
Der klassische Rhythmus — Patch am Dienstag, Einspielen im nächsten Wartungsfenster — passt nicht mehr zu dieser Lage. Entscheidend ist nicht mehr, ob Sie patchen, sondern wie schnell Sie wissen, welche Systeme betroffen sind, und wer sie heute noch aktualisiert.
Das ist zuerst eine Frage der Sichtbarkeit, erst danach eine der Technik.
Was Penetrationstest und Red Teaming hier beitragen
Gegen eine Lücke im PHP-Kern hilft am Ende nur der Patch. Ob Sie den Patch schnell genug einspielen und wie viel Schaden ein Angreifer in der Zwischenzeit anrichten kann, lässt sich aber vorher prüfen. Unsere Experten arbeiten dabei selbst mit KI-Unterstützung, also mit den Methoden, die auch Angreifer einsetzen.
Die Patch-Übung
Wie lange brauchen Sie von der Warnung bis zum letzten gepatchten System? Wir messen das an einem realistischen Szenario: Wer erfährt es, wer entscheidet, welche Systeme werden vergessen? Bei den meisten Unternehmen liegt die ehrliche Antwort bei Tagen — die Angreifer brauchen Minuten.
Was passiert nach der Shell?
Eine RCE-Lücke ist nur der Einstieg. Entscheidend ist, was ein Angreifer als Benutzer www-data erreicht: Datenbank-Zugangsdaten in der Konfiguration, den Cloud-Metadatendienst, das interne Netz, die Backups. Genau diese Frage beantwortet ein Assumed-Breach-Test — wir starten dort, wo eine Webshell landen würde.
Der Blick von außen
Welche Ihrer Systeme verraten ihre PHP-Version im X-Powered-By-Header? Welche Staging-Instanz läuft seit Jahren auf PHP 7? Welche Subdomain kennt niemand mehr? Genau so suchen Angreifer ihre Ziele für die erste Welle aus — automatisiert, über das ganze Internet.
Ausgehender Datenverkehr
Eine Reverse Shell braucht eine Verbindung nach draußen. Darf Ihr Webserver beliebige Ziele im Internet erreichen, ist jede RCE sofort voll nutzbar. Ein Pentest prüft, ob Egress-Filterung und Netzsegmentierung tatsächlich greifen.
Mehr zum Unterschied der beiden Ansätze: Penetrationstest prüft systematisch die Breite, Red Teaming spielt einen echten Angriff mit Ziel durch.
Wie unsere Plattform bei so einem Vorfall hilft
Die Frage „Wo läuft bei uns PHP, und wer ist dafür zuständig?“ sollte in einer Notlage nicht erst gestellt werden. Unsere Engineering Intelligence Platform beantwortet sie von zwei Seiten: aus Ihren Repositories und aus dem Internet.
Von innen
DevInsight: Repositories und Abhängigkeiten
DevInsight ist mit GitHub, GitLab oder Azure DevOps verbunden und erstellt für Ihre Repositories eine Stückliste der Abhängigkeiten (SBOM). Wird eine kritische Lücke bekannt, gleichen wir sie damit ab: Welche Projekte sind betroffen, und welches Team ist zuständig? Bei kritischen Funden informieren wir Ihr Sicherheitsteam und die betroffenen Teams direkt.
DevInsight ansehenVon außen
DevShield: Angriffsflächen-Monitoring
DevShield sieht Ihr Unternehmen so, wie ein Angreifer es sieht: Subdomains, erreichbare Dienste, Server, die ihre PHP-Version preisgeben, vergessene Staging-Systeme. So fallen auch die Systeme auf, die in keinem Repository stehen — Appliances, Fremdsoftware, die alte Kampagnenseite.
DevShield ansehenUnd wenn es brennt: Hilfe beim Beheben
Eine Warnung allein schließt keine Lücke. Wenn Ihrem Team die Zeit fehlt, helfen unsere Entwickler beim Patchen: Images neu bauen, PHP-Versionen anheben, Altsysteme migrieren. Danach prüfen wir von außen, ob die Lücke wirklich geschlossen ist.
Welche Ihrer PHP-Systeme sind von außen sichtbar?
Unser kostenloser Attack-Surface-Check zeigt auf zwei Seiten, was von außen erreichbar ist: Subdomains, offene Dienste, Zertifikate, geleakte Zugangsdaten. Eine Domain genügt — ohne Vertrag, ohne Systemzugriff.
Vorbereitet sein, bevor die nächste Lücke kommt
PHP2Shell wird nicht die letzte kritische Lücke dieses Jahres sein. Diese drei Bausteine sorgen dafür, dass Sie beim nächsten Mal in Stunden statt in Tagen reagieren.
Sehen
Angriffsflächen-Monitoring
Kostenloser Erstcheck, danach kontinuierliches Monitoring ab €249 pro Monat. Wir melden, was neu erreichbar ist — nicht jeden Monat denselben Bestand.
Angriffsflächen-Monitoring ansehenPrüfen
Penetrationstest
Manuelle Prüfung von Web-Anwendungen, APIs und Cloud ab €3.500 — einschließlich der Frage, wie weit ein Angreifer nach einer Codeausführung auf dem Webserver kommt.
Penetrationstest ansehenAngreifen
Red-Teaming-Starter (extern)
Festpreis €2.500. Ein Experte greift mit KI-Unterstützung von außen an, so wie die erste automatisierte Angriffswelle nach einem Leak. Optionaler Retest €300.
Red Teaming ansehenWas wir bewusst nicht versprechen
Wir betreiben kein 24/7-SOC und bieten keinen Incident-Response-Bereitschaftsdienst. Bei einem akuten Einbruch brauchen Sie einen spezialisierten IR-Dienstleister. Was wir liefern: Sichtbarkeit über Ihre Systeme, ehrliche Befunde und Entwickler, die beim Beheben mit anpacken. Weil unser Team jeden Auftrag selbst durchführt, nehmen wir pro Monat nur wenige neue Projekte an.
Quellen
- PHP: Upcoming Critical PHP Security Release (20.10.2026)
- Sansec: Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619 (20.10.2026)
- Huntress: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities (20.10.2026)
- watchTowr: PHP Remote Code Execution FAQ: CVE-2026-109618 & CVE-2026-109619 (21.10.2026)
- SecurityWeek: PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws (21.10.2026)
- Calif: Finding and Exploiting a 21-Year-Old Vulnerability in PHP (01.05.2026)
- Cloud Security Alliance: First AI-Generated Zero-Day Exploit Confirmed in the Wild (12.05.2026)
- Cloud Security Alliance: Sub-4-Hour Weaponization of Agentic AI Frameworks (2026)
Wissen, wo Sie verwundbar sind, bevor es ein Angreifer weiß
Starten Sie mit dem kostenlosen Attack-Surface-Check, oder sprechen Sie direkt mit uns, wenn Sie beim Patchen Unterstützung brauchen. Sie bekommen eine ehrliche Einschätzung, welcher nächste Schritt sinnvoll ist.
