Aufmacher · Schwachstellen
PHP2Shell war vier Tage vor dem Fix im Umlauf, und das meiste, was danach auf den Sensoren einschlug, funktioniert nicht
Zwei kritische PHP-Schwachstellen zur Remote-Code-Ausführung wurden am Mittwochnachmittag gepatcht; Amazons Honeypots beobachteten seit Samstag, wie Angreifer sie ausprobierten.
Das PHP-Sicherheitsteam veröffentlichte am 21. Oktober um 14:00 UTC Notfall-Fixes für CVE-2026-109618 und CVE-2026-109619, gemeinsam als PHP2Shell bekannt, in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 und stellte klar, dass nur ein Update einen Server vollständig schützt. Amazon Threat Intelligence berichtete anschließend, dass seine MadPot-Telemetrie bereits am 17. Oktober Ausnutzungsversuche erfasst hatte, vier Tage bevor jemand außerhalb des engsten Kreises einen Patch einspielen konnte. Brian Krebs bezifferte die Betroffenheit auf nahezu 70 Prozent der Websites, die ihre Kernsoftware aktualisieren müssen; bis Mittwochnachmittag waren Hunderte Seiten offline, während sich die Warnung der Maintainer durch die Hosting-Panels der Welt arbeitete.
Die Branche konnte sich während des Geschehens nicht einigen, wie schlimm es war. SANS hob seinen Infocon unter Verweis auf einen CVSS von 9.4 und frühe Proof-of-Concept-Exploits vor dem Patch auf Gelb; andere Berichte desselben Morgens nannten 9.2. Unangenehm ist der Bericht der PHP Foundation selbst: Eine Prüfung durch KI-Unternehmen im August habe die Aufmerksamkeit geschärft, und einer der beiden Fehler stammt aus dem Jahr 2024 – die Schwachstelle war also zwei Jahre lang ontologisch in Ihrem Bestand vorhanden und hatte lediglich weder Namen noch Logo noch eine CVSS-Debatte. Die einzige Einstellung, die als Workaround herumgereicht wird, reicht laut der Firma, die sie vorgeschlagen hat, allein nicht aus.
Dann kam das Rauschen. Ein Forscher, der ein Honeypot-Netzwerk beobachtet, berichtete, er werde mit php2shell-Exploits überschüttet, die nicht nur nicht funktionieren, sondern meilenweit davon entfernt sind, wie der Fehler tatsächlich funktioniert: Menschen füttern Sprachmodelle mit losen Details, die Modelle fixieren sich auf den String PHP_SESSION_UPLOAD_PROGRESS, und heraus kommt selbstsicherer Session-Poisoning-Code, der auf das völlig falsche Ziel gerichtet ist. Behandeln Sie „Massenausnutzung“ als unbestätigten Begriff, bis Ihre eigene Telemetrie ihn belegt. Währenddessen hat die stille, echte Arbeit begonnen: Okta hat bereits vier Access-Gateway-Schwachstellen einschließlich PHP2Shell gepatcht, behoben in 2026.44.0, und Hersteller auf breiter Front prüfen, ob sie PHP in einer als Appliance gekauften Lösung ausgeliefert haben.
Warum es wichtig istPatchen Sie PHP überall, auch dort, wo PHP das Produkt eines anderen mit Herstelleraufkleber ist, und durchsuchen Sie die Logs ab dem 17. Oktober statt erst ab Mittwoch.
- 1RSSPHP ships emergency patches for critical PHP2Shell…
- 2Security newsPHP2Shell Patches Land as First Exploitation Attemp…
- 3Security newsCritical PHP Vulnerability (CVE-2026-109618, CVE-20…
- 4Security newsPHP2Shell: Two Unpatched Critical PHP RCE Flaws (CV…
- 5Security newsPHP Issues Emergency Patches for Two Critical PHP2S…
- 6RSSAmazon says PHP2Shell exploitation began 4 days bef…