TL;DR: Das Wichtigste
- Die Angreifer begannen vier Tage vor der Veröffentlichung der offiziellen Patches, Server ins Visier zu nehmen, wobei sie durchgesickerte Daten ausnutzten, um automatisierte Erkundungsangriffe über anonymisierte Netzwerke zu starten.
- Sicherheitsforscher haben nachgewiesen, dass ein Exploit den Speicherschutz in Produktionsumgebungen umgehen kann, was den Weg für die Remote-Ausführung beliebigen Codes ebnet.
- Mehrere Regierungen und Gesundheitseinrichtungen haben sich dazu entschlossen, ihre Webdienste vorsorglich abzuschalten, um sich vor möglichen Angriffen zu schützen, bevor die Software-Updates vollständig implementiert sind.
- Die PHP Foundation hat eine dritte Sicherheitslücke im Zusammenhang mit der Verarbeitung von Session-Uploads gemeldet, die eine vorübergehende Deaktivierung dieser Einstellung erfordert, bis der nächste reguläre Patch-Zyklus eintritt.
Die kritischen PHP2Shell-Sicherheitslücken ermöglichen die Remote-Codeausführung auf Webservern, auf denen PHP ausgeführt wird, ohne dass eine vorherige Authentifizierung erforderlich ist, wodurch weltweit Dutzende Millionen Internetdienste gefährdet sind. Die PHP-Engine bildet die Grundlage für fast 80 % aller Websites weltweit, von Content-Management-Systemen wie WordPress bis hin zu Shared-Hosting-Angeboten. Das plötzliche Auftreten dieser Sicherheitslücken im Quellcode der Sprache löste weltweit eine Welle sofortiger böswilliger Aktivitäten aus.
Cyberangreifer nehmen Server ins Visier, noch bevor die Patches veröffentlicht werden
Die ersten Ausnutzungsversuche erfolgten bereits vor den offiziellen Ankündigungen des Open-Source-Projekts. Laut den von BleepingComputer weitergeleiteten Daten von Amazon Threat Intelligence haben Angreifer bereits am 17. Oktober 2026, also vier Tage vor der Bereitstellung der Patches für CVE-2026-109618 und CVE-2026-109619, Testserver abgefragt. Diese Aktivitäten gingen von einem kommerziellen Anonymisierungsnetzwerk aus, was darauf hindeutet, dass technische Details bereits vor Ablauf der Sicherheitssperrfrist durchgesickert waren.
Das Wichtigste zu Cybersicherheit, KI & Tech
Werden Sie Teil der Community. 3-mal pro Woche erhalten Sie die Trendanalyse von Marc Barbezat (auf Französisch). Kein Spam, nur Informationen.
Sobald das Embargo am 21. Oktober 2026 aufgehoben wurde, nahm die Zahl der Angriffe rasant zu. Die Sensoren von Cloudflare verzeichneten innerhalb von 45 Minuten Zehntausende böswilliger Anfragen, bevor die Zahl am nächsten Tag mehrere Millionen erreichte, wie SecurityWeek berichtete. Dennoch war der Grossteil der beobachteten Payloads nicht funktionsfähig: Es handelte sich lediglich um automatisierte Scans, absichtlich ausgelöste Softwareausfälle oder fehlerhafte Machbarkeitsnachweise, die auf GitHub geteilt wurden.
Diese Angriffswelle ging mit einer sofortigen Mobilisierung der IT-Teams einher. Den Daten von Google Trends zufolge stieg der weltweite Interessensindex für das Stichwort „PHP“ am 22. Oktober 2026 auf den Höchstwert von 100 und verzeichnete damit einen Anstieg von 70 % gegenüber dem Vormonat, während die Systemadministratoren nach Notfallmassnahmen suchten.
Die Speichersperre erschwert die Fernsteuerung
Das grösste technische Hindernis für Angreifer ist die Randomisierung des Speicherbereichs, ein in Betriebssysteme integrierter Schutzmechanismus, der die Position der Befehle im Arbeitsspeicher zufällig verändert. Ohne Kenntnis dieser genauen Adresse löst ein Angreifer, der versucht, Code einzuschleusen, in der Regel lediglich einen Absturz der Anwendung aus. Diese Barriere erklärt, warum Sicherheitsfirmen während der ersten Wellen massiver Angriffe keine erfolgreiche Codeausführung festgestellt haben, wie SecurityAffairs berichtet. Varianten des Mirai-Botnetzes, insbesondere der Potassium-Stamm, versuchen bereits, schädliche Dateien unter Linux zu verbreiten, doch ihre Angriffe wurden durch die bestehenden Gegenmassnahmen abgewehrt.
Diese Verteidigung gerät jedoch angesichts der Arbeit der Offensivspezialisten allmählich ins Wanken. Dem VulnCheck-Team ist es gelungen, diese Sicherheitsmassnahme auf 64-Bit-Architekturen zu umgehen, indem es die beiden Schwachstellen kombinierte, um zunächst einen Speicherleck zu verursachen und anschliessend beliebigen Code auszuführen, wie aus den von The Register gesammelten Details hervorgeht. Selbst bei den empfohlenen Produktionsoptionen, die die Anzeige von Fehlermeldungen unterdrücken, ist ihre Methode erfolgreich, was zeigt, dass ein im Speicher residierender Schutz die unverzügliche Anwendung des von den Entwicklern bereitgestellten Patches nicht ersetzen kann.
Analyse
In der Welt der Cybersicherheit stand diese Woche ganz im Zeichen kritischer Sicherheitslücken, von denen PHP betroffen war – jene alte Programmiersprache, die in rund 70 % aller Webanwendungen zum Einsatz kommt. Ähnlich wie bei einem Erdbeben ist nun mit weiteren Nachbeben zu rechnen – so wie den neuen Sicherheitslücken, die am Wochenende bekannt wurden. Es steht mittlerweile fest, dass böswillige Akteure bereits vier Tage vor der Veröffentlichung der Patches damit begonnen haben, die von zwei kritischen Sicherheitslücken zur Remote-Code-Ausführung (RCE) in PHP betroffenen Server zu sondieren, doch die Analyse muss fortgesetzt werden, um das tatsächliche Ausmass der Gefährlichkeit dieser Schwachstellen zu erfassen und insbesondere zu klären, ob gross angelegte Ausnutzungen möglich sind, da es natürlich noch an ausreichendem Abstand zur Bewertung mangelt. Die Entwicklung bleibt also abzuwarten.
Eine weitere Sicherheitslücke kommt hinzu und verlängert die Unsicherheit bezüglich der Server
Kaum hatte die Bereitstellung der ersten Patches begonnen, erschwerte eine neue, davon unabhängige Sicherheitslücke den Administratoren die Arbeit. Diese unter dem Code CVE-2026-115560 aufgeführte Schwachstelle ermöglicht ebenfalls die Ausführung von Code unter bestimmten Konfigurationen und wird durch die am 21. Oktober 2026 veröffentlichten Updates nicht behoben, wie SecurityAffairs berichtet. Das Projektteam empfiehlt, die Fortschrittsanzeige für Session-Uploads bis zum nächsten regulären Software-Update-Zyklus zu deaktivieren.
Die Bewältigung dieser Krise erinnert an die durch Log4Shell ausgelösten Turbulenzen, was auf die extrem weite Verbreitung von PHP und den Umfang der nicht gewarteten Serverflotte zurückzuführen ist. Fachspezifische Erhebungen beziffern die Zahl der noch gefährdeten Server mit Versionen am Ende ihres Lebenszyklus auf über eine Million; diese werden keine automatischen Updates mehr erhalten. Angesichts dieses Restrisikos haben sich mehrere britische Behörden sowie Krankenhäuser dafür entschieden, ihre öffentlichen Plattformen vorsorglich vom Netz zu nehmen, anstatt auf die Bestätigung eines in freier Wildbahn voll funktionsfähigen Exploits zu warten.
Diese rasche Abfolge von Warnmeldungen verdeutlicht die Anfälligkeit der Software-Grundlagen des Internets gegenüber einer allgegenwärtigen, aber veralteten Komponente. Auch wenn die Millionen beobachteter böswilliger Anfragen bislang noch nicht zu bestätigten massiven Eindringversuchen geführt haben, lassen sich die tatsächliche Gefährlichkeit dieser Schwachstellen und ihr Potenzial für kriminelle Automatisierung erst im Rückblick auf die nächsten Wochen (oder Tage?) der technischen Beobachtung einschätzen.
Häufig gestellte Fragen zur PHP2Shell-Krise
Was ist die PHP2Shell-Sicherheitslücke?
PHP2Shell bezeichnet eine Reihe von zwei kritischen Sicherheitslücken, die direkt die PHP-Engine betreffen und es nicht authentifizierten Dritten ermöglichen, bösartigen Code aus der Ferne über einfache HTTP-Anfragen auszuführen. Diese Sicherheitslücken betreffen die Speicherverwaltung des Programms und können potenziell alle Versionen betreffen, die Webanfragen verarbeiten.
Warum haben die massiven Angriffe bislang noch nicht zu nachweisbaren Sicherheitsverletzungen geführt?
Die in Betriebssysteme integrierten Sicherheitsmechanismen, insbesondere die zufällige Zuordnung des Speicherplatzes, verhindern gängige Angriffe, bei denen versucht wird, den genauen Speicherort der zu manipulierenden Funktionen zu ermitteln. Die meisten öffentlich verfügbaren Tools führen zu Systemabstürzen oder Verlangsamungen des Servers, anstatt eine Übernahme der Kontrolle zu erreichen.
Wie können sich Unternehmen vor PHP2Shell schützen?
Die vorrangige Massnahme besteht darin, unverzüglich die von der PHP Foundation veröffentlichten korrigierten PHP-Versionen zu installieren, insbesondere die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Bei Installationen, die nicht sofort aktualisiert werden können, müssen die Teams die Zugriffsrechte des Webprozesses auf das Netzwerk und die Dateien einschränken oder sensible Dienste vorübergehend deaktivieren.
Worin besteht die neue Sicherheitslücke, die nach den ersten Patches entdeckt wurde?
Die Sicherheitslücke CVE-2026-115560 betrifft eine seltene Konfiguration, bei der eine Anwendung den Serialisierungshandler vor dem Start einer Sitzung dynamisch ändert, während die Nachverfolgung von Datei-Uploads weiterhin aktiv bleibt. Die PHP Foundation empfiehlt, diese Einstellung für den Upload-Fortschrittsbericht zu deaktivieren, bis im Rahmen des nächsten Wartungszyklus ein entsprechender Patch veröffentlicht wird.
Weitere Informationen zu diesem Thema
Kritische Sicherheitslücken in PHP
Kritische Sicherheitslücken in PHP Weiterlesen
Keine Paywall. Keine Werbung.
DCOD bleibt dank Ihrer Beiträge frei zugänglich.
