PHP2Shell: KI ist nicht die Story
Der letzte Tag von Pompeji, Gemälde Karl Brjullow (1830-1833)
Ich habe gestern eine Notiz über eine Warnung vor zwei kritischen Sicherheitslücken in der Webanwendungs-Programmiersprache PHP geschrieben. Ich habe diesen Beitrag verfasst, weil die Warnung und der bevorstehende Patch den Joy Club, Deutschlands größte Community für Gelegenheitssex, dazu gezwungen haben, seine Website offline zu nehmen. Die beiden Sicherheitslücken (CVE-2026-109618 und CVE-2026-109619) wurden gemeinsam unter dem Namen PHP2Shell zusammengefasst und sind ziemlich gravierend.
Die Beliebtheit von PHP
Ein wichtiger Faktor ist die Verbreitung von PHP selbst. Schätzungen zufolge laufen etwa 70% des Internets auf PHP. Das liegt daran, dass diese Skriptsprache enorm beliebt war, als viele Open-Source-Projekte entwickelt wurden, die sich später sehr weit verbreitet haben. Dazu gehören beliebte Content-Management-Systeme wie WordPress, Drupal, Joomla und MediaWiki (auf dem unter anderem Wikipedia läuft). Aber auch viele andere maßgeschneiderte Webanwendungen und Webseiten sind in PHP geschrieben. Dazu zählen auch zahlreiche Seiten, bei denen Besucher keinerlei Inhalte beitragen und die vollständig statisch sein könnten. Das ist ein großes Problem.
Früher war ich selbst Teil dieses Problems. Viele Jahre lang liefen zahlreiche meiner Webseiten, darunter auch dieses Blog, auf PHP. Zunächst mit WordPress und später mit Drupal. Diese Seiten nutzten PHP hauptsächlich, um Kommentarfunktionen zu implementieren und für das Backend, in dem ich als Autor die Beiträge verfasste. Der Rest der Webseite, der durchaus aus statischem HTML/CSS mit JavaScript und Inhalten aus flat files hätte bestehen können, wurde dennoch bei jedem Aufruf eines Nutzers dynamisch aus einer SQL-Datenbank gerendert. Dadurch ist eine Seite natürlich wesentlich anfälliger für Angriffe als die oben erwähnte statische Alternative.
Später habe ich mein Blog auf Ghost umgestellt, eine modernere CMS-Technologie, die PHP durch serverseitiges JavaScript ersetzt, um Kommentarfunktionen und eine Admin-Oberfläche zu bereitzustellen. Ghost verzichtet außerdem auf eine Datenbank zugunsten von flat files (einfachen Text-Dateien in Ordnern). Obwohl bei Ghost die Seiten nach wie vor bei jeder Nutzeranfrage dynamisch auf dem Server generiert werden, ist das System doch wesentlich stabiler und sicherer als eine Seite, die einen riesigen Berg an PHP-Code ausführt. Einige Zeit später bin ich dann schließlich auf eine statische Webseite umgestiegen, die ich einmalig mit Hugo generiert und anschließend auf einen Server hochgeladen habe. Mittlerweile betreibe ich mein eigenes, selbst zusammengebasteltes System, das auf Client-Seite nicht mal JavaScript verwendet. Ich möchte nicht länger Teil des Problems sein.
Das Problem mit PHP
Das Problem bei einer Sprache wie PHP ist, dass sie auf unzählige Arten angegriffen werden kann. Nicht nur die konkrete Anwendung und deren Plugins können angegriffen werden — im schlimmsten Fall gibt es eine Schwachstelle im Framework oder sogar in der verwendeten Programmiersprache selbst. PHP2Shell ist ein solches Worst-Case-Szenario.
Die beiden nun öffentlich bekannt gewordenen Sicherheitslücken ermöglichen es einem Angreifer, eine PHP-basierte Anwendung über das Internet anzugreifen, indem er bestimmte HTTP-Anfragen an den Webserver sendet, der die PHP-Anwendung bereitstellt. Diese Anfragen müssen sorgfältig zusammengestellt werden und die Ausnutzung hängt davon ab, wie PHP auf dem Server konfiguriert ist. Wenn der Exploit jedoch funktioniert, führen die Anfragen dazu, dass dem PHP-Laufzeitprozess der Speicher ausgeht und er dann beliebigen Code ausführt, den der Angreifer in die Sitzung einschmuggelt. All dies geschieht in der PHP-Laufzeitumgebung, noch bevor Anwendungs-Code ausgeführt wird. Das bedeutet: Es spielt überhaupt keine Rolle, wie die Webanwendung aussieht — die Seite ist allein aufgrund der Verwendung von PHP anfällig.
Die Ausführung von beliebigem Code ist ein weiteres Worst-Case-Szenario bei einem solchen Angriff und bedeutet, dass der Angreifer die Kontrolle über die gesamte Webanwendung übernehmen könnte, möglicherweise sogar über den gesamten Server, auf dem diese läuft. Das erklärt, warum gestern nicht nur Joy Club, sondern auch viele Regierungswebseiten abgeschaltet wurden. Das war wahrscheinlich eine kluge Entscheidung. Es zeigt natürlich, dass die Betreiber dieser Webseiten nicht auf einen Angriff vorbereitet waren; man könnte argumentieren, dass sie nicht viel Ahnung von der Materie hatten, aber mehr dazu später. Sie haben in diesem Moment wahrscheinlich richtig reagiert, so unvorbereitet sie auch waren.
Wieder mal KI-Blödsinn
So gut wie jede Schlagzeile zu dieser Geschichte dreht sich darum, dass diese Schwachstellen mithilfe von KI-Technologien entdeckt wurden. Viele Medien haben genau das zum Kern der Story gemacht. Und natürlich hat Wiz — das Sicherheitsunternehmen, das die Schwachstellen entdeckt und publik gemacht hat — ebenfalls darauf rumgehackt, dass die Schwachstellen mit „Frontier-KI-Modellen“ gefunden wurden. Weil die halt wissen, wie man Aufmerksamkeit erregt, und weil Journalisten zu dumm sind, um zu verstehen, worum es hier eigentlich geht.
Es spielt überhaupt keine Rolle, wie diese Schwachstellen entdeckt wurden. Was man als „KI“ bezeichnet, ist lediglich eine weitere Methode, Daten algorithmisch zu analysieren, um Probleme in Quellcode zu finden. Früher gab es Shodan, jetzt nimmt man LLMs. Als Shodan auf den Markt kam, sahen alle die Welt deswegen untergehen. Das Ende für jegliche Software im Internet! Jetzt ist es halt die KI. Das ist alles Quatsch. Wann werden die Leute endlich aufwachen und begreifen, was hier das eigentliche Problem ist?
Das eigentliche Problem ist, dass Software Scheiße ist. Buchstäblich niemand — außer vielleicht der NASA — schreibt Software, bei der Sicherheit an erster Stelle steht. Ja, das ist teuer, und ja, das bremst die „Innovation“ (was auch immer das eigentlich sein soll) aus, aber es ist auch der einzige Weg, um zu verhindern, dass so etwas wie PHP2Shell passiert.
Das Beunruhigende an diesen Sicherheitslücken ist nicht, dass sie von einer KI entdeckt wurden. Das ist eigentlich gut. Denn es ist gut, dass diese Sicherheitslücken überhaupt entdeckt wurden! Das wirklich Beunruhigende ist, dass diese sehr schwerwiegenden Sicherheitslücken jahrzehntelang im Kern von PHP vorhanden waren, bevor sie entdeckt wurden!
Die Öffentlichkeit hat — wegen ein paar meiner dummen Kollegen in der Presse — ein völlig verkehrtes Verständnis von der Materie. Das betrifft in vielen Fällen sogar Experten auf diesem Gebiet. Wir glauben, es sei schlecht, wenn Sicherheitslücken offengelegt werden, weil dann Panik ausbricht und alle hektisch versuchen, Patches einzuspielen. Aber das ist gut! Schlecht sind die Sicherheitslücken, die noch nicht entdeckt wurden, von denen man nichts weiß. Nur weil man sie nicht kennt, heißt das doch noch lange nicht, dass sie nicht existieren.
Ich weiß, das klingt erst mal widersprüchlich. Aber diese PHP-Sicherheitslücken wurden wahrscheinlich jahrelang (vielleicht sogar jahrzehntelang) von echten bösen Jungs ausgenutzt. Nicht von den Script-Kiddies und Kleinkriminellen, die derzeit Webseiten angreifen, sondern von organisierter Kriminalität und — was noch viel schlimmer ist — von Geheimdiensten auf der ganzen Welt. Das sind Leute, die viel Geld dafür ausgeben, solche Schwachstellen aufzuspüren und diese dann für sich behalten. Sie entdeckten solche Schwachstellen schon seit Jahrzehnten, ohne auf „Frontier-KI-Modelle“ zurückgreifen zu müssen, und mittlerweile sind deren KI-Modelle dieser „Frontier“1 wahrscheinlich um Jahre voraus.
Anstatt sich auf KI zu konzentrieren, sollte die Presse begreifen, worin das eigentliche Problem besteht: Unsere Software ist Scheiße, war schon immer Scheiße und wird — wenn wir so weitermachen mit Vibe-Coding und der Faulheit, KIs statt unserer Hirne zu verwenden — in Zukunft noch scheißiger sein. Und wir stellen jeden Tag mehr wichtige Aspekte unseres Lebens auf diesen Scheiß um. Das ist die eigentliche Geschichte. Das ist es, was wirklich beängstigend ist.
Was wir hier lernen können
Die Lehre hier lautet: Verwende kein PHP. Zumindest nicht für eine einfache Webseite, auf der du Informationen in ein System eingibst, um sie der Öffentlichkeit anzuzeigen. Nutze dafür verdammt noch mal eine statische Webseite. Und verzichte auf SQL-Datenbanken, wenn du kannst. Sei endlich vernünftig!
Wenn du einfache Benutzerinteraktionen benötigst, nimm ein modernes Web-Anwendungs-Framework; die meisten davon basieren heutzutage auf JavaScript. So etwas wie NodeJS oder Ähnliches. Ich kann kaum glauben, dass ich hier JavaScript verteidige, aber generell gilt: Bei öffentlich zugänglichen Anwendungen sollte man die am wenigsten mächtige Sprache und das simpelste Framework verwenden, mit dem man davon kommt. PHP ist einfach zu mächtig. Es stammt aus einer älteren, viel naiveren Ära der Webentwicklung, in der die Leute von den vielen Funktionen berauscht waren und nicht ahnten, dass Angreifer überall lauern. Angreifer, die jede neue Funktion zu einer weiteren Waffe in ihrem Arsenal machen.
Und wenn man komplexe Geschäftslogik im öffentlichen Internet bereitstellen muss und unbedingt auf so etwas wie PHP zurückgreifen will, sollte man unbedingt einen Plan B parat haben. Entweder eine zweite Serverinfrastruktur, die Angriffen ausgesetzt werden kann, während man die Hauptsysteme patcht, oder, noch besser, eine statische Version der Webseite, die zwischenzeitlich als Ersatz online geht. Da ist dann zwar die Benutzerinteraktion deaktiviert, die Besucher können aber immer noch auf alle anderen Informationen zugreifen, während die dynamische Anwendung repariert wird. Außerdem braucht es ein System, das erkennt, ob die Server manipuliert wurden — unabhängig davon, welche Software auf den Servern selbst läuft.
Ich glaube, die wichtigste Erkenntnis hier ist eine, über die ich schon seit Jahren immer wieder schreibe: Weit weniger Webseiten müssen dynamisch sein, als den meisten Menschen bewusst ist. Die meisten der Regierungswebseiten, die in diesem Fall vorsorglich abgeschaltet wurden, bestanden wahrscheinlich zu 99% aus statischen Informationen und zu 1% aus Benutzerinteraktion. Warum sollte man so etwas nicht auf zwei Infrastrukturen aufteilen? Eine vollständig statische, die im Grunde genommen nicht angegriffen werden kann — abgesehen von DDoS-Angriffen oder Angriffen auf den Hoster — und ein weiteres System, das die Geschäftslogik für die Nutzerinteraktion implementiert, stets als Sicherheitsrisiko behandelt wird und in einem Fall wie PHP2Shell dann halt abgeschaltet werden kann, ohne dabei 99% der gesamten Webpräsenz zu verlieren.
Natürlich weiß ich, warum man solche Software so nicht baut. Das ist zu kompliziert und zu teuer. Man müsste die Leute, die das System betreiben, umschulen — und, schlimmer noch, diejenigen, die die Inhalte einstellen auch. Was machen wir also? Wir bleiben bei Scheiß-Software, und wenn dann unvermeidlich etwas schiefgeht, dann geben wir den bösen Hackern die Schuld. Oder heutzutage einfach der KI. Denn dafür ist KI ja vor allem da: um Menschen von jeglicher Verantwortung zu entbinden.
Der eigentliche Brainfuck
Hat sich eigentlich jemand von denen, die seit gestern verzweifelt versuchen, ihre PHP-Installationen zu patchen, einmal die Zeit genommen, über die wirklich beängstigendere Möglichkeit nachzudenken? Dass ihr gesamter Webauftritt möglicherweise schon lange gehackt und von jemandem übernommen wurde, der schon vor Jahrzehnten von diesen Schwachstellen wusste? Von tatsächlich böswilligen Leuten, die Schwachstellen geheim halten und sie in ihrem Hacker-Arsenal sammeln, um jahrzehntelang Böses damit anzustellen, bevor die „Frontier-KI-Modelle“ aufholen. Das ist doch der wirklich beängstigende Gedanke!
Update // 18:39 CEST:
Siehe auch: