Die Installation eines PHP-Patches kann eine Sicherheitslücke schließen. Sie kann Administratoren jedoch nicht sagen, ob Angreifer zuvor Zugriff erlangt haben.
Vor dieser Herausforderung stehen Sicherheitsteams nach den PHP2Shell-Enthüllungen, die im Zentrum des Alarms „Black October“ stehen. Amazon meldete Ausnutzungsversuche vor der öffentlichen Bekanntgabe, während ein separater PHP-Sicherheitshinweis Konfigurationsprüfungen auch für Organisationen vorsah, die die Notfallupdates bereits installiert hatten.
Sicherheitsteams müssen nun klären, ob Angreifer vor dem Patchen Zugriff erlangt haben, ob sie etwas zurückgelassen haben und ob jede exponierte Anwendung die Korrekturen ausführt.
Das Untersuchungsfenster beginnt vor dem Patch
Die anfängliche Störung umfasste vorsorglich vom Netz genommene Websites europäischer Regierungen. Die anschließende Frage lautet, ob exponierte Systeme angegriffen wurden, bevor ihre Betreiber von der notwendigen Reaktion wussten.
Amazon Threat Intelligence meldete einen PHP2Shell-Ausnutzungsversuch gegen seine MadPot-Honeypot-Infrastruktur am 17. Okt., vier Tage vor der öffentlichen Bekanntgabe. Rund um die Veröffentlichung folgten weitere Versuche, doch Amazon erklärte, es sei unklar, ob diese gegen Systeme in der Praxis erfolgreich gewesen wären.
Amazon empfahl, die Untersuchung mindestens ab dem 17. Okt. zu beginnen, statt das Datum des Sicherheitshinweises als Ausgangspunkt zu verwenden. Diese Unterscheidung ist für Organisationen wichtig, deren erste Prüfungen nur den Zeitraum nach Beginn der Patch-Installation abdeckten.
Auch die Beweislage erfordert Sorgfalt. In einer Korrektur vom 25. Okt., nahm Unit 42 von Palo Alto Networks seine frühere Zuordnung eines Angriffs auf eine europäische Regierungsbehörde zu PHP2Shell zurück. Die Forscher beobachteten eine Kompromittierung unter Einbeziehung einer verwundbaren PHP-Anwendung, konnten jedoch nicht bestätigen, dass diese spezifischen CVEs den ursprünglichen Zugriff ermöglichten.
Die Korrektur mindert nicht die Notwendigkeit zu patchen. Sie bedeutet jedoch, dass der gemeldete Vorfall keine erfolgreiche Ausnutzung von PHP2Shell belegen kann.
Ein separater Sicherheitshinweis rückt Konfigurationsprüfungen in den Fokus
Die ursprünglichen Schwachstellen CVE-2026-109618 und CVE-2026-109619 wurden am 21. Okt. in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Anbieter von Distributionen und Versionen mit langfristigem Support stellen möglicherweise zurückportierte Korrekturen bereit. Administratoren sollten daher den Paketstatus ihres Anbieters überprüfen, statt sich ausschließlich auf einen Vergleich der Upstream-Versionen zu verlassen.
Am 23. Okt. veröffentlichte das PHP-Projekt einen Informationshinweis zu einem separaten Problem, CVE-2026-115560, im Zusammenhang mit dem Fortschritt von Sitzungs-Uploads. Dafür ist eine ungewöhnliche Kombination aus Konfiguration und Anwendungsverhalten erforderlich. PHP erklärte, das Problem im regulären Release-Zyklus zu beheben.
Konkret muss eine Anwendung session.serialize_handler als php_binary oder php_serialize konfigurieren und anschließend mit ini_set() auf php umstellen, bevor sie session_start() aufruft. Der Fortschritt von Sitzungs-Uploads muss ebenfalls aktiviert bleiben.
PHP empfiehlt, session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release zu setzen. Dadurch wird die native PHP-Berichterstattung zum Fortschritt von Sitzungs-Uploads deaktiviert. Administratoren sollten daher prüfen, ob ihre Anwendungen darauf angewiesen sind. Für dieses separate Problem erklärt PHP, dass Anwendungen, die den Serialisierungs-Handler zur Laufzeit nie ändern, die Funktion aktiviert lassen können. Die Updates zur Behebung der ursprünglichen PHP2Shell-Schwachstellen benötigen sie trotzdem.
Administratoren, die diese Abhilfe anwenden, müssen eine Konfiguration verwenden, die vor der Verarbeitung von Anfragen wirksam wird, etwa php.ini, den PHP-FPM-Pool oder die Apache-Serverkonfiguration. PHP warnt davor, sich für diese Änderung auf ini_set() auf Anwendungsebene oder PHP-FPM-.user.ini-Dateien zu verlassen.
Red Hats Leitfaden zur Bereitstellung fordert außerdem den Neustart jedes betroffenen Workers; ein Neuladen reicht nicht aus. In containerisierten Bereitstellungen muss der laufende Container oder Pod ersetzt werden. Überprüfen Sie, dass die Anwendung, die Webanfragen verarbeitet, die aktualisierte Einstellung verwendet, statt sich ausschließlich auf die PHP-Konfiguration der Befehlszeile zu verlassen.
Die Deaktivierung des Fortschritts von Sitzungs-Uploads behebt das separate, bedingte Problem, ersetzt aber nicht die ursprünglichen PHP2Shell-Updates. Der spätere Sicherheitshinweis bedeutet nicht, dass diese Updates die ursprünglichen Schwachstellen nicht behoben hätten.
Die Aktualisierung des CMS schließt nicht jede Lücke
Die verwundbare Komponente liegt unterhalb der Website-Anwendung. Wiz-Forscher demonstrierten eine nicht authentifizierte Remote-Code-Ausführung bei WordPress-, Drupal- und Joomla-Bereitstellungen, erklärten jedoch, dass die zugrunde liegenden Schwachstellen in PHP selbst lagen.
Für Organisationen, die es gewohnt sind, auf die Ausnutzung von WordPress-Plugins zu reagieren, ändert das die Prüfaufgabe. Die alleinige Aktualisierung eines Plugins oder Content-Management-Systems zeigt nicht, dass die PHP-Laufzeitumgebung eine Korrektur erhalten hat.
Joseph Perry, Cybersicherheitsforscher und Leiter des Bereichs Advanced Services bei Arcova, beschrieb die Reaktion für E-Commerce- und andere API-basierte Webanwendungen als „kritisches Aktualisierungs- und Überwachungsfenster“.
„Für jeden, der einen Blog oder eine Website betreibt, ist das ein guter Anlass, die Komplexität zu reduzieren, alles zu aktualisieren und bewährte Verfahren konsequent einzuhalten“, sagte Perry.
Eine praktische Anschlussprüfung besteht darin, Hosting- und Anwendungsverantwortliche zu fragen, welche Laufzeitumgebung die jeweilige exponierte Website bereitstellt, welches Anbieterpaket die Schwachstellen behebt und ob laufende Worker und Container das Update tatsächlich übernommen haben.
Der Sicherheitshinweis der National Security Agency empfiehlt außerdem eine erweiterte Protokollierung und den Ersatz veralteter PHP-Dienste, die keine kompatiblen Patches erhalten können. Wo eine sofortige Aktualisierung nicht möglich ist, empfiehlt die Behörde, das System offline zu nehmen, bis es vollständig abgesichert werden kann. Für Administratoren bedeutet das, nicht unterstützte Systeme zu identifizieren – und nicht lediglich Updates auf unterstützten Bereitstellungen zu bestätigen.
Auch temporäre Kontrollen müssen kritisch geprüft werden. Der AWS-Leitfaden zur Abhilfe beschreibt Web Application Firewall-Regeln als zusätzlichen Schutz und betont, dass Patchen die einzige vollständige Lösung ist. Eine blockierte Anfrage sollte nicht zum Beleg werden, mit dem ein Behebungsticket geschlossen wird.
Cloudflare meldete , dass Angreifer ihre Payloads veränderten, um die Schutzmechanismen zu umgehen, während die Analysten von Cloudflare die Erkennungsregeln weiter aktualisierten. Diese Aktivität liefert Verteidigern einen weiteren Grund, temporäre Kontrollen während der gesamten Behebung zu überprüfen, statt ihre ursprüngliche Bereitstellung als Abschluss der Arbeit zu betrachten.
KI verändert, welche Exploits den Aufwand wert sind
Perrys übergreifende Sorge gilt der Wirtschaftlichkeit der Exploit-Entwicklung.
„Dies ist auch ein bemerkenswerter Fall, in dem KI den Exploit nicht unbedingt ermöglicht, sondern praktikabel gemacht hat“, sagte er. „Was der Entwicklung eines solchen Exploits im Weg steht, ist der Bedarf an kontinuierlichem, erschöpfendem Debugging von Plattform zu Plattform und von Version zu Version.“
Die Ergebnisse von Wiz decken sich mit dieser Einschätzung. Die Forscher beschrieben wiederholte Tests und Anpassungen über verschiedene PHP-Versionen, Konfigurationen und Speicherlayouts hinweg und erklärten, dass KI den erforderlichen Aufwand an Spezialistenwissen reduziert habe.
„Beim Schutz vor KI geht es nicht darum, sich gegen futuristische Exploits zu schützen, die sich kein Mensch vorstellen könnte. Es geht darum, sich gegen die Art von Exploits zu schützen, die kein Mensch einsetzen würde, weil sie zu aufwendig sind“, sagte Perry.
Das belegt nicht, dass jeder beobachtete Angriff KI nutzte. Es stellt jedoch die Annahme infrage, dass komplexe Speicherbeschädigungsschwachstellen über viele Ziele hinweg zu kostspielig für eine Ausnutzung bleiben.
„Das bedeutet, dass wir uns weniger darauf konzentrieren sollten, was KI möglich macht, und sehr, sehr viel mehr darauf, was KI praktikabel macht“, sagte Perry.
Das potenzielle Folgeproblem ist bekannt. Frühere Berichte über den Backdoor-Betrieb von WP-SHELLSTORM auf Websites zeigten, wie Angreifer bekannte Schwachstellen nutzten, um dauerhaften Zugriff herzustellen. Das war eine separate Kampagne, verdeutlicht aber, warum die Behebung berücksichtigen muss, was ein Angreifer zurücklassen könnte.
Was Sicherheitsteams vor dem Abschluss der Reaktion klären müssen
Das wichtigste Ergebnis nach dem Black October ist eine dokumentierte Antwort auf drei Fragen: Welche Systeme waren exponiert, wann wurde ihr Schutz wirksam und welche Belege stützen die Zuversicht, dass sie weiterhin vertrauenswürdig sind?
Sicherheitsteams sollten jede öffentlich zugängliche Anwendung mit ihrer tatsächlichen PHP-Laufzeitumgebung und einem verantwortlichen Besitzer verknüpfen. Bei gehosteten Diensten ist eine Bestätigung des Anbieters erforderlich; bei Containern muss bestätigt werden, dass aktualisierte Images die laufenden Workloads erreicht haben. Ein abgeschlossenes Änderungs-Request ist ein schwächerer Beleg als die Überprüfung, dass die Korrektur bereitgestellt wurde.
Die Untersuchung sollte parallel zur Behebung laufen. Prüfen Sie aufbewahrte Telemetriedaten aus Web-, Anwendungs- und Endpunktsystemen mindestens ab dem frühesten bekannten Zieldatum und gehen Sie weiter zurück, wenn die Beweislage dies rechtfertigt. Unerwartete Prozesse, die von Web-Workern gestartet wurden, unbefugte Dateiänderungen oder verdächtige ausgehende Verbindungen verdienen eine Untersuchung, obwohl keines dieser Indizien allein eine Ausnutzung von PHP2Shell beweist. Fehlende Protokolle sollten als Einschränkung der Aussagekraft dokumentiert werden.
Wenn die Beweislage auf eine Kompromittierung hindeutet, ist Patchen als ein Teil der Reaktion auf den Vorfall zu behandeln. Ermitteln Sie den Umfang, entfernen Sie Persistenzmechanismen und prüfen Sie, ob zugängliche Anmeldedaten oder Token ersetzt werden müssen, bevor die Wiederherstellung als abgeschlossen erklärt wird.