KI, PHP2Shell und IT-Sicherheit: Warum Patches allein nicht reichen

Wenn KI Sicherheitslücken schneller findet, als wir sie schließen können

Warum PHP2Shell zeigt, dass wir IT-Sicherheit grundsätzlicher denken müssen

Wir haben inzwischen Werkzeuge, die Sicherheitslücken möglicherweise schneller entdecken können, als Entwickler und Administratoren sie beseitigen können. Und genau darin liegt ein Problem, das wir in der IT-Sicherheit bisher nur unzureichend berücksichtigt haben.

Ein System kann gestern noch nach allen bekannten Sicherheitsstandards als sicher gegolten haben und heute plötzlich als kritisch verwundbar eingestuft werden. Obwohl niemand eine einzige Zeile Code verändert hat. Die Schwachstelle war möglicherweise schon seit Jahren vorhanden. Neu ist lediglich, dass sie jetzt entdeckt wurde und unter Umständen auch ausgenutzt werden kann.

Das ist ein entscheidender Unterschied.

KI erzeugt in solchen Fällen nicht die Sicherheitslücke. Sie verändert, wie schnell wir sie entdecken und wie schnell daraus ein praktischer Angriff entstehen kann.

Damit verändert sich nicht zwangsläufig die technische Ursache unserer Sicherheitsprobleme, wohl aber die Geschwindigkeit, mit der wir darauf reagieren müssen.

PHP2Shell: Ein aktuelles Beispiel

Am 21. Oktober 2026 sorgten zwei kritische Sicherheitslücken in PHP weltweit für erhebliche Unruhe.

Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 ermöglichen unter bestimmten Bedingungen die Ausführung von Schadcode auf betroffenen Systemen. Das Problem betrifft nicht irgendeine exotische Software, sondern PHP – eine der grundlegenden Technologien zahlreicher Webanwendungen. Betroffen sind damit potenziell klassische Webserver, Content-Management-Systeme, Unternehmensanwendungen und andere Produkte, die PHP verwenden.

Was den Vorfall besonders bemerkenswert macht: Die Fehler reichen weit in die Entwicklungsgeschichte von PHP zurück. Es handelt sich also nicht einfach um Sicherheitslücken, die erst mit einem aktuellen Softwareupdate entstanden sind. Die betroffenen Systeme konnten über lange Zeit unauffällig betrieben werden. Erst die Entdeckung und die anschließende Veröffentlichung der Schwachstellen haben die Risikobewertung schlagartig verändert.

Das verdeutlicht ein grundsätzliches Problem:

Ein erfolgreich abgeschlossener Sicherheitstest bedeutet nicht, dass ein System frei von unbekannten Schwachstellen ist.

Er bedeutet zunächst nur, dass mit den eingesetzten Methoden keine entsprechenden Fehler gefunden wurden.

Wenn KI auf KI trifft

Der SPD-Digitalpolitiker Johannes Schätzl fordert angesichts des PHP2Shell-Vorfalls eine stärkere Rolle des Bundesamtes für Sicherheit in der Informationstechnik (BSI).

Das BSI soll Schwachstellen frühzeitig erkennen, Betreiber unterstützen und selbst moderne KI-Werkzeuge einsetzen. Diese Forderung halte ich grundsätzlich für richtig. Allerdings müssen wir uns darüber im Klaren sein, was daraus entsteht.

Ein technisches Wettrüsten.

Auf der einen Seite können KI-Systeme große Mengen Quellcode analysieren, ungewöhnliche Programmzustände untersuchen und bisher unbekannte Fehler aufspüren. Auf der anderen Seite können dieselben technologischen Fähigkeiten dazu beitragen, aus gefundenen Schwachstellen schneller funktionsfähige Exploits zu entwickeln. Die Verteidiger setzen wiederum KI-Systeme ein, um auffällige Aktivitäten, Angriffsmuster und Schwachstellen frühzeitig zu erkennen. Das klingt zunächst nach einem technologischen Gleichgewicht.

Aber es gibt einen entscheidenden Unterschied:

Einen Fehler zu entdecken oder auszunutzen ist nicht dasselbe, wie ihn zuverlässig zu beheben.

Ein Sicherheitsupdate muss entwickelt, getestet und veröffentlicht werden. Anschließend muss es in möglicherweise Tausenden unterschiedlichen Systemumgebungen installiert werden. Im Enterprise-Umfeld kommen Abhängigkeiten zu weiteren Anwendungen, Freigabeprozesse, Wartungsfenster und mögliche Betriebsunterbrechungen hinzu. Wer schon einmal eine geschäftskritische Infrastruktur betreut hat, weiß, dass sich ein Patch nicht immer einfach innerhalb weniger Minuten produktiv einspielen lässt. Selbst wenn die Sicherheitslücke innerhalb kürzester Zeit erkannt wird, verschwindet damit nicht der operative Aufwand ihrer Beseitigung.

Ich sehe deshalb die Gefahr, dass sich der Engpass der IT-Sicherheit zunehmend verschiebt:

Weg von der reinen Entdeckung von Schwachstellen, hin zur Geschwindigkeit und Zuverlässigkeit ihrer Behebung.

Warum wir Updates trotzdem nicht abschaffen können

Johannes Schätzl erklärte im Zusammenhang mit PHP2Shell, dass es nicht ausreichen könne, bekannt gewordenen Sicherheitslücken immer nur mit Updates hinterherzulaufen. Ich verstehe den Gedanken dahinter.

Aber welche realistische Alternative gibt es?

Selbst wenn wir heute sämtliche verfügbare Software mit den leistungsfähigsten KI-Modellen analysieren würden, könnten zukünftige Modelle morgen weitere Fehler entdecken. Das ist kein Widerspruch, sondern eine grundsätzliche Eigenschaft komplexer Software. Wir können bestimmte Programmeigenschaften mathematisch verifizieren. Bei einem gesamten IT-System aus Betriebssystem, Webserver, PHP-Laufzeitumgebung, Datenbank, Bibliotheken, Netzwerkkomponenten und Anwendungen wird ein umfassender Nachweis der Sicherheit allerdings erheblich schwieriger.

Außerdem entstehen Risiken nicht ausschließlich durch Programmierfehler. Fehlkonfigurationen, kompromittierte Zugangsdaten, unsichere Schnittstellen und unerwartete Wechselwirkungen zwischen Komponenten bleiben weiterhin relevant. Deshalb halte ich es für unrealistisch, dass wir irgendwann auf Sicherheitsupdates verzichten können. Patches werden notwendig bleiben.

Die eigentliche Frage sollte vielmehr lauten:

Wie bauen wir IT-Systeme, in denen eine einzelne Sicherheitslücke nicht automatisch zur vollständigen Kompromittierung der Infrastruktur führt?

Ein kompromittierter PHP-Prozess darf nicht das gesamte System gefährden

Nehmen wir einen klassischen Linux-Webserver. Darauf laufen Apache oder Nginx, PHP-FPM, eine Datenbankanbindung und verschiedene Anwendungen. Wird eine kritische Schwachstelle in PHP ausgenutzt, kann ein Angreifer möglicherweise zunächst Code mit den Rechten des betroffenen PHP-Prozesses ausführen. Wie groß der Schaden anschließend wird, hängt wesentlich von der Architektur und den vergebenen Berechtigungen ab.

Kann der Prozess auf sensible Konfigurationsdateien zugreifen?
Sind Datenbankpasswörter im Dateisystem hinterlegt und lesbar?
Kann er beliebige Netzwerkverbindungen aufbauen?
Sind weitere Anwendungen über gemeinsam genutzte Verzeichnisse erreichbar?
Verfügt der Prozess über unnötige Systemrechte?

Oder ist die PHP-Laufzeitumgebung so weit eingeschränkt, dass der Angreifer trotz erfolgreicher Codeausführung nur einen begrenzten Handlungsspielraum erhält? Genau hier liegt für mich ein entscheidender Ansatz. Unter Linux stehen uns dafür seit vielen Jahren bewährte Mechanismen zur Verfügung.

Dazu gehören unter anderem:

systemd-Sandboxing zur Einschränkung von Diensten
AppArmor oder SELinux zur Durchsetzung zusätzlicher Zugriffsregeln
seccomp zur Begrenzung verfügbarer Systemaufrufe
getrennte Dienstkonten und restriktive Dateisystemberechtigungen
Netzwerksegmentierung und gezielte Zugriffskontrollen
isolierte Laufzeitumgebungen für unterschiedliche Anwendungen

Dabei geht es nicht darum, möglichst viele Sicherheitsmechanismen wahllos zu aktivieren. Entscheidend ist, dass eine kompromittierte Komponente möglichst wenig Zugriff auf andere Ressourcen erhält. Auch Container können dabei helfen. Sie sind allerdings nicht automatisch eine vollständige Sicherheitsgrenze. Entscheidend sind ihre Berechtigungen, Netzwerkanbindungen, eingebundenen Verzeichnisse und die Sicherheit des darunterliegenden Hosts. Diese Maßnahmen ersetzen keinen Patch. Aber sie können darüber entscheiden, ob aus einer Sicherheitslücke ein begrenzter Vorfall oder ein schwerwiegender Infrastrukturkompromiss wird.

Enterprise-Sicherheit muss einen erfolgreichen Angriff einkalkulieren

In professionellen IT-Umgebungen sollte Sicherheit niemals ausschließlich auf der Annahme beruhen, dass sämtliche Komponenten fehlerfrei funktionieren. Das war schon früher keine besonders tragfähige Strategie. Mit zunehmend leistungsfähigeren KI-Systemen wird diese Annahme noch problematischer.

Aus meiner Sicht müssen wir fünf Bereiche stärker miteinander verbinden.

1. Sicherheitsprüfung bereits während der Softwareentwicklung

KI-gestützte Codeanalyse kann helfen, Schwachstellen früher im Entwicklungsprozess zu erkennen. Sie sollte klassische Verfahren wie Code-Reviews, statische und dynamische Analysen, Fuzzing und automatisierte Tests ergänzen. Entscheidend ist die kontinuierliche Prüfung und nicht eine einmalige Sicherheitsbewertung vor der Veröffentlichung.

2. Kritische Open-Source-Infrastruktur nachhaltig finanzieren

PHP, OpenSSL und zahlreiche andere Open-Source-Komponenten bilden das Fundament großer Teile unserer digitalen Infrastruktur. Unzählige Unternehmen verdienen mit Produkten und Dienstleistungen Geld, die auf diesen Projekten aufbauen. Gleichzeitig hängt deren langfristige Wartung häufig von vergleichsweise kleinen Entwicklerteams und begrenzten Ressourcen ab. Hier brauchen wir nachhaltige Finanzierung, professionelle Sicherheitsprozesse und ausreichend Kapazitäten für Entwicklung und Wartung. Nicht erst dann, wenn die nächste kritische Sicherheitslücke bekannt wird.

3. Kompromittierte Komponenten konsequent isolieren

Ein Webserver benötigt nicht automatisch Zugriff auf sämtliche Datenbanken, Server und Dateisystembereiche. Anwendungen sollten nur diejenigen Berechtigungen erhalten, die sie für ihren Betrieb tatsächlich benötigen. Das klassische Least-Privilege-Prinzip ist keine neue Erfindung. Aber gerade jetzt wird es wichtiger denn je.

4. Sicherheitsupdates schneller und kontrollierter ausrollen

Wir benötigen weiterhin ein funktionierendes Patchmanagement. Automatisierte Tests, reproduzierbare Deployments, gestaffelte Rollouts und vorbereitete Rollback-Verfahren können helfen, die Zeit zwischen verfügbarer Korrektur und produktiver Installation zu verkürzen. Dabei darf Geschwindigkeit nicht zulasten der Betriebssicherheit gehen. Eine geschäftskritische Anwendung, die nach einem ungeprüften Update nicht mehr funktioniert, ist ebenfalls ein ernsthaftes Problem.

5. Resilienz als eigenständiges Sicherheitsziel verstehen

Wir müssen nicht nur verhindern, dass Angreifer in Systeme eindringen. Wir müssen ebenso sicherstellen, dass ein erfolgreicher Angriff möglichst wenig Schaden verursacht. Dazu gehören die Begrenzung von Zugriffsrechten, die Erkennung ungewöhnlicher Aktivitäten, belastbare Backups, Wiederherstellungsverfahren und die Fähigkeit, kompromittierte Komponenten schnell auszutauschen. Das ist keine Kapitulation vor Sicherheitslücken. Es ist eine realistische technische Strategie im Umgang mit komplexen Systemen.

Auch die Veröffentlichung von Sicherheitslücken wird schwieriger

Ein weiterer Aspekt des PHP2Shell-Vorfalls verdient besondere Aufmerksamkeit. Laut einem Bericht von Golem wurden korrigierte Container-Images vor dem ursprünglich vorgesehenen Veröffentlichungszeitpunkt bereitgestellt.

Das Problem dabei: Durch die Untersuchung solcher Images lassen sich unter Umständen Rückschlüsse auf die korrigierten Programmstellen und damit auf die zugrunde liegenden Schwachstellen ziehen. Das ist als Reverse Engineering von Patches seit Langem bekannt. KI kann diese Analyse jedoch erheblich beschleunigen. Damit entsteht ein Dilemma. Einerseits sollen Hersteller und Betreiber Sicherheitsupdates möglichst früh erhalten, damit sie ihre Systeme schützen können.

Andererseits können vorzeitig veröffentlichte Korrekturen Angreifern Informationen liefern, bevor die breite Masse der Betreiber überhaupt Zugriff auf die entsprechenden Updates hat. Der Prozess der koordinierten Offenlegung von Schwachstellen bleibt notwendig. Er muss aber möglicherweise an diese veränderten Geschwindigkeiten angepasst werden.

Vollständig beseitigen lässt sich dieses Spannungsfeld vermutlich nicht.

Wir brauchen keine Illusion fehlerfreier Software

Seit mehr als drei Jahrzehnten beschäftigen wir uns in der IT mit Firewalls, Zugangskontrollen, Sicherheitsupdates, Systemhärtung und der Trennung von Diensten. Viele dieser Grundprinzipien sind heute noch genauso richtig wie vor zwanzig oder dreißig Jahren. Was sich verändert, ist die Geschwindigkeit, mit der Schwachstellen entdeckt, analysiert und möglicherweise ausgenutzt werden können.

KI wird diesen Prozess weiter beschleunigen. Wir werden aber nicht plötzlich fehlerfreie Betriebssysteme, Datenbanken oder Webanwendungen entwickeln. Deshalb sollten wir auch nicht darauf warten.

Die entscheidende Aufgabe besteht darin, IT-Infrastrukturen so zu gestalten, dass Fehler einkalkuliert sind und ein erfolgreicher Angriff nicht zwangsläufig das gesamte System gefährdet.

Eine Sicherheitslücke in PHP darf nicht automatisch zum vollständigen Zugriff auf einen Linux-Server führen. Ein kompromittierter Webserver darf nicht ohne Weiteres die gesamte interne Infrastruktur erreichen. Und der Ausfall einer einzelnen Komponente darf nicht unmittelbar zum Stillstand eines gesamten Unternehmens führen.

Genau darin sehe ich den notwendigen Perspektivwechsel. Weg von der Vorstellung, Sicherheit ausschließlich durch das Verhindern einzelner Schwachstellen erreichen zu können. Hin zu einer Architektur, die auch dann kontrollierbar bleibt, wenn eine ihrer Komponenten versagt.

Denn eines dürfte sicher sein:

Die nächste kritische Sicherheitslücke wird kommen. Entscheidend ist, wie viel Schaden sie dann noch anrichten kann.