Wenn Sie PHP an irgendeiner Stelle in Ihrem Stack ausführen und kein Upgrade durchgeführt haben, dann mit dem Lesen auf und führen Sie ein Update auf eine gepatchte Version. Weitere Informationen hierzu finden Sie auf unserem Blog mit Sicherheitshinweisen, und schau dir php2shell.aikido.io, um zu prüfen, ob Ihr Dienst potenziell anfällig ist.
Die vergangene Woche war in Sachen Cybersicherheit möglicherweise die ereignisreichste aller Zeiten – und ich glaube nicht, dass ich damit übertreibe. Es gab eine wahre Flut von Sicherheitslücken, doch die größte Schlagzeile machte PHP2shell.
Viele Websites wurden wegen Aktualisierungsarbeiten vorübergehend nicht erreichbar, was viele von uns überraschte, da ein Großteil des Internets nach wie vor auf PHP basiert (nach einigen Angaben sogar70 %!). Das Thema erlangte große Aufmerksamkeit.
PHP2Shell war etwa zwanzig Jahre lang in der PHP-Laufzeitumgebung versteckt, doch dann entdeckten in diesem Jahr innerhalb kurzer Zeit mehrere Gruppen dieselbe Sicherheitslücke. In diesem Monat versuchten Angreifer bereits Tage, bevor PHP überhaupt eine bevorstehende Korrektur angekündigt hatte, diese auszunutzen. KI hat die Spielregeln verändert, und jegliche Indiskretionen über eine Sicherheitslücke oder deren Patches sind gefährlicher als zuvor. Das bedeutet, dass die nächste große Sicherheitslücke möglicherweise ohne große Vorwarnung auftritt und die zuständigen Teams darauf vorbereitet sein müssen, schnell zu reagieren und Patches bereitzustellen.
Wie sich die Enthüllungen zu PHP2Shell entwickelten
Ein Überblick über den zeitlichen Ablauf der PHP2Shell-Enthüllungen, um den Kontext zu verdeutlichen.
Das Speicherüberlauf-Problem, das der ersten der beiden PHP2Shell-Sicherheitslücken zugrunde lag, war bereits bei einem Audit durch OSTIF und Quarkslab im Jahr 2024 aufgetaucht, blieb jedoch unbehoben, da niemand nachgewiesen hatte, dass es ausgenutzt werden konnte. Es wurde im Jahr 2026 erneut entdeckt, als Calif und Wiz die Schwachstellen unabhängig voneinander mit einem Ausnutzungsnachweis entdeckten (Calif meldete dies im Rahmen der „Patch the Planet“-Initiative von OpenAI). Das PHP-Sicherheitsteam bestätigte die Berichte und arbeitete in den folgenden Wochen an Korrekturen für jeden unterstützten Zweig. Die Details wurden bis zur koordinierten Veröffentlichung unter Embargo gehalten.
PHP hatte ursprünglich geplant, die Korrekturen am 22. Oktober zu veröffentlichen. Als die CVE-IDs CVE-2026-109618 und CVE-2026-109619 am 20. Oktober vorzeitig bekannt wurden, veröffentlichte PHP noch am selben Abend um 19:30 Uhr UTC eine Vorankündigung und zog die Veröffentlichung um einen Tag vor, auf den 21. Oktober um 14:00 Uhr UTC.
Aikido Wir gehörten zu einer Gruppe von Organisationen, die frühzeitig informiert wurden, und die Vorbereitungen auf den Patch verliefen chaotisch. Mit jedem neuen Informationsleck stieg die Wahrscheinlichkeit, dass Angreifer noch vor der Veröffentlichung der Patches zuschlagen würden, und die Mitglieder der Gruppe diskutierten darüber, ob sie Abhilfemaßnahmen frühzeitig bekanntgeben oder ihre eigenen Zeitpläne anpassen sollten. Wir sind der Meinung, dass eine koordinierte Offenlegung Unterstützung verdient, daher haben wir unsere gepatchten Images erst nach der Ankündigung von PHP am 21. Oktober veröffentlicht.
Im Vorfeld der Veröffentlichung und noch Stunden danach befand sich ein großer Teil des Internets im Wartungsmodus, während eilig Patches installiert wurden. Censys verfolgt die PHP2Shell-Sicherheitslücke seit dem 21. Oktober. Bis zum 27. Oktober waren etwa 11,2 Millionen PHP-Dienste auf eine gepatchte Version umgestellt worden – das entspricht etwa einem Viertel der Dienste, die eine Version angaben –, während 32,5 Millionen weiterhin eine betroffene Version liefen. Mehr als 60 Millionen PHP-Dienste geben überhaupt keine Version an, sodass die tatsächliche Anzahl der betroffenen Dienste wahrscheinlich höher ist. Verfolgen Sie die aktuellen Zahlen auf der PHP2Shell-Seite von Censys.
Ausnutzungsversuche sind mittlerweile weit verbreitet, und es gab auch bereits einige erfolgreiche Angriffe. In einem öffentlichen Test richtete der Sicherheitsforscher James Pavur einen nicht gepatchten PHP-8.4.26-Server ein , auf dem Bitcoin im Wert von etwa 2.000 US-Dollar als Preis auslobt wurden, und ein Teilnehmer drang etwa drei Stunden, nachdem der Server begonnen hatte, eine Seite mit PHP-Code bereitzustellen, in das System ein.
Der Nachbericht der PHP Foundation und der Bericht von Calif enthalten den vollständigen zeitlichen Ablauf von der Entdeckung bis zur Veröffentlichung des Patches.
KI entdeckt Schwachstellen schneller und in größerer Zahl
PHP ist seit drei Jahrzehnten die treibende Kraft hinter einem Großteil des Internets, weshalb diejenigen, die damit arbeiten, davon ausgingen, dass sie alle schwerwiegenden Fehler bereits entdeckt hätten. „Wir wissen nicht, woher die nächste CVE kommen wird. Und sie könnte in einer Software stecken, an deren Entwicklung in den letzten 20 Jahren noch niemand auch nur gedacht hat“, sagt Benji Kalman, SVP Engineering bei Aikido.
Die PHP2shell-Sicherheitslücke gab es ebenfalls schon seit einigen Jahrzehnten, allerdings als unentdeckter „Geist“. Die Tatsache, dass Calif und Wiz sie im Abstand von nur wenigen Wochen entdeckt haben, macht deutlich, dass KI solche Schwachstellen künftig schneller aufspüren wird.
Wir haben getestet, wie schnell wir diese PHP-Sicherheitslücken selbst aufspüren konnten. Nach der Veröffentlichung haben wir den Dienst „ KI-Codeanalyse “ von Aikido auf PHP gerichtet, und innerhalb weniger Stunden wurde PHP2Shell erneut entdeckt. Wir haben den Dienst bereits auf Open-Source-Bibliotheken angewendet, hatten jedoch die ihnen zugrunde liegenden Sprachen noch nicht getestet.
Die weitere Erforschung solcher Schwachstellen könnte als riskant angesehen werden, wenn dadurch eine Schwachstelle ins Rampenlicht gerückt wird, von der jahrzehntelang niemand etwas wusste. Doch wenn ein Tool der Verteidiger einen solchen Fehler an einem Nachmittag aufspüren kann, werden die Tools der Angreifer nicht lange auf sich warten lassen. Es handelt sich also um eine Art „Gefangenendilemma“ – Angreifer werden anfangen, in allem, was sie finden können, nach Schwachstellen zu suchen, und ihre Tools werden immer besser werden, sodass die Verteidiger nicht im Dunkeln tappen dürfen. Auch die „guten Hacker“ müssen weiterhin nach Schwachstellen in Open-Source-Bibliotheken und -Sprachen suchen. Sicherheitsteams sollten damit rechnen, dass der nächste dringende Patch über Nacht veröffentlicht wird.
Die abgestimmte Offenlegung muss schneller voranschreiten
Mit KI können Angreifer bereits mit sehr wenigen Informationen arbeiten – und genau das macht eine Offenlegung dieser Schwere so schwer zu bewältigen. „Schon ein kleiner Hinweis reicht aus. Man muss nur sagen, dass es eine Sicherheitslücke in PHP gibt – und schon höre ich, wie alle GPUs im Rechenzentrum auf Hochtouren laufen“, sagt Charlie Eriksen, leitender Malware-Forscher bei Aikido. „Wir befinden uns in einer Situation, in der die Zeitspanne zwischen der Entdeckung und der Ausnutzung einer Sicherheitslücke immer kürzer wird, und es gibt so viele verschiedene Akteure, die diese Schwachstellen sehr schnell aufdecken können.“
Durch diese Geschwindigkeit wird eine koordinierte Offenlegung wertvoller denn je, aber es wird auch schwieriger, sie richtig zu handhaben. Warnungen und Vorankündigungen helfen den Betroffenen zwar dabei, sich auf die Installation von Patches vorzubereiten oder Dienste offline zu schalten, geben Angreifern aber gleichzeitig auch Hinweise darauf, wo sie suchen müssen. „Die Warnung kann Ihnen auch Schaden zufügen. Das ist eine wirklich schwierige Dynamik“, sagt Charlie.
Im Fall von PHP2Shell war die Vorankündigung möglicherweise zu weit im Voraus gegenüber der eigentlichen Veröffentlichung geplant. Das PHP-Team hat die Veröffentlichung um einen Tag vorverlegt, sobald die CVE-IDs und POCs auftauchten. Amazon gibt jedoch an, dass die ersten Ausnutzungsversuche am Samstag, dem 17. Oktober, begannen – drei Tage vor der Vorankündigung von PHP am 20. Oktober (über die Gründe dafür können wir keine Spekulationen anstellen).
Sobald ein Patch veröffentlicht ist, stehen Angreifern weitaus mehr Möglichkeiten zur Verfügung als zuvor. Charlie schätzt, dass jemand, der sich damit auskennt, anhand der Patches innerhalb weniger Stunden mit einem LLM einen Exploit erstellen könnte. Im Fall von PHP2Shell hat Trail of Bits mit Codex innerhalb eines Tages einen funktionierenden Exploit entwickelt.
Bei Sicherheitslücken, deren Offenlegung koordiniert erfolgen muss, muss der Prozess schneller und straffer gestaltet werden. Die Sperrfristen sollten kürzer sein, und technische Details sollten so wenige Personen wie möglich erreichen, da jeder zusätzliche Tag und jede weitere Partei das Risiko einer Indiskretion erhöht.
Was kürzere Sperrfristen für die Mehrheit bedeuten
Kürzere, strengere Embargos helfen den Teams, da sie das Zeitfenster für Indiskretionen und vorzeitige Angriffe verkleinern, lassen aber auch allen Beteiligten in den nachgelagerten Bereichen weniger Zeit, sich vorzubereiten.
Der offizielle Patch und der Patch, den ein Team tatsächlich installieren kann, erscheinen nicht immer gleichzeitig. Am Nachmittag, als PHP seinen Patch veröffentlichte, befanden sich die Updates für SUSE und Fedora noch in der Testphase, und Debian unstable lieferte weiterhin die anfällige Version 8.4.26 aus. Bei Shared-Hosting-Lösungen können Website-Betreiber PHP nicht selbst patchen, sodass sie auf ihren Provider warten müssen.
Auch Schutzmaßnahmen sind auf eine frühzeitige Benachrichtigung angewiesen. CDN- und WAF-Anbieter, die im Voraus informiert werden, können bereits am ersten Tag Sperrregeln bereitstellen, wie es „ Cloudflare “ getan hat, als das Unternehmen seine WAF-Regeln noch vor Veröffentlichung des Patches auf alle Tarife – einschließlich des kostenlosen – ausweitete. Sind weniger Anbieter informiert, wird das Sicherheitsnetz erst später aufgebaut. Warnungen können zudem kürzer und vager ausfallen, um Hacker auszubremsen, was den Teams weniger Zeit für die Planung von Wartungsarbeiten lässt.
Sollten die Reaktionszeiten verkürzt werden müssen, müssen Sicherheitsteams sicherstellen, dass sie Warnmeldungen rechtzeitig erhalten und darauf vorbereitet sind, Patches zügig zu installieren – oder über Sicherheitstools verfügen, die dies automatisch erledigen.
Was Teams vor dem nächsten „internetbreaks2shell“ tun können
Das Wichtigste zuerst. Beginnen Sie damit, sich einen Überblick darüber zu verschaffen, was Sie ausführen. „Das Erste, was Sie natürlich wissen müssen, ist: Wie groß ist mein potenzielles Risiko? Erstellen Sie eine Bestandsliste“, sagt Charlie. Diese Bestandsliste muss jede Laufzeitumgebung und jede Abhängigkeit abdecken, die Sie ausführen – auch diejenigen, die Sie nicht selbst installiert haben. PHP2Shell ist ein gutes Beispiel, da PHP häufig in Basis-Images von „ container “, CI-Images, Hosting-Panels und Anbietersoftware vorkommt.
Wählen Sie als Nächstes Ihre Informationsquellen sorgfältig aus. In den ersten Stunden nach dem Auftreten eines Vorfalls halten die nützlichsten Quellen ihre Informationen entsprechend den sich ändernden Umständen auf dem neuesten Stand und beschränken sich nicht nur auf die Beschreibung des Problems, sondern bieten Ihnen auch Maßnahmen zur Risikominderung und vor allem Lösungen, die Sie umsetzen können.
Erkundigen Sie sich bei Ihren derzeitigen oder potenziellen Sicherheitsanbietern, wie diese bei der Bewältigung und Kommunikation solcher Probleme helfen:
- Passen sie ihre Leitlinien an, wenn sich die Nutzung weiterentwickelt?
- Versenden sie Live-Benachrichtigungen zu Vorfällen, sodass die richtige Person davon erfährt, ohne ständig durch Twitter scrollen zu müssen?
- Informieren sie Sie nur über die wichtigsten Vorfälle oder überschütten sie Sie mit einer Flut von irrelevanten Meldungen zu KI-Sicherheitslücken?
- Erklären sie, wie man das Risiko verringern kann, während man auf einen Patch wartet?
- Bekommst du die Korrekturen?
Im Zuge des PHP2Shell-Vorfalls haben wir unseren Sicherheitshinweis im Laufe der Entwicklung des Vorfalls aktualisiert und Live-E-Mails zum Vorfall versendet. Wir haben unter php2shell.aikido.io einen kostenlosen Checker veröffentlicht, mit dem Website-Betreiber testen konnten, ob ihre Websites das PHP2Shell-Verhalten zur Speichererschöpfung aufwiesen.
Außerdem haben wir rückportierte Korrekturen für PHP2Shell über die Aikido -Images bereitgestellt. Die kostenlosen Images im öffentlichen ECR unter Aikido decken PHP 5.5, 5.6, die 7.x-Serie sowie 8.2 bis 8.5 ab und wurden kurz nach der offiziellen Veröffentlichung von PHP bereitgestellt. Teams konnten (und können immer noch!) ein korrigiertes Image nutzen, ohne selbst ein umfangreiches PHP-Upgrade durchführen zu müssen.
„Wir wollen sicherstellen, dass wir, wie wir es nennen, ‚vor Ort‘ Patches installieren. Das heißt also, dass wir euch nicht bitten, auf ein völlig anderes Betriebssystem oder etwas Ähnliches umzusteigen“, sagt Benji. „Es ist so einfach wie das Herunterladen des Images aus dem ECR und das Ersetzen im Dockerfile.“
Wir raten von einem „Renovate“-Verhalten im Bot-Stil ab, bei dem alles automatisch auf die neuesten Versionen aktualisiert wird. Das führt ständig zu Fehlern in Ihrer App, sodass Teams diese Funktion letztendlich deaktivieren. Teams müssen geschützt werden, ohne dabei Sicherheitslücken zu schaffen. Sichern Sie daher die aktuellen Versionen mit Lock-Dateien und führen Sie Upgrades nur durch, wenn CVEs auftreten.
„Das Netz ist riesig und unendlich“
Auch wenn PHP2Shell stressig und etwas chaotisch war, können die Verteidiger dennoch als Sieger hervorgehen.
„Ich denke, die Verteidiger sind derzeit noch im Vorteil. Man muss natürlich schon einiges an Arbeit investieren“, sagte Willem Debare, Geschäftsführer von Aikido, letzte Woche zu den Sicherheitslücken.
Wenn Sie jetzt damit beginnen, Widerstandsfähigkeit aufzubauen, werden Sie zu denen gehören, die noch stehen, wenn sich der Staub und die Code-Puffer gelegt haben.
P.S. Ein Teil des Internets wird das nicht überstehen. Ein Großteil davon läuft immer noch auf alten PHP-Installationen, die nicht mehr gepflegt werden. „The Atlantic“ warnt , dass viele Seiten vom Netz genommen oder gehackt werden und manche vielleicht nie wieder zurückkommen. RIP, wunderschönes Internet der frühen 2000er Jahre.
