PHP2Shell Wer jetzt handelt, kommt noch vor die Lage

Anbieter zum Thema

cidaas by Widas ID GmbH

Laut Unit 42 laufen rund 22,6 Millionen exponierten Instanzen auf PHP. Aufgrund von zwei Sicherheitslücken, haben viele Organisationen ihre Webseiten gestern vorsorglich abgeschaltet. Nun sind die Patches da. Was jetzt zählt, ist die Reihenfolge.

21. Oktober 2026, 15:34 Uhr. Das PHP-Projekt veröffentlicht zwei Advisories, auf die seit dem Vorabend das halbe Netz wartet. Zwei Sicherheitslücken im Kern der Programmiersprache gefährden weltweit exponierte Instanzen, von WordPress bis zur Firewall-Oberfläche. Dem Sicherheitsteam von Palo Alto Networks, Unit 42, zufolge, läuft PHP auf 22,6 Millionen exponierten Instanzen.

Mögliche Zero Days

Zwei kritische PHP-Schwachstellen bedrohen Millionen Webseiten

Was passiert ist

Am 20. Oktober kündigte das PHP-Sicherheitsteam ein Notfall-Release an, ohne Details, mit Termin: 21. Oktober, 14:00 UTC. CERT-EU und CERT.at warnten noch am Abend vor, das BSI am Vormittag; NCSC-NL meldete um 11:03 Uhr einen öffentlichen Proof-of-Concept. Das Release kam um 15:34 Uhr, knapp vor dem Termin.

Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619, in der Berichterstattung „PHP2Shell“ genannt, sind mit CVSS 4.0 jeweils 9.2 bewertet. Beide sitzen nicht in einer Anwendung, sondern in der Art, wie PHP Anfragen entgegennimmt und wieder aufräumt.

• 1. Ein Angreifer treibt PHP beim Einlesen einer Anfrage gezielt in den Speichermangel. PHP bricht ab, während interne Strukturen erst halb aufgebaut sind, und die Aufräumroutine behandelt diesen Zustand als gültig.

• 2. Ein PHP-Worker bearbeitet viele Anfragen nacheinander. Bricht eine durch einen fatalen Fehler ab, bleiben Verweise auf bereits freigegebenen Speicher stehen, und die nächste Anfrage desselben Workers kann sie benutzen.

In beiden Fällen ist das Ergebnis dasselbe: Codeausführung mit den Rechten des Web-Workers, ohne Anmeldung, ohne Nutzerinteraktion. Gegen Apache mit „mod_php“ hat das PHP-Projekt die Ausnutzung vollständig demonstriert, ein Pfad ist auch gegen PHP-FPM belegt.

Exploit-Code kursiert, eine bestätigte Ausnutzung in freier Wildbahn gibt es bislang nicht; der KEV-Katalog der CISA führt die Lücken nicht. Das BSI geht trotzdem davon aus, dass KI-gestützte Werkzeuge den Patch innerhalb weniger Stunden in einen funktionierenden Exploit übersetzen. Wer den Patch lesen kann, kann den Exploit bauen. Das ist die Lage.

Millionen Webseiten potenziell anfällig

Angreifer richten persistente Webshells über WordPress-Schwachstellen ein

Warum das jeden trifft

Der Fehler liegt nicht in WordPress, TYPO3 oder Nextcloud, sondern in der Laufzeitumgebung darunter. Wer heute sein CMS aktualisiert, hat nichts gewonnen; das PHP muss gepatcht werden, CIRCL sagt das wörtlich. Und PHP läuft, wo es keiner vermutet: in Firewalls wie pfSense und OPNsense, in Zabbix und Roundcube, in den Verwaltungsoberflächen von Netzwerkgeräten und Appliances. Das Schweizer BACS rät deshalb, auch interne und eingebettete Installationen zu prüfen und Lieferanten zu fragen, welche Produkte PHP enthalten. Betroffen sind laut BSI und CERT-FR alle Versionen bis zurück zu PHP 5.

Was jetzt zu tun ist

• 1. PHP finden, auch wo es nicht draufsteht. Webserver, Container-Images, Hosting-Pakete, Admin-Oberflächen, Appliances. Aus dem Internet erreichbare Systeme zuerst, und die warten nicht auf das vollständige Inventar.

• 2. Patchen und jeden Worker neu starten. Fix-Version des eigenen Zweigs (8.5.12, 8.4.27, 8.3.36, 8.2.35) oder das Backport-Paket der Distribution (Debian DSA-6574-1, Ubuntu USN-8948-1). Container neu bauen. Prüfen, was tatsächlich läuft, nicht nur „php -v“, bei Backports bleibt die Versionsnummer gleich. Von Hostern und Herstellern die Behebung bestätigen lassen.

• 3. Wer nicht sofort patchen kann: vom Netz. BSI, CERT-EU und NCSC UK empfehlen, exponierte Systeme vorübergehend zu trennen oder hinter VPN zu stellen. Eine WAF allein genügt nicht, das sagen BSI, BACS und CIRCL übereinstimmend.

• 4. Übergangsmaßnahmen des PHP-Projekts setzen. „session.upload_progress.enabled=0“, „memory_limit=-1“ administrativ, bei PHP 8.5 „fatal_error_backtraces=0“, Multipart-Anfragen am Proxy begrenzen. Jede dieser Maßnahmen schließt nur einzelne Wege; das Update ist die einzige vollständige Abhilfe.

• 5. Logs vor und nach dem Patch durchsehen. Bestätigte Indikatoren gibt es nicht, das BSI warnt ausdrücklich vor den kursierenden IOC-Listen. Was es gibt, sind Spuren aus dem Angriffsweg: Multipart-Anfragen ohne brauchbaren Content-Length oder mit sehr vielen Kopfzeilen, das Feld „PHP_SESSION_UPLOAD_PROGRESS“, abstürzende Worker und Speichererschöpfung vor dem Start eines Skripts, Kindprozesse des Web-Workers, neue Dateien im Webroot, ungewöhnliche ausgehende Verbindungen. Ein Update beseitigt keine bereits erfolgte Kompromittierung.

• 6. Alte Zweige ablösen. PHP 8.1 und älter sind ohne Support, 8.2 endet am 31. Dezember 2026. Die Quell-Backports für 7.4, 8.0 und 8.1 sind eine Notlösung, kein Supportzweig.

Und die Nachweispflicht

NIS2 und § 30 BSIG verlangen Schwachstellenmanagement und die Dokumentation der Einhaltung, DORA dokumentierte Patch-Richtlinien. Ein Nachweis je System mit Datum, Paketversion und Neustart ist heute nicht Bürokratie, sondern der Beleg, den Aufsicht und Auditor nach dieser Lage sehen wollen. Wer jetzt handelt, kommt vor die Lage. Wer zögert, arbeitet sie ab morgen ab, mit Forensik statt Patch-Fenster.

Über den Autor: Daniel Thomas Heessel ist Gründer und Geschäftsführer der Threat-Informed Cybersecurity Solutions GmbH sowie Gründer von certmap.de. Er beschäftigt sich mit bedrohungsorientierter Informationssicherheit und der wirksamen Verbindung von Cybersecurity und Compliance. 2026 wurde er als CISO des Jahres ausgezeichnet.

Stimmungsbild aus der Praxis

Nachweise, Meldefristen und Risikomanagement bremsen NIS 2

(ID:50995792)