Zwei schwerwiegende Schwachstellen im PHP-Kern, Patches seit dem 21. Oktober, erste Angriffsversuche bereits davor. Das wissen Sie mittlerweile.
Die Lücke war bekannt, nur nicht bewertet
Den Kern des Speicherproblems entdeckten Sicherheitsforscher nach eigenen Aussagen bereits 2020 und wieder 2024, beseitigt wurde er nicht, weil die tatsächliche Ausnutzbarkeit nicht nachgewiesen war. Das ist keine Sorglosigkeit der PHP-Entwickler, sondern die Priorisierung der gesamten Industrie. Ohne Exploit kein Handlungsdruck. Sie steckt in Risikoregistern, in Pentest-Berichten mit dem Hinweis „theoretisch“ und in DORA-Risikoakzeptanzen, die ein Management unterschrieben hat. Mit KI-Unterstützung erreichte ein einziger Sicherheitsforscher laut Wiz in einer Woche, wofür sonst ein Expertenteam Monate benötigt. Wer Risiken mit der Erläuterung „praktisch nicht ausnutzbar“ akzeptiert hat, sollte diese Einträge auf Wiedervorlage setzen, bei jeder Komponente mit älteren, unbehobenen Speicherfehlern. Das ist auch ein Nachweisthema. Wer nach einem Sicherheitsvorfall erläutern muss, wie die Bewertung zustande kam, benötigt dafür eine belastbare Erklärung.
Die Versionsnummer sagt nichts
Distributionen und Panel-Hersteller beheben die Lücke in früheren Zweigen oft, ohne die Versionsnummer zu verändern. In einer einzelnen Fix-Übersicht sind 21 Einträge aktualisierte Builds mit gleichbleibender PHP-Version. Wer seinen Patchstand an „php -v“, am Scanner-Befund oder an der Asset-Datenbank festmacht, erhält daher Fehlalarme bei aktualisierten Systemen und keinen belastbaren Nachweis für behobene Systeme. Verlangen Sie den Paket- oder Build-Stand mit CVE-Referenz im Changelog des Herstellers, nicht die Versionsnummer.
PHP steckt dort, wo Sie es nicht suchen
Die Lücke liegt nicht in einzelnen Anwendungen. Forscher zeigten Codeausführung ohne Login gegen aktuelle Versionen von WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony und WHMCS, und die Plesk-Oberfläche läuft auf einer eigenen PHP-Kopie. Unangenehmer ist der Sicherheitsstack selber. Gebräuchliche Dienste wie pfSense und OPNsense sind in PHP programmiert, und Palo Alto Networks führte laut Greenbone alle PAN-OS- und Panorama-Versionen als betroffen und empfahl bis zum Fix, die Management-Oberfläche auf interne Adressen zu begrenzen. Ein weiterer Forscher zeigte in einer Momentaufnahme etwa 76.000 aus dem Internet erreichbare pfSense-Oberflächen. Dann ist das System, das Angriffe abfangen soll, der Einstiegspunkt. Management-Oberflächen gehören nicht ins Internet, losgelöst von PHP. Dazu kommt ein wichtiger Punkt, in virtuellen Appliances und Vendor-Images sieht das übliche Betriebssystem-Patching das integrierte PHP nicht.
Folgeschaden statt Einfallstor
Wer eine Website kompromittiert, erhält deren Besucher, Links und den Ruf der Domain und kann fingierte Verifizierungsabfragen anzeigen. Reputationsbasierte Schutzmaßnahmen wie URL-Kategorisierung, DNS-Filter oder Freigaben für „vertrauenswürdige“ Branchenseiten greifen hier nicht, weil die Seite bis zur Übernahme wirklich vertrauenswürdig war. Für Ihre Endgeräte folgt daraus dreierlei. Halten Sie Browser und Betriebssystem aktualisiert, damit eine veränderte Seite keine bekannte Browserlücke findet. Setzen Sie Endpoint-Schutz ein, der das Verhalten auf dem Computer bewertet statt die Herkunft der Seite. Und sorgen Sie dafür, dass Beschäftigte wissen, keine vertrauenswürdige Website fordert, einen Befehl zu kopieren und im Ausführen-Dialog einzufügen. Dieses Schema, bekannt als ClickFix, benötigt keine Browserlücke. Für Vermittler kommt ein Reputationsrisiko hinzu:
Wird die eigene Website zum Verteiler, sind es die eigenen Kunden, die dort angegriffen werden.
Die Rückschau zählt
Maßgeblich ist nicht, ob Sie inzwischen gepatcht sind, sondern ob ein System zwischen dem Bekanntwerden am 20. Oktober und dem Patch erreichbar war. Angriffsversuche gab es bereits vor der Publikation, öffentliche Proofs of Concept kurz danach. Dem Entdecker zufolge reichen unter Umständen einige Dutzend Anfragen.. Untersuchen Sie daher Webserver- und PHP-Logs im Zeitfenster auf vermehrte Worker-Abstürze, noch sind diese möglicherweise verfügbar, und auffallend umfangreiche Upload-Anfragen. Das sind nachvollziehbare Hinweise.
Weil die Schwachstellen auch Prozessspeicher preisgeben können, in dem Zugangsdaten und Schlüssel liegen, sollten Passwörter, API-Schlüssel und Tokens exponierter und möglicher befallender Systeme rotiert werden.
Was Sie schriftlich erfragen sollten
Welche Systeme verwenden PHP, auch Appliances, Panels und Container, und mit welchem nachgewiesenen Fix-Stand? War irgendein System seit dem 20. Oktober ungepatcht erreichbar, wurden Logs untersucht und Zugangsdaten rotiert? Welche Management-Oberflächen sind aus dem Internet erreichbar? Wo laufen PHP-Versionen ohne Herstellersupport, und bis wann werden sie ersetzt?
PHP2Shell wird nicht die letzte Lücke dieser Art sein. Die PHP Foundation verzeichnet seit dem 1. Juli 15 neu veröffentlichte CVEs und führt den Zuwachs auf KI-Unterstützung zurück. Wer jetzt nur das Update einspielt, hat die Lücke geschlossen, aber die Erkenntnis nicht gezogen. Priorisieren nach „bisher nicht ausgenutzt“ funktioniert nicht mehr, und Patchen innerhalb von Stunden muss zum Regelbetrieb gehören.
