Verteidiger und Risiko zugleich: Die zwei Gesichter der KI

Anthropics Claude findet Schwachstellen in Open-Source-Software – und schafft gleichzeitig selbst neue Risiken.

Open‑Source‑Software bildet das Fundament moderner Unternehmensanwendungen. Doch je tiefer Bibliotheken und Frameworks in Applikations‑Stacks eingebettet sind, desto größer ist das systemische Risiko: Ein einzelner, lange unentdeckter Fehler kann sich kaskadenartig durch ganze Lieferketten ausbreiten. Mit dem Einsatz leistungsfähiger KI‑Modelle verschärft sich diese Dynamik – sowohl auf der Verteidiger‑ als auch auf der Angreiferseite.

500 auf einen Streich: KI als Vulnerability‑Scout

Anfang Februar sorgte Anthropic für Aufsehen: Das neue Modell Claude Opus 4.6 identifizierte nach Angaben des Herstellers mehr als 500 zuvor unbekannte, hochkritische Schwachstellen in weit verbreiteten Open‑Source‑Bibliotheken wie Ghostscript, OpenSC und CGIF. Diese Komponenten sind tief in Unternehmens‑IT, Entwickler‑Tools und Betriebssysteme integriert – entsprechend groß ist der potenzielle Impact.

Bemerkenswert ist weniger die schiere Zahl der Funde als die Methode. Claude Opus 4.6 analysierte nicht nur Quellcode, sondern auch Commit‑Historien, identifizierte wiederkehrende Fehlermuster und deckte Logik‑ und Speicherfehler auf, die selbst bei hoher Testabdeckung unentdeckt geblieben waren. Anthropic betont, dass alle Funde durch das interne Frontier Red Team validiert wurden, um Fehlalarme auszuschließen.

Für Unternehmen bedeutet das zweierlei: Erstens können KI‑gestützte Analysen helfen, jahrzehntealte Schwachstellen schneller zu finden und zu schließen. Zweitens sinkt die Eintrittsschwelle für Angreifer, die ähnliche Modelle nutzen, um gezielt nach ausnutzbaren Fehlern in der Lieferkette zu suchen.

Wenn die KI selbst zur Schwachstelle wird

Fast zeitgleich geriet Anthropic jedoch selbst in die Kritik. Sicherheitsforscher von LayerX entdeckten eine Zero‑Click‑Schwachstelle in Claude‑Desktop‑Erweiterungen, die potenziell mehr als 10.000 Nutzer betrifft. Ein einzelner manipulierter Google‑Kalendereintrag genügt, um beim späteren Zugriff durch Claude lokale Code‑Ausführung mit Systemrechten auszulösen – ganz ohne Nutzerinteraktion.

Ursache ist kein klassischer Buffer Overflow, sondern ein Bruch von Vertrauensgrenzen: Daten aus einem als risikoarm betrachteten Kontext (Kalender) werden von einem autonomen Agenten mit hochprivilegierten lokalen Ausführungsrechten verknüpft.

„Exploits wie dieser zeigen das klassische Dilemma der KI: Um die Produktivitätsvorteile der KI zu nutzen, muss man diesen Tools umfassenden Zugriff auf sensible Daten gewähren“, erklärte Roy Paz, Principal AI Researcher bei LayerX Security, in einer E-Mail an eSecurityPlanet. „Wenn jedoch Daten kompromittiert werden, sehen sich die KI- und Modellanbieter nicht für die Sicherheit der Nutzer ihrer Produkte verantwortlich. Dies unterstreicht die Notwendigkeit eines KI-Modells der geteilten Verantwortung, bei dem klar ist, wer für die verschiedenen Sicherheitsebenen von KI-Tools verantwortlich ist.“

Da Desktop‑Erweiterungen außerhalb klassischer Sandbox‑Mechanismen laufen, können sie Dateien lesen, Befehle ausführen und Zugangsdaten abgreifen.

Ein Konstruktionsfehler, der die Angriffsfläche unbemerkt vergrößert

Zwar bestreitet Anthropic die Behauptung, dass Erweiterungen ohne Sandboxing ausgeführt werden, ganz so einfach ist es aber nicht, wie Roy Paz, leitender Sicherheitsforscher bei LayerX, gegenüber The Register erklärte:

„Es ist vom Design her nicht möglich, etwas in einer Sandbox zu isolieren, wenn davon ausgegangen wird, dass es vollen Systemzugriff hat. Man kann es vielleicht in einen Container packen, aber das ist nicht dasselbe. Im Vergleich zu Windows Sandbox, Sandboxie oder VMware bleibt der Container von Claude DXT deutlich hinter den Erwartungen an eine Sandbox zurück. Aus Sicht eines Angreifers ist das so, als würde man den Türcode auf 1234 setzen und die Tür dann unverschlossen lassen, weil das Schließen des Türcodes die Zusteller daran hindern würde, das Gebäude zu betreten und zu verlassen.“

Anthropic entschied sich nach dem Bekanntwerden gegen eine kurzfristige Behebung und wies darauf hin, dass es sich um ein Architektur‑ und Einsatzthema handele.

Für CISOs ist das ein Warnsignal. Die Annahme, eine Sandbox sei per Definition sicher, greift zu kurz.

Isolierung ist kein Ersatz für Vertrauensmodelle

Dass Isolierung allein kein Sicherheitsversprechen ist, zeigt ein aktueller Vorfall bei Fortinet. Der Hersteller hat im Februar eine kritische Schwachstelle in FortiSandbox offengelegt, einer Plattform, die eigentlich dazu dient, Schadcode sicher zu analysieren. Die Lücke ermöglicht es Angreifern, ohne Authentifizierung Systembefehle auszuführen.

Der Fall ist vor allem sicherheitspolitisch brisant: Eine Lösung zur Abschottung von Malware kann selbst zum Pivot‑Point für Schadsoftware werden. Konkret handelt es sich um eine reflektierte Cross‑Site‑Scripting‑Schwachstelle (XSS) in der Web‑Oberfläche von FortiSandbox (CVE‑2025‑52436). Über manipulierte Anfragen kann Schadcode in die GUI eingeschleust werden. Wird die kompromittierte Seite später von einem Administrator aufgerufen, wird das Skript im Kontext der Anwendung ausgeführt – mit der Folge, dass sich der Angriff von Client‑seitigem Skriptcode zu vollständiger Remote‑Command‑Execution (RCE) eskalieren lässt.

Fast schon sarkastisch mutet Fortinets Antwort an, dass “Produkte, bei denen SSL-VPN nie aktiviert war, von diesem Problem nicht betroffen“ sind.

Strukturell ähnelt das Risiko dem Zero‑Click‑Exploit in Claude Desktop: In beiden Fällen führen fehlende oder falsch modellierte Vertrauensgrenzen dazu, dass eigentlich niedrig bewertete Eingaben (Web‑Parameter, Kalenderdaten) in hochprivilegierte Aktionen münden.

Damit fügt sich der FortiSandbox‑Vorfall in ein größeres Muster ein. Sandboxen – ob für Malware‑Analyse, Container‑Workloads oder KI‑Agenten – schützen in erster Linie Codeausführung, nicht automatisch Steuer‑ und Verwaltungsebenen. Web‑GUIs, APIs und Orchestrierungslogik bleiben klassische Angriffsflächen. Autonome KI‑Agenten erweitern die Angriffsfläche, ohne dass dies in traditionellen Threat‑Modellen hinreichend abgebildet wird.

Lieferkette unter Dauerstress

Beide Ereignisse verdeutlichen ein zentrales Problem moderner IT‑Sicherheit: Transparenz und Kontrolle über Abhängigkeiten fehlen. Open‑Source‑Bibliotheken, KI‑Modelle, Plug‑ins und Agenten bilden eine hochdynamische Lieferkette. Wird eine Schwachstelle erst spät entdeckt, kann sie sich unbemerkt in Dutzenden Produkten fortpflanzen.

Regulatorisch wächst der Druck. Vorgaben wie NIS2 oder die zunehmende Bedeutung von Software Bills of Materials (SBOMs) zielen genau auf diese Intransparenz ab. Auch internationale Sicherheitsbehörden fordern SBOMs als Grundlage für ein wirksames Risikomanagement in der Software‑Lieferkette.

Handlungsempfehlungen für CISOs

• SBOMs konsequent etablieren und nutzen: SBOMs dürfen kein reines Compliance‑Artefakt sein. Sie sollten automatisiert gepflegt und mit Schwachstellen‑ und Exploit‑Daten korreliert werden, um reale Risiken zu priorisieren statt bloß CVE‑Listen abzuarbeiten.
• Ausnutzbarkeit vor Kritikalität priorisieren: Nicht jede „kritische“ Schwachstelle ist praktisch relevant. KI‑gestützte Analysen können helfen, jene Fehler zu identifizieren, die unter realen Bedingungen tatsächlich ausnutzbar sind – ein entscheidender Faktor angesichts begrenzter Ressourcen.
• Autonome Agenten strikt isolieren: KI‑Agenten und Desktop‑Erweiterungen sollten in Sandboxen, VMs oder dedizierten Arbeitsumgebungen betrieben werden. Direkte Verbindungen zwischen externen Datenquellen und lokalen Ausführungsrechten sind zu vermeiden.
• Vertrauensgrenzen explizit modellieren: IT-Verantwortliche sollten Agenten‑Workflows wie klassische Privilege‑Escalation‑Pfade betrachten. Daten aus E‑Mail, Kalendern oder Chats müssen als untrusted Input gelten – auch wenn sie aus scheinbar legitimen Quellen stammen.
• Laufzeitüberwachung statt nur Prävention: Angriffe auf die Lieferkette zeigen sich oft erst im Betrieb. Verhaltensanalysen und Runtime‑Monitoring können Hinweise auf kompromittierte Bibliotheken oder manipulierte Agenten liefern, bevor größerer Schaden entsteht.
• Gemeinsames Verantwortungsmodell einfordern: Hersteller verweisen zunehmend auf den Anwender. Unternehmen sollten deshalb vertraglich und organisatorisch klären, welche Sicherheitsgarantien sie von KI‑ und Software‑Anbietern erwarten – und wo eigene Kontrollen zwingend nötig sind.

Fazit

KI beschleunigt die Entdeckung von Schwachstellen – und damit auch das Wettrennen zwischen Angreifern und Verteidigern. Gleichzeitig zeigen Vorfälle wie bei Claude Desktop, dass autonome Agenten ohne klare Sicherheitsgrenzen neue, schwer kalkulierbare Risiken schaffen. Angriffsflächen verschieben sich, schaffen neue Abhängigkeiten und erfordern explizite Governance. Wer KI produktiv einsetzen will, muss sie genauso streng kontrollieren wie jede andere kritische Infrastruktur.

Für CISOs bedeutet das, Schutzmechanismen nicht isoliert zu betrachten, sondern sie als Teil einer durchgängigen Vertrauenskette zu modellieren. Lieferkettensicherheit, Agenten‑Governance und Laufzeitkontrollen müssen als Einheit gedacht werden.