Samstag, 24. Oktober 2026
Seit drei Tagen wurde ich mit Meldungen und Mail bombardiert. War ich als Betreiber einer Homepage direkt betroffen? Ja und Nein. Ja, denn Dogado hätte durchaus den Web-Server vom Netz nehmen können. Dann wäre meine Seite nicht mehr erreichbar gewesen. Nein, denn zur Problemlösung konnte ich nichts beitragen.
Wenn Webseiten vorsorglich vom Netz genommen werden
Am 21. Oktober 2026 waren zahlreiche Webseiten und Online-Dienste zeitweise nicht erreichbar. Betreiber hatten ihre Systeme teilweise bewusst abgeschaltet, um sie vor möglichen Cyberangriffen zu schützen. Betroffen waren unter anderem Webhosting-Dienste, Verwaltungsportale und Unternehmensanwendungen.
Zeigt sich hier eine Stärke oder Schwäche der Betreiber. Ich würde eher Stärke vermuten. Eine Schwäche wäre es eher gewesen, die Dinge so weiter laufen zu lassen und nichts zu tun.
In den Niederlanden wurden beispielsweise staatliche Online-Dienste vorübergehend abgeschaltet. Auch Hosting-Unternehmen in Deutschland und Österreich mussten kurzfristig reagieren. Einzelne Anbieter unterbrachen den Betrieb ihrer Webserver vollständig, andere beschränkten den Zugriff auf besonders gefährdete Anwendungen.
Auslöser waren zwei schwerwiegende Sicherheitslücken in PHP, einer der am weitesten verbreiteten serverseitigen Programmiersprachen. Die Schwachstellen erhielten die Kennungen CVE-2026-109618 und CVE-2026-109619 und wurden unter der gemeinsamen Bezeichnung PHP2Shell bekannt.
Beide Schwachstellen wurden nach dem Common Vulnerability Scoring System in der Version 4.0 mit einem Schweregrad von 9,2 auf einer Skala bis 10 bewertet.
Besonders problematisch war, dass ein Angreifer unter bestimmten Voraussetzungen ohne vorherige Anmeldung eigenen Programmcode auf einem betroffenen Server ausführen konnte. Ein Benutzerkonto, ein bekanntes Passwort oder administrative Zugriffsrechte waren dafür nicht erforderlich.
Die Schwachstellen befanden sich nicht etwa in einem schlecht programmierten WordPress-Plugin, sondern unmittelbar in der PHP-Laufzeitumgebung. Damit konnten auch Webseiten betroffen sein, deren eigentlicher Anwendungscode keine entsprechende Sicherheitslücke enthielt.
Tatsächlich kannte ich PHP nicht wirklich richtig. Selbst wenn das Protokoll megawichtig ist, so hatte/habe ich bei meiner Homepage niemals direkt mit PHP zu tun. Folglich musste ich mir erst einmal von der KI erklären lassen, was hier los ist. Ich dachte, dass PHP nur bei dynamischen Seiten wirkt. Meine Homepage ist aber eine statische Seite. Hat ein User einen Blog von mir aufgerufen, steht das Ergebnis statisch auf seinem PC. Selbst wenn ich als Admin wenige Sekunden später einen Tippfehler korrigiere, wirkt sich das auf die beim Leser angezeigte Seite nicht aus. Er muss die Seite erst refreshen, bevor er meine Korrektur sieht. Auf einer dynamischen Seite würde sich das System anders verhalten. Jede Änderung im Hintergrund würde sofort an den PC oder das Mobiltelefon des Lesers geschickt. Auf meiner Seite geschieht das nur auf der Root-Seite, auf der der Schuldenstand Deutschlands eingeblendet wird. Der Zähler geht automatisch nach oben, ohne dass der Leser etwas tun muss.
Weil ich aber die Zusammenhänge nicht kenne, präsentiere ich hier die aus meiner Sicht sehr interessanten Einlassungen von ChatGPT:
PHP als technische Grundlage zahlreicher Webseiten
PHP steht heute für „PHP: Hypertext Preprocessor“. Die Programmiersprache wird auf Webservern ausgeführt, um beispielsweise dynamische Webseiten zu erzeugen, Datenbanken abzufragen, Benutzereingaben zu verarbeiten und Sitzungen zu verwalten.
Zu den bekanntesten PHP-basierten Systemen gehören WordPress, Drupal, Joomla und MediaWiki.
Ruft ein Besucher eine WordPress-Webseite auf, verarbeitet PHP bei einem nicht bereits zwischengespeicherten Seitenaufruf die erforderlichen Anweisungen. WordPress ermittelt den gewünschten Beitrag, fragt gegebenenfalls Inhalte aus der Datenbank ab, berücksichtigt das verwendete Theme – bei mir Astra – und erzeugt daraus eine HTML-Seite.
Der Besucher erhält das fertige HTML-Dokument. Den PHP-Programmcode selbst bekommt sein Browser normalerweise nicht zu sehen.
Gerade diese zentrale Stellung macht Sicherheitslücken in PHP besonders gefährlich. Ein Programmierfehler in einem einzelnen WordPress-Plugin betrifft zunächst nur Installationen dieses Plugins. Ein Fehler in der PHP-Laufzeitumgebung kann dagegen unterschiedliche Webanwendungen gleichzeitig betreffen.
Die Sicherheitsforscher von Wiz Research verwiesen auf die enorme Verbreitung von PHP und darauf, dass die untersuchten Fehler teilweise seit vielen Jahren im Quellcode vorhanden waren.
Die Entdeckung: Ein alter Programmierfehler wird plötzlich ausnutzbar
Die Geschichte von PHP2Shell begann nicht erst im Oktober 2026.
Bereits 2024 gab es Hinweise auf ein verwandtes technisches Problem. Damals ließ sich daraus jedoch kein ausreichend konkreter Angriff ableiten. Die praktische Gefährlichkeit wurde deshalb zunächst unterschätzt.
Im August 2026 gelang es mehreren Sicherheitsforschern, die zugrunde liegenden Fehler deutlich genauer zu untersuchen.
Eine wichtige Rolle spielten dabei Wiz Research, das Sicherheitsunternehmen Calif sowie Forscher aus dem Umfeld von OpenAI. Die Beteiligten arbeiteten mit verschiedenen KI-Modellen, darunter Gemini 4 Argon und GPT-5.6 Sol.
Am 19. August identifizierte Wiz Research nach eigenen Angaben eine der entscheidenden Schwachstellen. Bereits am 20. August konnte eine nicht authentifizierte Remote-Code-Execution gegen Drupal nachgewiesen werden. Einen Tag später gelang ein entsprechender Nachweis auch gegen WordPress.
Am 24. August meldete Wiz die Erkenntnisse dem PHP-Sicherheitsteam.
Die Forscher hatten damit nicht lediglich einen ungewöhnlichen Programmzustand entdeckt. Sie konnten zeigen, dass sich der Fehler unter kontrollierten Testbedingungen in einen tatsächlichen Angriff auf einen Webserver umwandeln ließ.
Das ist in der Sicherheitsforschung ein entscheidender Unterschied.
Ein theoretischer Fehler muss nicht zwangsläufig praktisch ausnutzbar sein. Erst wenn sich die notwendigen technischen Bedingungen zuverlässig herstellen lassen, wird aus einem potenziellen Problem eine nachgewiesene Angriffsmöglichkeit.
Was technisch hinter PHP2Shell steckt
Die beiden veröffentlichten Schwachstellen betreffen die interne Speicherverwaltung von PHP.
Moderne Programme verwenden Arbeitsspeicher, um beispielsweise Variablen, Sitzungsinformationen, Datenstrukturen und Zwischenergebnisse abzulegen. Wird ein Speicherbereich nicht mehr benötigt, muss er wieder freigegeben werden.
Problematisch wird es, wenn ein Programm anschließend weiterhin auf diesen bereits freigegebenen Speicherbereich zugreift.
Ein solcher Programmierfehler wird als „Use-after-free“ bezeichnet.
Bei PHP2Shell kamen weitere Besonderheiten hinzu.
Die erste Schwachstelle, CVE-2026-109618, betrifft die Behandlung von Situationen, in denen PHP während einer Speicheranforderung nicht genügend Arbeitsspeicher zur Verfügung hat. Solche Zustände werden als Out-of-Memory bezeichnet.
Unter bestimmten Bedingungen konnte die Verarbeitung einer HTTP-Anfrage unterbrochen werden, während interne Datenstrukturen nur teilweise initialisiert waren. Spätere Aufräumarbeiten konnten dann auf ungültige oder unvollständige Speicherinhalte zugreifen.
Die zweite Schwachstelle, CVE-2026-109619, betrifft interne Zustandsinformationen, die über die Verarbeitung einer einzelnen Anfrage hinaus erhalten bleiben konnten.
Ein PHP-Prozess bearbeitet häufig nacheinander zahlreiche HTTP-Anfragen. Dabei muss sichergestellt sein, dass temporäre Daten einer abgeschlossenen Anfrage nicht versehentlich in die Verarbeitung der nächsten Anfrage hineinwirken.
Genau diese Trennung war unter bestimmten Umständen nicht ausreichend gewährleistet.
Angreifer konnten dadurch Möglichkeiten erhalten, Speicherinhalte auszulesen oder die Programmausführung zu beeinflussen.
Das potenzielle Ergebnis war besonders schwerwiegend: Remote Code Execution, abgekürzt RCE. Damit bezeichnet man die Möglichkeit, aus der Ferne eigenen Programmcode auf einem fremden System auszuführen.
Welche Rechte ein solcher Code tatsächlich erhält, hängt unter anderem von der Serverkonfiguration und den Berechtigungen des betroffenen PHP-Prozesses ab. Ein erfolgreicher Angriff bedeutet daher nicht automatisch vollständige Kontrolle über das gesamte Betriebssystem. Trotzdem kann bereits der Zugriff mit den Rechten des Webservers erhebliche Schäden verursachen.
Warum ein Angriff auch ohne Benutzeranmeldung möglich war
Eine besonders kritische Eigenschaft der PHP2Shell-Schwachstellen bestand darin, dass relevante Verarbeitungsschritte bereits vor der eigentlichen Ausführung des Anwendungscodes stattfinden konnten.
Wenn ein Webserver eine HTTP-Anfrage entgegennimmt, übernimmt die PHP-Laufzeitumgebung zunächst bestimmte interne Aufgaben. Dazu gehört beispielsweise die Verarbeitung von Anfrageparametern oder hochgeladenen Formulardaten.
Erst anschließend wird der eigentliche PHP-Anwendungscode ausgeführt.
Befindet sich die Sicherheitslücke in dieser frühen Verarbeitungsphase, können klassische Schutzmechanismen einer Webanwendung möglicherweise noch gar nicht greifen.
Eine WordPress-Anmeldung mit Benutzername und Passwort schützt beispielsweise den administrativen Bereich. Sie verhindert aber nicht grundsätzlich, dass der PHP-Interpreter eingehende HTTP-Anfragen verarbeitet.
Auch eine fehlerfrei programmierte Webanwendung kann deshalb durch eine Schwachstelle der darunterliegenden Laufzeitumgebung gefährdet sein.
Sicherheitsforscher konnten erfolgreiche Angriffsketten unter anderem für WordPress, Drupal und Joomla demonstrieren. Das bedeutet nicht, dass jede beliebige Installation unter sämtlichen Bedingungen gleich einfach kompromittiert werden konnte. Die technische Ausnutzbarkeit hing weiterhin von der konkreten Umgebung ab.
Warum Hosting-Anbieter ganze Dienste abschalteten
Nachdem die Sicherheitslücken öffentlich bekannt geworden waren, standen Hosting-Anbieter vor einer schwierigen Entscheidung.
Einerseits sollten Webseiten und Online-Dienste möglichst ohne Unterbrechung erreichbar bleiben. Andererseits konnte ein weiterhin angreifbarer Server zu einer erheblichen Gefahr für Kundendaten und weitere Systeme werden.
Besonders problematisch war, dass die Sicherheitskorrekturen nicht sofort auf sämtlichen Serverplattformen verfügbar waren.
Der PHP-Quellcode wird zwar zentral vom PHP-Projekt gepflegt. Hosting-Anbieter verwenden jedoch häufig speziell zusammengestellte PHP-Pakete, die auf ihre Betriebssysteme und Hosting-Umgebungen abgestimmt sind.
Die Veröffentlichung einer korrigierten PHP-Version bedeutet deshalb nicht automatisch, dass wenige Sekunden später sämtliche Hosting-Server aktualisiert sind.
Manche Betreiber entschieden sich daher, gefährdete Webseiten vorübergehend vom Netz zu nehmen.
Andere setzten zusätzliche Zugriffsbeschränkungen, Sicherheitsregeln oder sogenannte Web Application Firewalls ein.
Diese Maßnahmen konnten das Risiko verringern, waren jedoch kein vollständiger Ersatz für die eigentliche Fehlerkorrektur.
Die zeitweise Abschaltung ist aus technischer Sicht eine Maßnahme zur Reduzierung der Angriffsfläche. Wenn ein gefährdeter Dienst aus dem öffentlichen Internet nicht mehr erreichbar ist, kann er über diesen Zugangsweg zunächst nicht mehr angegriffen werden.
Ob eine vollständige Abschaltung erforderlich ist, hängt allerdings vom konkreten System, seiner Erreichbarkeit und den vorhandenen Schutzmaßnahmen ab.
Wie ein Sicherheitspatch überhaupt entsteht
Ein Sicherheitspatch ist eine gezielte Änderung an einem Programm, mit der ein identifizierter Fehler beseitigt werden soll.
Bei PHP handelt es sich um ein Open-Source-Projekt. Der Quellcode ist öffentlich zugänglich und wird von zahlreichen Entwicklern gepflegt. Ein Teil dieser Arbeit wird über die PHP Foundation finanziert.
Wird eine schwerwiegende Sicherheitslücke entdeckt, beginnt zunächst die technische Analyse.
Die Entwickler müssen verstehen, unter welchen Bedingungen der Fehler auftritt und welche Programmteile dafür verantwortlich sind.
Gerade bei Speicherfehlern ist das häufig aufwendig. Ein sichtbarer Absturz muss nicht an der Stelle entstehen, an der die eigentliche Ursache liegt.
Beispielsweise kann ein Programm einen Speicherbereich fehlerhaft freigeben und erst zahlreiche Verarbeitungsschritte später auf diesen Bereich zugreifen. Der Absturz tritt dann möglicherweise in einer ganz anderen Funktion auf.
Nachdem die Fehlerursache identifiziert wurde, entwickeln die Programmierer eine entsprechende Änderung am Quellcode.
Dabei reicht es nicht unbedingt, nur den unmittelbar auslösenden Programmzustand zu verhindern.
Die Entwickler müssen auch prüfen, ob derselbe grundlegende Fehler an anderen Stellen auftreten kann.
Bei PHP2Shell war genau das besonders wichtig. Die betroffenen Mechanismen waren teilweise tief in die interne Architektur der PHP-Laufzeitumgebung eingebettet.
Wie aus einer Codeänderung ein veröffentlichtes Sicherheitsupdate wird
Die reine Programmänderung ist nur ein Teil des gesamten Vorgangs.
Zunächst erstellen die Entwickler eine korrigierte Fassung der betreffenden Funktionen. Anschließend wird der veränderte Programmcode kompiliert und getestet.
Dabei kommen automatisierte Tests zum Einsatz, die prüfen, ob die bisherige Sicherheitslücke tatsächlich geschlossen wurde.
Besonders wichtig sind sogenannte Regressionstests. Sie sollen verhindern, dass durch die Korrektur an anderer Stelle neue Fehler entstehen oder bisher funktionierende Anwendungen plötzlich ausfallen.
Darüber hinaus werden gezielte Sicherheitstests durchgeführt. Dabei versuchen Forscher, die ursprüngliche Schwachstelle erneut auszulösen.
Gelingt das nicht mehr, ist dies ein wichtiger Hinweis auf die Wirksamkeit des Patches. Ein vollständiger Sicherheitsnachweis ergibt sich daraus allerdings noch nicht.
Zusätzlich müssen unterschiedliche PHP-Versionen berücksichtigt werden.
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt die korrigierten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12.
Ältere PHP-Versionen, die das reguläre Supportende bereits erreicht hatten, erhielten vom PHP-Projekt keine entsprechenden offiziellen Sicherheitsupdates.
Ein Hosting-Anbieter kann solche Korrekturen unter Umständen dennoch selbst in ältere Softwarestände integrieren. Dafür benötigt er jedoch eigene Paketpflege oder entsprechende Unterstützung durch Dritthersteller.
Was bedeutet Backporting?
Viele Hosting-Anbieter wechseln bei einem Sicherheitsupdate nicht automatisch auf die neueste PHP-Hauptversion.
Der Grund liegt in möglichen Kompatibilitätsproblemen.
Eine WordPress-Installation kann beispielsweise mit einer bestimmten PHP-Version einwandfrei funktionieren, während ein älteres Plugin bei einer neueren Version Fehler verursacht.
Deshalb verwenden manche Anbieter das sogenannte Backporting.
Dabei wird eine Sicherheitskorrektur aus einer neuen Programmversion in eine ältere, weiterhin eingesetzte Version übernommen.
Die eigentliche PHP-Versionsnummer muss sich dadurch nicht verändern.
Ein Server kann deshalb weiterhin PHP 8.3.35 anzeigen, obwohl die beiden betreffenden Sicherheitskorrekturen bereits in das vom Hosting-Anbieter bereitgestellte Paket integriert wurden.
Entscheidend ist dann nicht allein die sichtbare Versionsnummer, sondern der tatsächliche Patchstand des installierten Pakets.
Der deutsche Hosting-Anbieter dogado erklärte im Zusammenhang mit PHP2Shell ausdrücklich, solche Sicherheitskorrekturen mittels Backporting in bestehende PHP-Pakete zu integrieren.
Für Betreiber von WordPress-Webseiten bedeutet das, dass eine ältere angezeigte Versionsnummer nicht zwangsläufig eine ungepatchte Installation beweist. Umgekehrt darf aus der Versionsnummer allein aber auch nicht geschlossen werden, dass ein bestimmter Sicherheitspatch vorhanden ist.
Die internationale Zusammenarbeit bei PHP2Shell
Die Behebung der Schwachstellen war keine rein interne Angelegenheit des PHP-Projekts.
Beteiligt waren Sicherheitsforscher, PHP-Entwickler, Cloud-Anbieter, Hosting-Unternehmen und Betreiber großer Internetinfrastrukturen.
Unter anderem arbeiteten Wiz Research, OpenAI, Calif und weitere Beteiligte an der Untersuchung und Verifikation der Sicherheitsprobleme.
Parallel bereiteten Unternehmen wie Cloudflare, Google, AWS und verschiedene Sicherheitsanbieter Schutzmaßnahmen für ihre Kunden vor.
Dabei ging es nicht ausschließlich um die Veröffentlichung neuer PHP-Versionen.
Web Application Firewalls mussten beispielsweise auf verdächtige HTTP-Anfragen vorbereitet werden. Sicherheitsprodukte benötigten neue Erkennungsregeln, und Hosting-Anbieter mussten feststellen, welche ihrer Systeme überhaupt betroffen waren.
Solche abgestimmten Prozesse werden als Coordinated Vulnerability Disclosure bezeichnet.
Sicherheitsforscher informieren die zuständigen Entwickler zunächst vertraulich über ihre Erkenntnisse. Danach erhalten die Verantwortlichen möglichst ausreichend Zeit, eine Korrektur zu entwickeln und deren Veröffentlichung vorzubereiten.
Erst anschließend werden die technischen Einzelheiten öffentlich gemacht.
Damit soll verhindert werden, dass Cyberkriminelle eine vollständig dokumentierte Sicherheitslücke ausnutzen können, bevor Betreiber eine realistische Möglichkeit zur Aktualisierung ihrer Systeme haben.
Bei PHP2Shell geriet dieser Ablauf zeitweise unter erheblichen Druck. Informationen über die Schwachstellen verbreiteten sich bereits vor der geplanten Veröffentlichung. Zudem wurden Teile technischer Demonstrationen vorzeitig öffentlich.
Dadurch verkürzte sich das Zeitfenster für eine geordnete Vorbereitung.
Was KI bei der Entdeckung der Sicherheitslücken geleistet hat
Einer der technisch interessantesten Aspekte des gesamten Vorfalls ist der Einsatz künstlicher Intelligenz.
Die beteiligten Sicherheitsforscher verwendeten moderne KI-Modelle, um umfangreichen Quellcode zu untersuchen, mögliche Fehlerzustände zu analysieren und Angriffsszenarien zu überprüfen.
Ein großes Softwareprojekt wie PHP besteht aus zahlreichen miteinander verbundenen Komponenten.
Ein menschlicher Entwickler kann einzelne Funktionen untersuchen und deren Verhalten nachvollziehen. Besonders schwierig wird die Analyse jedoch, wenn mehrere Funktionen, Speicherzustände und zeitlich aufeinanderfolgende Verarbeitungsprozesse zusammenwirken.
Hier können KI-Systeme unterstützen.
Sie können größere Codebereiche miteinander vergleichen, ungewöhnliche Programmzustände identifizieren, Hypothesen zu möglichen Fehlerursachen formulieren und die Erstellung zusätzlicher Testfälle unterstützen.
Bei PHP2Shell halfen KI-Modelle nach Angaben der beteiligten Forscher auch dabei, komplexe Angriffsketten zu entwickeln und deren Verhalten in unterschiedlichen Testumgebungen nachzuvollziehen.
Das Besondere war nicht, dass eine KI einen einfachen Syntaxfehler entdeckt hätte.
Die eigentliche Leistung bestand darin, aus schwer nachvollziehbaren Speicherfehlern praktisch demonstrierbare Sicherheitsprobleme abzuleiten.
Dabei müssen jedoch die Grenzen solcher Systeme berücksichtigt werden.
Ein KI-Modell kann einen Programmfehler vermuten, der tatsächlich nicht existiert. Ebenso kann es eine Schwachstelle übersehen oder die Ausnutzbarkeit falsch einschätzen.
Deshalb müssen KI-generierte Erkenntnisse weiterhin anhand realer Programmausführung, reproduzierbarer Tests und fachlicher Prüfung bestätigt werden.
Wie Hacker dieselben KI-Fähigkeiten verwenden können
Die Möglichkeiten künstlicher Intelligenz stehen grundsätzlich nicht nur Sicherheitsforschern zur Verfügung.
Auch Cyberkriminelle können KI-Systeme verwenden, um technische Informationen schneller zu verarbeiten, Software zu analysieren und Angriffsmöglichkeiten zu untersuchen.
Der wesentliche Unterschied liegt in der Absicht und der Berechtigung.
Ein Sicherheitsforscher untersucht ein System mit entsprechender Erlaubnis, dokumentiert eine Schwachstelle und unterstützt deren Behebung.
Ein Angreifer versucht dagegen, fremde Systeme ohne Berechtigung zu kompromittieren.
Die zugrunde liegenden technischen Analysefähigkeiten können sich teilweise stark ähneln.
Das betrifft insbesondere die Auswertung öffentlich verfügbarer Quellcodes, die Analyse veröffentlichter Sicherheitskorrekturen und die Identifizierung potenziell verwundbarer Softwarestände.
KI kann diese Tätigkeiten beschleunigen.
Ein Angreifer benötigt dadurch möglicherweise weniger Zeit, um sich in ein unbekanntes Softwareprojekt einzuarbeiten.
Auch die Erstellung von Automatisierungsskripten, die Interpretation von Fehlermeldungen und die Auswertung großer Mengen technischer Daten können durch KI unterstützt werden.
Damit sinken bestimmte Einstiegshürden für Cyberangriffe.
Allerdings bedeutet dies nicht, dass jedes KI-Modell automatisch selbstständig komplexe Sicherheitslücken ausnutzen kann. Die erfolgreiche Durchführung anspruchsvoller Angriffe erfordert weiterhin geeignete Werkzeuge, belastbare technische Informationen, erreichbare Ziele und funktionierende Angriffsketten.
Vom automatisierten Angriff zum KI-gesteuerten Angreifer
Bereits lange vor dem Einsatz generativer KI verwendeten Cyberkriminelle automatisierte Werkzeuge.
Internetweite Portscans, Schwachstellenscanner und Programme zum automatisierten Ausprobieren bekannter Angriffsmethoden gehören seit vielen Jahren zum technischen Instrumentarium von Angreifern.
Generative KI und sogenannte KI-Agenten erweitern diese Möglichkeiten.
Während klassische Automatisierung häufig festen Regeln folgt, können KI-gestützte Systeme Ergebnisse interpretieren und darauf reagieren.
Ein KI-Agent kann beispielsweise technische Befunde auswerten, weitere Analyseschritte auswählen und die Ergebnisse verschiedener Werkzeuge miteinander verknüpfen.
Bei einem autorisierten Sicherheitstest kann das die Effizienz erheblich steigern.
In kriminellen Händen entsteht dagegen die Möglichkeit, größere Mengen potenzieller Ziele mit weniger unmittelbarer menschlicher Steuerung zu untersuchen.
Besonders relevant ist dabei die Kombination aus KI, automatisierter Softwareanalyse und skalierbarer Cloud-Infrastruktur.
Trotzdem sollte zwischen technisch demonstrierten Fähigkeiten und einer vollständig autonomen, zuverlässig arbeitenden Angriffsplattform unterschieden werden.
Komplexe Angriffe können weiterhin scheitern, weil KI-Systeme falsche Annahmen treffen, sich in technischen Details irren oder unerwartete Systemzustände nicht korrekt interpretieren.
Die Gefahr durch die Veröffentlichung eines Sicherheitspatches
Ein zunächst widersprüchlich wirkender Effekt tritt auf, sobald eine Sicherheitskorrektur veröffentlicht wird.
Mit dem Patch wird eine Schwachstelle geschlossen. Gleichzeitig liefert die veröffentlichte Codeänderung möglicherweise Hinweise auf den ursprünglichen Programmierfehler.
Bei Open-Source-Projekten können interessierte Personen den bisherigen und den korrigierten Quellcode miteinander vergleichen.
Dabei lässt sich unter Umständen erkennen, welche interne Programmfunktion verändert wurde und welche fehlerhaften Zustände künftig verhindert werden sollen.
Dieses Vorgehen wird als Patch-Diffing bezeichnet.
Für Sicherheitsforscher ist es ein wichtiges Instrument, um Korrekturen nachvollziehen und ihre Wirksamkeit überprüfen zu können.
Angreifer können dieselbe Methode verwenden, um aus einem veröffentlichten Patch Rückschlüsse auf die zuvor bestehende Schwachstelle zu ziehen.
KI-Systeme können solche Codevergleiche zusätzlich unterstützen.
Dadurch entsteht nach der Veröffentlichung eines Sicherheitsupdates eine besonders kritische Phase.
Die Entwickler haben den Fehler zwar korrigiert, aber noch längst nicht alle Betreiber haben die neue Version installiert.
Gleichzeitig können technische Informationen über die Schwachstelle zunehmend öffentlich verfügbar werden.
Dieses Zeitfenster wird häufig als N-Day-Risiko bezeichnet: Eine Sicherheitslücke ist bereits bekannt und korrigiert, bleibt auf ungepatchten Systemen aber weiterhin ausnutzbar.
Warum KI das zeitliche Gleichgewicht verändern könnte
Traditionell benötigten Sicherheitsforscher und Angreifer teilweise Wochen oder Monate, um komplexe Programmierfehler vollständig zu verstehen und daraus funktionierende Angriffsnachweise abzuleiten.
Bei besonders anspruchsvollen Speicherfehlern können zahlreiche Testläufe erforderlich sein.
KI kann einzelne Arbeitsschritte erheblich beschleunigen.
Dadurch könnte sich die Zeitspanne zwischen der Veröffentlichung eines Sicherheitsupdates und dem Auftreten praktisch nutzbarer Angriffswerkzeuge weiter verkürzen.
Für Betreiber bedeutet das, dass bisherige Updatezyklen möglicherweise nicht mehr ausreichend sind.
Ein Unternehmen, das kritische Sicherheitsupdates grundsätzlich erst mehrere Wochen nach deren Veröffentlichung installiert, könnte künftig ein erheblich höheres Risiko eingehen.
Gleichzeitig profitieren auch Verteidiger von dieser Entwicklung.
KI kann helfen, verdächtige Netzwerkaktivitäten zu analysieren, bekannte Angriffsmuster zu erkennen und notwendige Sicherheitsmaßnahmen schneller zu priorisieren.
Es entsteht damit eine technologische Konkurrenz zwischen der beschleunigten Entwicklung von Angriffsmöglichkeiten und der ebenso beschleunigten Entwicklung geeigneter Gegenmaßnahmen.
Wie künstliche Intelligenz bei der Abwehr helfen kann
Die Anwendungsmöglichkeiten der KI beschränken sich keineswegs auf das Auffinden neuer Programmierfehler.
Auch beim Schutz laufender IT-Systeme ergeben sich zahlreiche Einsatzgebiete.
So können KI-gestützte Analysesysteme große Mengen an Webserver-Protokollen untersuchen und nach Auffälligkeiten suchen.
Dazu gehören ungewöhnliche HTTP-Anfragen, auffällige Fehlerraten, unerwartete Prozessneustarts oder verdächtige Zugriffsfolgen.
Bei PHP2Shell waren unter anderem bestimmte ungewöhnliche HTTP-Anfragen, Speicherfehler und wiederholte Serverfehler potenziell interessante Hinweise für Sicherheitsanalysen.
Einzelne derartige Ereignisse sind allerdings kein Beweis für einen erfolgreichen Angriff.
KI kann ferner dabei helfen, große IT-Landschaften zu inventarisieren und betroffene Softwarestände zu ermitteln.
Das ist insbesondere in Unternehmen wichtig, die zahlreiche Webserver, Container, virtuelle Maschinen und Cloud-Dienste betreiben.
Ein Sicherheitsupdate auf dem zentralen Webserver reicht nicht aus, wenn eine ältere, weiterhin erreichbare PHP-Installation auf einem anderen System vergessen wird.
Darüber hinaus können KI-Werkzeuge Entwickler bei der Überarbeitung sicherheitskritischer Programmfunktionen unterstützen.
Ein sinnvoller Einsatz besteht darin, automatisiert Hinweise auf mögliche Programmfehler zu erzeugen und diese anschließend durch reproduzierbare Tests und menschliche Fachleute überprüfen zu lassen.
Kann KI auch fehlerhafte Sicherheitspatches verhindern?
KI kann dabei helfen, die Qualität von Sicherheitskorrekturen zu verbessern.
Ein Sicherheitspatch muss nicht nur die bekannte Schwachstelle schließen. Er darf möglichst auch keine neuen Sicherheitsprobleme verursachen.
KI-gestützte Codeanalysen können alternative Fehlerzustände aufzeigen und zusätzliche Testfälle vorschlagen.
Bei umfangreichen Softwareprojekten können solche Verfahren besonders hilfreich sein, weil Änderungen an einer zentralen Funktion Auswirkungen auf viele andere Komponenten haben können.
Allerdings kann eine KI selbst fehlerhaften Programmcode erzeugen.
Deshalb sollte eine KI-generierte Korrektur nicht ungeprüft in sicherheitskritische Produktivsysteme übernommen werden.
Erforderlich bleiben nachvollziehbare Codeänderungen, automatisierte Testverfahren, unabhängige Prüfung und eine kontrollierte Veröffentlichung.
Die technische Verantwortung liegt weiterhin bei den Entwicklern und Betreibern der betroffenen Software.
Weshalb Firewalls allein keine vollständige Lösung sind
Einige Hosting-Anbieter und Sicherheitsunternehmen reagierten auf PHP2Shell mit zusätzlichen Regeln für Web Application Firewalls.
Eine solche Firewall untersucht eingehende HTTP-Anfragen und kann auffällige oder bekannte Angriffsmuster blockieren.
Cloudflare entwickelte beispielsweise spezielle Schutzregeln für die PHP2Shell-Schwachstellen.
Das kann das Risiko eines erfolgreichen Angriffs deutlich reduzieren.
Eine Web Application Firewall beseitigt jedoch nicht den zugrunde liegenden Programmierfehler im PHP-Interpreter.
Außerdem können sich Angriffsmethoden verändern. Eine Regel, die einen bestimmten Angriff erkennt, muss nicht zwangsläufig alle Varianten desselben technischen Problems erfassen.
Auch die Abschaltung bestimmter PHP-Funktionen oder Einschränkungen beim Umgang mit HTTP-Anfragen können lediglich Teilmaßnahmen darstellen.
Die vollständige Behebung der beiden ursprünglichen PHP2Shell-Schwachstellen erforderte die Installation entsprechender Sicherheitskorrekturen.
Warum ein installiertes Update nicht automatisch bedeutet, dass ein Server sicher ist
Ein wichtiger Aspekt wird bei der öffentlichen Diskussion über Sicherheitspatches häufig übersehen.
Angenommen, ein Angreifer konnte einen Server bereits vor der Installation des Updates kompromittieren.
Dann verhindert der Patch zwar weitere Angriffe über die geschlossene Sicherheitslücke. Er beseitigt aber nicht automatisch die Folgen eines bereits erfolgreichen Angriffs.
Ein Angreifer könnte beispielsweise Dateien verändert, zusätzliche Zugänge eingerichtet oder vertrauliche Informationen entwendet haben.
Daher muss nach schwerwiegenden Sicherheitsvorfällen zwischen zwei unterschiedlichen Maßnahmen unterschieden werden.
Die erste Maßnahme ist die Beseitigung der technischen Schwachstelle.
Die zweite Maßnahme ist die Untersuchung, ob das betroffene System bereits angegriffen wurde.
Diese Untersuchung wird als Incident Response bezeichnet.
Dazu gehören die Auswertung von Systemprotokollen, die Überprüfung ungewöhnlicher Prozesse, die Kontrolle von Dateiänderungen und gegebenenfalls eine forensische Analyse.
Bei ernsthaften Hinweisen auf eine Kompromittierung kann es notwendig sein, ein System aus einem vertrauenswürdigen Zustand vollständig neu aufzubauen.
Auch Zugangsdaten, API-Schlüssel und andere möglicherweise offengelegte Geheimnisse müssen dann überprüft und gegebenenfalls ersetzt werden.
Ein Sicherheitsupdate ist deshalb eine notwendige Maßnahme, aber nicht automatisch ein Nachweis dafür, dass es zuvor keinen erfolgreichen Angriff gegeben hat.
Welche Verantwortung tragen die Hosting-Anbieter?
Bei einem klassischen Webhosting-Vertrag übernimmt der Hosting-Anbieter wesentliche Teile des technischen Serverbetriebs.
Dazu gehören normalerweise die Pflege des Betriebssystems, der Webserver-Software und der bereitgestellten PHP-Laufzeitumgebung.
Der Betreiber einer WordPress-Homepage ist dagegen häufig selbst dafür verantwortlich, WordPress, Themes und Plugins aktuell zu halten.
Diese Aufgabenteilung ist wichtig.
Wenn ein Sicherheitsproblem unmittelbar in PHP liegt, kann ein gewöhnlicher WordPress-Nutzer die betroffene Laufzeitumgebung auf einem gemeinsam genutzten Hosting-Server normalerweise nicht selbst reparieren.
Er ist darauf angewiesen, dass sein Hosting-Anbieter die entsprechenden Aktualisierungen bereitstellt und korrekt installiert.
Bei einem selbst administrierten Server liegt diese Verantwortung dagegen grundsätzlich beim jeweiligen Betreiber.
Der Vorfall PHP2Shell zeigt außerdem, wie wichtig transparente Informationen über den tatsächlichen Sicherheitsstand sind.
Eine unveränderte Versionsnummer muss nicht zwangsläufig bedeuten, dass ein Sicherheitsupdate fehlt. Allerdings sollte der Anbieter nachvollziehbar bestätigen können, dass die erforderlichen Korrekturen tatsächlich installiert wurden.
Die besondere Situation von WordPress-Webseiten
WordPress gehört zu den weltweit am häufigsten verwendeten Content-Management-Systemen.
Dadurch ist es ein attraktives Ziel für automatisierte Cyberangriffe.
Ein erheblicher Teil der bekannten WordPress-Sicherheitsprobleme entsteht durch veraltete Plugins, unsichere Themes oder fehlerhafte Konfigurationen.
PHP2Shell unterschied sich davon grundlegend.
Hier befand sich die Schwachstelle unterhalb der eigentlichen WordPress-Anwendung.
Auch eine vollständig aktualisierte WordPress-Installation konnte deshalb von einer verwundbaren PHP-Laufzeitumgebung abhängig sein.
Das verdeutlicht einen allgemeinen Grundsatz der IT-Sicherheit: Die Sicherheit einer Anwendung hängt nicht ausschließlich vom Anwendungscode ab.
Auch Betriebssysteme, Laufzeitumgebungen, Webserver, Datenbanken, Bibliotheken und weitere technische Abhängigkeiten gehören zur gesamten Angriffsfläche.
Umgekehrt macht eine aktuelle PHP-Version veraltete oder unsichere WordPress-Plugins nicht automatisch sicher.
Ein zuverlässiger Betrieb erfordert deshalb Aktualisierungen auf mehreren technischen Ebenen.
Was der Vorfall über die Zukunft der Softwareentwicklung aussagt
Die Sicherheitslücken von PHP2Shell verdeutlichen ein grundlegendes Problem moderner Software.
Programme können über viele Jahre erfolgreich eingesetzt werden, obwohl in ihrem Quellcode schwer erkennbare Sicherheitsfehler vorhanden sind.
Solche Fehler bleiben teilweise unentdeckt, weil die notwendigen technischen Bedingungen für einen Angriff ungewöhnlich komplex erscheinen.
Durch KI-gestützte Analysen könnte sich diese Situation verändern.
Fehler, deren praktische Ausnutzung früher als unwahrscheinlich galt, können unter Umständen mit vertretbarem Aufwand untersucht und demonstriert werden.
Das betrifft nicht ausschließlich PHP.
Auch Betriebssystemkerne, Datenbankserver, Netzwerkdienste, Browser und andere umfangreiche Softwareprojekte enthalten komplexe Programmstrukturen, deren vollständiges Verhalten nur schwer zu überprüfen ist.
Gerade Anwendungen, die in speicherunsicheren Programmiersprachen entwickelt wurden, müssen besonders sorgfältig mit Speichergrenzen, Zeigern und der Lebensdauer interner Datenstrukturen umgehen.
Speichersichere Programmiersprachen können bestimmte Fehlerklassen bereits durch ihre technischen Eigenschaften verhindern. Eine vollständige Sicherheit garantieren allerdings auch sie nicht.
Langfristig könnten deshalb neben KI-gestützten Sicherheitsanalysen auch speichersichere Implementierungen und strengere Softwareprüfverfahren an Bedeutung gewinnen.
Die wirtschaftlichen Auswirkungen kritischer Sicherheitslücken
Ein Sicherheitsvorfall dieser Größenordnung verursacht auch dann erhebliche Kosten, wenn kein erfolgreicher Angriff nachgewiesen wird.
Hosting-Anbieter müssen Personal kurzfristig für die Untersuchung und Aktualisierung ihrer Systeme einsetzen.
Unternehmen müssen möglicherweise Anwendungen abschalten und ihre Kunden informieren.
Bei Online-Shops können bereits wenige Stunden Ausfall zu Umsatzeinbußen führen.
Besonders kritisch sind solche Unterbrechungen bei Diensten mit hoher gesellschaftlicher Bedeutung, beispielsweise Verwaltungsportalen oder medizinischen Informationssystemen.
Zusätzlich entstehen Kosten für Sicherheitsanalysen, Softwaretests und die Wiederherstellung des regulären Betriebs.
Dabei müssen die Betreiber eine schwierige Abwägung treffen.
Eine vorsorgliche Abschaltung verursacht einen sicheren, unmittelbar sichtbaren Ausfall. Der mögliche Schaden durch eine erfolgreiche Kompromittierung ist dagegen zunächst ungewiss, kann aber wesentlich größer sein.
Bei einer kritischen, möglicherweise ohne Anmeldung ausnutzbaren Sicherheitslücke kann eine zeitweilige Abschaltung deshalb eine angemessene Maßnahme sein.
Wie lässt sich die Sicherheit großer Softwareprojekte dauerhaft verbessern?
Die Erfahrungen mit PHP2Shell zeigen, dass Sicherheitsupdates allein nicht ausreichen, um langfristig ein hohes Sicherheitsniveau zu gewährleisten.
Entscheidend ist bereits die Entwicklung der Software.
Dazu gehören systematische Codeprüfungen, automatisierte Tests, Fuzzing und die gezielte Analyse sicherheitskritischer Programmfunktionen.
Beim Fuzzing werden Programme mit großen Mengen ungewöhnlicher, fehlerhafter oder zufällig erzeugter Eingaben konfrontiert. Ziel ist es, Abstürze und unerwartete Programmzustände aufzudecken.
KI kann solche Verfahren unterstützen, indem sie aussichtsreiche Testeingaben vorschlägt oder Ergebnisse automatisch auswertet.
Auch die Organisation der Sicherheitsarbeit spielt eine wesentliche Rolle.
Wenn Forscher auf eine potenzielle Schwachstelle aufmerksam machen, müssen entsprechende Hinweise zuverlässig aufgenommen, bewertet und nachverfolgt werden.
Der Hinweis auf einen verwandten Fehler aus dem Jahr 2024 zeigt, dass selbst in etablierten Softwareprojekten die Priorisierung von Sicherheitsmeldungen problematisch sein kann.
Ein zunächst als theoretisch eingestufter Fehler kann später erhebliche praktische Bedeutung erlangen.
Deshalb sind ausreichende finanzielle Mittel, qualifizierte Entwickler und transparente Verfahren zur Bearbeitung von Sicherheitsmeldungen notwendig.
Welche Rolle spielt die PHP Foundation?
PHP ist kein Produkt eines einzelnen Softwareunternehmens.
Die Programmiersprache wird innerhalb eines internationalen Open-Source-Projekts weiterentwickelt.
Die 2021 gegründete PHP Foundation unterstützt diese Arbeit durch die Finanzierung professioneller Entwickler.
Daneben beteiligen sich zahlreiche unabhängige Programmierer und Mitarbeiter verschiedener Unternehmen an der Entwicklung.
Die Sicherheitsarbeit erfordert dabei besonders spezialisiertes Wissen.
Änderungen an der internen Speicherverwaltung einer Programmiersprache können Auswirkungen auf sehr große Teile des gesamten Systems haben.
Deshalb müssen entsprechende Korrekturen sorgfältig entwickelt, getestet und mit weiteren Beteiligten abgestimmt werden.
Der PHP2Shell-Vorfall verdeutlicht auch die Abhängigkeit großer Teile der Internetwirtschaft von vergleichsweise kleinen Entwicklergemeinschaften.
Viele Unternehmen verwenden Open-Source-Software in geschäftskritischen Anwendungen, ohne selbst unmittelbar an deren grundlegender Entwicklung beteiligt zu sein.
Die nachhaltige Finanzierung solcher Projekte ist deshalb nicht nur eine Frage der Softwareentwicklung, sondern auch der Sicherheit digitaler Infrastruktur.
Die neue Dimension: KI als Sicherheitsforscher und potenzieller Angriffsverstärker
PHP2Shell zeigt eine Entwicklung, die für die Cybersicherheit der kommenden Jahre von erheblicher Bedeutung sein dürfte.
Künstliche Intelligenz kann helfen, bislang unentdeckte Schwachstellen in umfangreichen Softwareprojekten aufzuspüren.
Dieselbe technologische Leistungsfähigkeit kann jedoch auch dazu beitragen, dass Angreifer schneller geeignete Angriffsmöglichkeiten finden.
Ein besonderer Risikofaktor besteht darin, dass die Analyse komplexer Software zunehmend automatisiert werden kann.
Damit könnten Fähigkeiten, die früher nur hoch spezialisierten Sicherheitsforschern zur Verfügung standen, für einen größeren Personenkreis zugänglich werden.
Ob daraus tatsächlich eine deutliche Zunahme erfolgreicher Angriffe entsteht, hängt allerdings von vielen Faktoren ab.
Dazu zählen die technische Zuverlässigkeit der KI-Systeme, die Verfügbarkeit geeigneter Werkzeuge, der tatsächliche Schwierigkeitsgrad der Sicherheitslücken und die Geschwindigkeit der Verteidiger.
Eine pauschale Aussage, dass KI künftig jedes IT-System kompromittieren könne, wäre technisch nicht begründet.
Gleichzeitig wäre es ebenso problematisch, die Entwicklung ausschließlich als Unterstützung für Softwareentwickler zu betrachten.
KI besitzt im Bereich der Cybersicherheit einen ausgeprägten Dual-Use-Charakter. Dieselben Verfahren können sowohl zum Schutz als auch zum Angriff auf IT-Systeme eingesetzt werden.
Für Unternehmen und Betreiber digitaler Dienste gewinnt deshalb die Fähigkeit an Bedeutung, Sicherheitslücken frühzeitig zu identifizieren, ihre tatsächliche Gefährlichkeit zu bewerten und notwendige Korrekturen schnell und kontrolliert bereitzustellen.
Was nach PHP2Shell bleibt
Der Vorfall vom Oktober 2026 zeigt, dass selbst eine jahrzehntelang entwickelte und weltweit eingesetzte Programmiersprache schwerwiegende, über lange Zeit unentdeckte Sicherheitsprobleme enthalten kann.
Die Entdeckung solcher Schwachstellen ist ein technisch anspruchsvoller Prozess. Ihre Behebung erfordert qualifizierte Entwickler, umfassende Tests und eine enge internationale Zusammenarbeit.
Die anschließende Verteilung der Sicherheitsupdates stellt eine weitere Herausforderung dar. Zwischen dem korrigierten Quellcode und einem tatsächlich abgesicherten Produktivsystem liegen häufig zahlreiche technische und organisatorische Schritte.
Gleichzeitig verändert künstliche Intelligenz die Geschwindigkeit, mit der komplexe Software untersucht werden kann.
PHP2Shell ist damit nicht nur ein Beispiel für zwei kritische Sicherheitslücken. Der Vorfall macht sichtbar, wie eng Softwarequalität, Open-Source-Entwicklung, Internetinfrastruktur, organisierte Sicherheitsforschung und KI-gestützte Analysetechnologien inzwischen miteinander verbunden sind.
Für die Sicherheit des Internets wird künftig nicht allein entscheidend sein, wie schnell neue Schwachstellen gefunden werden. Mindestens ebenso wichtig ist, wie zuverlässig die Erkenntnisse geprüft, in sichere Programmänderungen umgesetzt und auf Millionen produktiver Systeme verteilt werden können.
Entdecken Sie mehr von Michael Behrens
Melden Sie sich für ein Abonnement an, um die neuesten Beiträge per E-Mail zu erhalten.