Ich rechne damit, dass wir als Administratoren häufiger mit gefährlichen Exploits umgehen müssen, also mit Angriffscode, der Sicherheitslücken ausnutzt. PHP2Shell, die beiden kürzlich geschlossenen Sicherheitslücken in der serverseitigen Skriptsprache PHP, ist für mich ein Anlass, diese Erwartung ernst zu nehmen. PHP führt den Code vieler Websites aus; die Lücken CVE-2026-109618 und CVE-2026-109619 können unter passenden Bedingungen fremden Code ohne vorherige Anmeldung auf dem Server ermöglichen. Die Updates erschienen am 21. Oktober. Die Frage, die mich darüber hinaus beschäftigt: Was passiert mit unserem Betrieb, wenn KI die Suche nach solchen Fehlern und ihre Ausnutzung immer günstiger macht?[a]
Ich arbeite seit vielen Jahren als Sysadmin und Entwickler. Dass Software Sicherheitslücken hat, überrascht mich nicht. Mein Eindruck ist aber, dass sich gerade verändert, wie viel Arbeit nötig ist, um aus einem schwer verständlichen Fehler einen brauchbaren Angriff zu machen. In unserem Unternehmen wollen wir Sicherheitspraktiken deshalb stärker gewichten. Wir erwarten mehr gefährliche Exploits und wollen unsere Abläufe darauf vorbereiten.
Die Zahl der Meldungen steigt. Was sagt sie aus?
Eine CVE, kurz für Common Vulnerabilities and Exposures, gibt einer öffentlich erfassten Schwachstelle eine gemeinsame Kennung. Der Sicherheitsforscher Jerry Gamblin zählt für Januar bis Juni 2024 insgesamt 20.374 veröffentlichte CVE-Datensätze, für denselben Zeitraum 2025 bereits 23.656 und für 2026 dann 35.364. Das sind 49,5 Prozent mehr als im Vorjahreszeitraum. Seine Auswertung schließt zurückgewiesene Einträge aus. Das Veröffentlichungsdatum sagt dabei nicht, wann der Fehler entstand oder erstmals entdeckt wurde.[c]
Jeweils 1. Januar bis 30. Juni; veröffentlichte CVE-Datensätze ohne zurückgewiesene Einträge. Historischer Auswertungsstand vom 1. Juli 2026. Keine Jahresprognose und keine Zählung von Angriffen.
Quelle: Jerry Gamblin, Auswertung vom 1. Juli 2026. Veröffentlichte CVE-Datensätze jeweils von Januar bis Juni, ohne zurückgewiesene Einträge.[c]
Auch schwere Lücken sind darunter: Für das erste Halbjahr 2026 nennt die Auswertung 13.821 Einträge mit dem Schweregrad „hoch“ und 3.554 mit „kritisch“. Der zugrunde liegende Score des Common Vulnerability Scoring System (CVSS) beschreibt technische Schwere unter bestimmten Bedingungen. Er sagt nicht, ob die Lücke auf meinem Server erreichbar ist oder bereits ausgenutzt wird.[c]
FIRST, der internationale Zusammenschluss von Sicherheitsteams, nennt in seiner Juni-Auswertung neben KI-gestützter Forschung auch mehr Meldungen und die Erfassung bislang nicht zugeordneter Altbestände. Bei einer Eingrenzung auf bekannte Ausnutzung beziehungsweise höhere vorhergesagte Ausnutzungswahrscheinlichkeit sah FIRST damals keinen entsprechend starken Anstieg.[k]
Meine Sorge hängt deshalb nicht an einer steilen Kurve allein. Entscheidend sind Fälle, in denen Forschende mit KI-Unterstützung tatsächliche, relevante Fehler nachweisen und daraus funktionierende Angriffe entwickeln.
Die Beispiele reichen längst über PHP hinaus
Bei Firefox ist die Verbindung besonders gut dokumentiert. Anthropic berichtete im März, mit Claude Opus 4.6 binnen zwei Wochen 22 Schwachstellen gefunden zu haben, von denen Mozilla 14 als hoch einstufte. In Mozillas Sicherheitsmeldung zu Firefox 148 stehen konkrete Kennungen: etwa CVE-2026-2763, ein Zugriff auf bereits freigegebenen Speicher in der JavaScript-Engine, und CVE-2026-2771, undefiniertes Verhalten in einer zentralen Browserkomponente. Mozilla nennt die Forschenden ausdrücklich mit dem Zusatz, dass sie Claude eingesetzt haben.[f][d]
Im April meldete Mozilla weitere 271 mit einer frühen Version von Claude Mythos Preview identifizierte und in Firefox 150 behobene Schwachstellen. Sie zeigt, wie viel bislang unentdeckte Arbeit selbst in einem intensiv geprüften Projekt sichtbar werden kann.[e]
Für Serverbetreiber ist Copy Fail, CVE-2026-31431, ein weiteres Beispiel. Laut dem Entdeckerteam Theori brachte dessen KI-Werkzeug Xint Code den Fehler bei einer etwa einstündigen Untersuchung des Linux-Kryptografiecodes ans Licht. Microsoft beschreibt die Lücke als lokale Rechteausweitung: Wer bereits Code mit geringen Rechten auf einem betroffenen System ausführen kann, kann unter den erforderlichen Bedingungen Root-Rechte erlangen. Der Score liegt bei 7,8, also „hoch“.[g][h]
Gerade dieser Unterschied zählt im Alltag: Copy Fail öffnet für sich genommen keinen Server aus dem Internet. Eine solche Lücke kann aber einen bereits vorhandenen, begrenzten Zugang erheblich gefährlicher machen. Wer Build-Runner oder andere Systeme mit fremdem Code betreibt, muss deshalb auch die Grenzen zwischen Anwendung, Container und Host betrachten.[h]
Was LLMs den Menschen tatsächlich abnehmen
Große Sprachmodelle, häufig LLMs genannt, helfen inzwischen bei mehreren aufeinanderfolgenden Arbeitsschritten. Sie können Code untersuchen, Vermutungen über Fehler formulieren und Testprogramme entwerfen. Verbunden mit Werkzeugen können sie Fehlversuche auswerten und ihre Ansätze ändern. Das Sicherheitswissen des Menschen fließt weiterhin in die Auswahl des Ziels, die Testumgebung und die Bewertung des Ergebnisses ein.[f]
KI unterstützt mehrere Schritte der Sicherheitsforschung. Reproduzierbare Tests verbinden die Arbeit von Forschenden und Modellen. Eigene Infografik: Ex Silico.[b][f]
Bei PHP2Shell beschreibt Wiz genau diesen praktischen Nutzen: Das Team habe mithilfe von KI funktionierende Exploits innerhalb von Stunden für unterschiedliche Anwendungen entwickelt und angepasst. Besonders aufwendig seien zuvor die Unterschiede in Speicherbelegung, PHP-Version und Konfiguration gewesen.[b]
Ein weiterer Versuch macht die mögliche Größenordnung greifbar. Anthropic beschrieb im September, wie ein Forscher GLM-5.3-Flash öffentliche Informationen zur Chrome-Lücke CVE-2026-11645 und zu einer weiteren bekannten Lücke gab. Das Modell verband beide in einem Labortest zu einer funktionierenden Exploit-Kette für ein ARM64-Ziel. Genannt werden 20 Minuten menschliche Aufmerksamkeit, acht Stunden Modellarbeit und rechnerisch 20,40 Dollar API-Kosten.[i]
Die Entwicklung lässt sich allerdings nicht nur mit Anbieterberichten begründen. Das US-Institut CAISI bewertete GLM-5.3 im September ebenfalls als besonders leistungsfähiges Modell mit öffentlich verfügbaren Gewichten für Sicherheitsaufgaben. Im zusammengefassten Maß seiner Tests lag es rund vier Monate hinter der US-Spitze. Sie stützen aber die Einschätzung, dass solche Fähigkeiten breiter verfügbar werden.[j]
Schneller finden heißt noch lange nicht schneller absichern
Die Aussicht hat eine gute Seite: Auch Verteidiger können alte Fehler systematischer suchen und beseitigen. Mozilla zieht aus seinen Ergebnissen ausdrücklich eine optimistische Schlussfolgerung. Wenn die Suche billiger wird, können Entwickler mehr prüfen, bevor ein Angreifer die Lücke findet. Diesen Vorteil sollten wir nutzen.[e]
Die Arbeit danach verschwindet jedoch nicht. Die PHP Foundation berichtet von 15 veröffentlichten CVEs seit dem 1. Juli und mehr als 100 geprüften Meldungen, die sich als ungültig, doppelt oder nicht reproduzierbar erwiesen. Erste Anzeichen eines der PHP2Shell-Probleme waren schon 2024 bekannt. Der Weg zum Fix stockte unter anderem an schwierigen technischen Abwägungen, Entscheidungen und fehlenden Ressourcen. Ein Modell, das mehr findet, schafft nicht automatisch mehr erfahrene Maintainer.[a]
Auch die Infrastruktur zur Bewertung kommt unter Druck. NIST erklärte im April, 2025 fast 42.000 CVEs um zusätzliche Informationen angereichert zu haben und trotzdem nicht mit dem Aufkommen Schritt zu halten. Die Behörde priorisiert diese Arbeit seither nach festgelegten Kriterien. Für mich ist das ein konkretes Zeichen dafür, dass wir neben besseren Suchwerkzeugen auch mehr Kapazität für die Verarbeitung der Ergebnisse brauchen.[l]
Ein Internet, in dem sich mehr Angriffe lohnen
Wenn Modelle weiter besser und ihre Nutzung günstiger werden, erwarte ich zunächst eine breitere wirtschaftliche Angriffsfläche. Ein Ziel, das bisher zu wenig Ertrag für mehrere Tage Spezialistenarbeit versprach, könnte attraktiv werden, wenn ein Mensch mehrere Versuche parallel betreut und das Modell den Großteil der Anpassung übernimmt. Dafür muss keine KI jeden Server selbstständig knacken. Es genügt, dass Menschen mit denselben Ressourcen mehr aussichtsreiche Versuche durchführen können.
Ein zweiter möglicher Effekt betrifft die Zeit nach einem Update. Ein veröffentlichter Fix verrät etwas über den Fehler. Wenn sich daraus schneller ein funktionierender Angriff entwickeln lässt, wächst der Druck auf Betreiber, die noch aktualisieren müssen. Wie stark dieses Zeitfenster schrumpft, wird von der Lücke, dem Ziel und den verfügbaren Schutzmaßnahmen abhängen.
Ich halte es deshalb für plausibel, dass öffentliche Dienste stärker abgeschirmt werden und kleinere Betreiber häufiger auf zentral verwaltete Plattformen ausweichen. Dort lassen sich Updates und Schutzmaßnahmen für viele Kunden bündeln. Das könnte aber auch die Abhängigkeit von wenigen Anbietern vergrößern und eigenständigen Betrieb teurer machen. Ein offenes Internet, in dem kleine Teams selbst Dienste anbieten können, braucht deshalb bezahlbare Sicherheitswerkzeuge und ausreichend finanzierte Basiskomponenten.
Wenn Verteidiger ihre Systeme schneller verstehen, Fehler früher schließen und die Folgen eines Einbruchs begrenzen, kann dieselbe Technik das Netz robuster machen. Meine Erwartung ist trotzdem, dass der Übergang für viele Betriebsteams anstrengender wird: Alte Fehler werden sichtbar, während neue Software und neue Abhängigkeiten hinzukommen.
Was ich daraus für unseren Beruf ableite
Vier Prioritäten für den IT-Betrieb: Überblick, schnelle Updates, begrenzte Zugriffe und getestete Wiederherstellung. Eigene Infografik zur Einordnung: Ex Silico.
Mehr Sicherheitsfokus muss sich für mich an konkreten Fähigkeiten messen lassen. Ich würde zuerst wissen wollen, welche Dienste wir öffentlich anbieten, welche Komponenten darin laufen und wer ein dringendes Update verantwortet. Ein Inventar muss auch Nebenanwendungen, Container-Images und selten angefasste Systeme erfassen. Sonst beginnt die Reaktion auf die nächste Meldung wieder mit der Suche nach den eigenen Installationen.
Danach würde ich den Weg vom Advisory zum laufenden Fix üben: Betroffenheit prüfen, Update testen, kontrolliert ausrollen und anschließend feststellen, ob tatsächlich die korrigierte Version läuft. Dazu gehören ein Rückweg bei Problemen und klare Entscheidungsbefugnisse für dringende Fälle. Reaktionszeit lässt sich vorbereiten; sie sollte nicht jedes Mal von spontaner Mehrarbeit abhängen.
Bei der Reihenfolge helfen bekannte Ausnutzung, Erreichbarkeit und mögliche Folgen mehr als die reine Länge einer CVE-Liste. Der KEV-Katalog der US-Behörde CISA sammelt nachweislich ausgenutzte Schwachstellen; FIRSTs EPSS schätzt die Wahrscheinlichkeit beobachteter Ausnutzung. Beide sind Hilfen zur Priorisierung. Ein fehlender Eintrag ersetzt keine Prüfung der eigenen Situation.[k]
Ebenso wichtig finde ich begrenzte Berechtigungen, getrennte Systeme für unterschiedlich vertrauenswürdige Aufgaben, geschützte Zugangsdaten und getestete Wiederherstellung. Auch ein gut organisierter Betrieb wird nicht jede Lücke rechtzeitig schließen. Dann entscheidet die Architektur mit darüber, wie weit ein Angreifer kommt und wie aufwendig die Rückkehr zum normalen Betrieb wird.
KI würde ich dabei selbst einsetzen: zum Eingrenzen von Änderungen, für zusätzliche Prüfungen und für reproduzierbare Tests in kontrollierten Umgebungen. Die Ergebnisse müssen überprüfbar bleiben. Was ich für unser Unternehmen aus der aktuellen Entwicklung mitnehme, ist eine klare Priorität: Wir wollen mehr Zeit in Sicherheitspraktiken investieren, bevor der nächste Exploit uns diese Zeit ungeplant abverlangt.
Warum werden mehr CVEs veröffentlicht?
Wie weit kommen Modelle bei der Exploit-Entwicklung?
Titelbild: Server der Wikimedia Foundation, fotografiert am 21. Juli 2015. Archivfoto zur Illustration des Infrastruktur-Betriebs. Foto: Victor Grigas/Wikimedia Foundation (öffnet in neuem Tab), CC BY-SA 3.0 (öffnet in neuem Tab). Unverändertes Original; für die Darstellung skaliert.
