Ausnutzung von Schwachstellen
Pwn2Own Berlin: GenAI Jäger und auch Gejagter
Der diesjährige Pwn2Own-Wettbewerb in Berlin hat die Anfälligkeit des KI-Stack vorgeführt. Die Kluft zwischen den Versprechen dieser Tools und der tatsächlichen Leistung verdeutlicht die fragilen Sicherheitsgrundlagen, auf denen sie beruhen.
Save to Folio
Wichtige Erkenntnisse
- KI ist nun sowohl Jäger als auch Gejagter. Beim Pwn2Own Berlin 2026 nutzten die Teilnehmer LLMs und agentische Programmierwerkzeuge, um Schwachstellen zu finden, gleichzeitig standen KI-Tools wie Claude Code, Codex und Cursor auch auf der Liste der Ziele.
- Die ausnutzbaren Schwachstellen in Claude Code, OpenAI Codex und Cursor ließen sich alle auf dieselben Ursachen zurückführen: überdimensionierte Entwicklertools und ein fehlgeleitetes Vertrauen zwischen Agenten und Nutzern.
- Jedes Team setzte LLMs in einem Teil seines Workflows ein, doch alle berichteten von hohen Falsch-Positiv-Raten in der Erkundungsphase, was mit den Ergebnissen traditioneller Sicherheitsforschung übereinstimmt. Entscheidend ist der Geschwindigkeitsvorteil, nicht die Genauigkeit.
- Tools wie Ollama und ChromaDB sind im Internet sehr exponiert, und erfolgreiche Angriffe auf diese oder auf das Nvidia Container Toolkit könnten Zugriff auf den zugrunde liegenden Host gewähren – nicht nur auf das Modell.
- Vibe-Coding und Risiken in der Lieferkette lassen im nächsten Jahr einen noch intensiveren und chaotischeren Wettbewerb erwarten. Ähnlicher Code, der sich über unabhängige Projekte hinweg verbreitet, missbrauchsanfällige Entwicklertools und anhaltende Angriffe auf die Lieferkette bedeuten, dass die Angriffsfläche nur noch zunehmen wird, während sich die Softwareentwicklung und die Entdeckung von Fehlern gleichzeitig beschleunigen.
Der Pwn2Own Berlin fand bereits zum zweiten Mal in Folge vom 14. bis 16. Mai auf der OffensiveCon statt und wird von TrendAI™ ZDI, dem weltweit größten herstellerunabhängigen Bug-Bounty-Programm, organisiert. Eingeladen sind IT-Forscher, die im Wettbewerb Schwachstellen in weit verbreiteter Software und Hardware aufdecken sollen. Der Wettbewerb zweifellos in der Ära der generativen KI (GenAI) angekommen. Als Vertreter des Forward-Looking Threat Research (FTR)-Teams von TrendAI™ hatte ich das Privileg, gemeinsam mit den Analysten der TrendAI™ Zero Day Initiative™ (ZDI) am Offenlegungsprozess für einige der KI-Ziele mitzuwirken. Selbstverständlich kann ich die Details der tatsächlichen Fehler erst nach Ablauf der Offenlegungsfrist erörtern, doch lassen sich bereits einige allgemeine Beobachtungen teilen.
Der letztjährige Wettbewerb brachte die ersten Ergebnisse in der neuen KI-spezifischen Kategorie hervor, darunter CVE-2025-49844 (ZDI-25-933), eine kritische Use-after-free-Sicherheitslücke in Redis, sowie CVE-2025-23266 (ZDI-25-626), eine Schwachstelle zur Rechteausweitung im Nvidia Container Toolkit.
Für den diesjährigen Wettbewerb gab es in allen Kategorien eine Rekordzahl an Einsendungen, sodass wir bei der Aufnahme der Teilnehmer sehr wählerisch sein mussten. Am Ende der Veranstaltung gab es zudem mehr Absagen als erwartet. Das ist bedauerlich, aber wir wollen nicht darüber spekulieren, woran das lag. Letztendlich erhielten alle Teilnehmer zusammen jedoch knapp 1,3 Millionen US-Dollar an Preisgeldern -- immer noch eine beachtliche Summe.
Die höchsten Prämien waren für besonders schwerwiegende Schwachstellen in Betriebssystemen, Hypervisoren und Browsern vorgesehen. Doch angesichts der steigenden Bedeutung von KI wurden auch einige dieser Ziele mit nicht unerheblichen Prämien ausgezeichnet. Die lukrativsten Kategorien waren die Nvidia- und die Inferenz-Ziele.
Ziele in den KI-Kategorien
Insgesamt gab es 13 mögliche Ziele in allen KI-Kategorien. Bei „KI-Datenbanken“ (die in der Regel Vektorspeicher bedeuten) wurden von den Teilnehmern nur Chroma und die Oracle Autonomous AI Database ins Visier genommen. In der Kategorie „Codierungsagenten“ versuchten sich die Teilnehmer an allen Zielen: Anthropic Claude Code, Cursor und OpenAI Codex. Bei „lokaler Inferenz“ wurden nur LiteLLM, LM Studio und Ollama in die Hacking-Versuche eingezogen. Megatron Bridge und das Container Toolkit waren die einzigen, die in der Kategorie „Nvidia“ angegriffen wurden. Insgesamt belief sich Zahl der tatsächlich von den Forschern angegriffenen Ziele auf zehn.
Geht es um KI-Systeme, denken wir meist an Inferenz: eine Vorhersage aus einem Input zu erhalten. Klassischerweise fallen einem da Systeme wie Ollama, LM Studio oder das Nvidia Container Toolkit ein, die ein Modell hosten und Zugriff darauf gewähren können. Oder vielleicht eine Abstraktions- und Proxy-Schicht wie LiteLLM.
Mit Ollama können Nutzer viele Modelle selbst hosten, sofern der Host über ausreichend GPU-Leistung und Arbeitsspeicher verfügt. Auf diese Weise lassen sich beispielsweise große Sprachmodelle (LLMs) wie Googles Gemma 4 oder OpenAIs GPT-OSS sowie Embeddings von Nomic lokal ausführen. Zudem ist Ollama sehr häufig im Internet exponiert und damit ein attraktives Ziel für Angreifer.
Als Ziel in einem Wettbewerb wie Pwn2Own ist Ollama, das sehr häufig aktualisiert wird, nicht gerade ideal. Ein Teilnehmer arbeitet etwa wochenlang an einem Exploit, nur um dann festzustellen, dass dieser auf der neuesten Version nicht funktioniert. Dem Team „Out Of Bounds“ gelang es jedoch, zwei Fehler zu finden, von denen einer bereits bekannt, aber noch nicht behoben worden war. Viele der im Internet exponierten Ollama-Instanzen könnten bereits manipuliert oder für Inferenzzwecke genutzt werden, doch dieser Bug hätte auch den Zugriff auf den zugrunde liegenden Host ermöglicht.
Das Container Toolkit von Nvidia ist ein ganz anderes Biest. Es handelt sich um eine Reihe von Bibliotheken, die es Docker-, Kubernetes- oder ähnlichen Containern ermöglichen, auf die GPUs von Nvidia zuzugreifen. Somit kann der Nutzer hochleistungsfähige Aufgaben ausführen, insbesondere aber LLM-Inferenzen innerhalb einer Containerumgebung. Potenziell könnte ein erfolgreicher Angriff Zugriff auf den Container selbst oder, schlimmer noch, auf das Host-System gewähren. Es gab drei Versuche, von denen zwei erfolgreich waren, von Chompie (Valentina Palmiotti von IBM X-Force) und PWN2DACA. In der Praxis müsste der Angreifer bereits über einen gewissen Zugriff auf die Containerumgebung verfügen, um einen solchen Angriff auszuführen, aber eine Verkettung von Exploits ist in der Praxis keine Seltenheit.
LM Studio ähnelt Ollama insofern, als es KI-Modelle und Embeddings hostet, verfügt jedoch über eine intuitivere Benutzeroberfläche und bietet weitere KI-bezogene Funktionen, etwa „Retrieval-Augmented Generation“ – eine beliebte Methode, um relevanten Kontext in eine Benutzeranfrage einzubinden und so Halluzinationen zu reduzieren. Im Gegensatz zu Ollama ist die Anwendung jedoch meist lokal ausgerichtet und hat kaum Kontakt zum Internet. Die Electron-basierte GUI-Anwendung bringt viele der Probleme von Electron mit sich. Daher ist es nicht überraschend, dass OtterSec und Starlabs eine Vielzahl von Fehlern fanden, Qrious Secure hingegen zogen ihren Beitrag zurück.
Auch Agentic Coding-Systeme wurden als Angriffsziele einbezogen. OpenAI Codex ist bereits seit langem als Plugin für verschiedene Code-Editoren verfügbar, lange bevor ChatGPT in den Fokus der Öffentlichkeit rückte. Das System wird nach wie vor als Plugin genutzt, ist mittlerweile aber auch als eigenständige und cloudbasierte Anwendung verfügbar. Fünf Teams versuchten sich an Codex, und obwohl sich viele von ihnen gefundenen Fehler ähnelten und das Grundkonzept bereits bekannt war, galten sie größtenteils als einzigartige Fehler. Es gab einen fehlgeschlagenen Versuch und eine Kollision.
Der Claude-Code von Anthropic ist zwar ein relativ neuer Akteur in diesem Bereich, erfreut sich jedoch großer Beliebtheit. Er war ein sehr begehrtes Ziel, auf das sich vier Teams konzentrierten. Die gefundenen Fehler ähnelten sich, und in zwei Fällen wurden sie als Überschneidungen mit zuvor im Wettbewerb entdeckten Fehlern eingestuft. Manchmal entscheidet eben der Zufall bei der Zuteilung.
Für Cursor gab es nur zwei Versuche von Viettel und STARLabs, die zu vollständigen Erfolgen führten.
Bei allen drei KI-Programmierwerkzeugen scheinen die Probleme auf ähnliche Ursachen zurückzuführen zu sein: die zugrunde liegenden Frameworks, die die Agenten verwenden. Einige dieser gängigen Entwicklertools haben viele Funktionen hinzubekommen, die nun im Zeitalter der generativen KI zu Nachteilen werden. Hinzu kommt ein gewisses falsch verstandenes Vertrauen, wenn die Agenten den Nutzer auffordern, Risiken einzugehen, die der Nutzer möglicherweise nicht richtig einschätzen kann.
Für sich genommen sind LLMs zwar nützlich, neigen jedoch zu Halluzinationen. Um dieses Problem zu lösen, ergänzen viele GenAI-gesteuerten Anwendungen die Eingabeaufforderung mit Informationen aus vertrauenswürdigen Datenquellen, wofür häufig Vektorspeicher genutzt werden. „Retrieval-Augmented Generation“ (RAG) ist das Stichwort. Auf diese Weise lassen sich ähnliche Texte abrufen, indem anhand ihrer Vektoreinbettungen diejenigen gefunden werden, die den für die Anfrage interessanten Texten am nächsten kommen.
ChromaDB ist eine auf Vektorsuche ausgerichtete Open-Source-Datenbank, die speziell für KI-Anwendungen entwickelt wurde, und im Internet sind zahlreiche exponierte Instanzen zu finden. Im Allgemeinen scheint sie gut abgesichert zu sein, doch dem Out-of-Bounds-Team gelang es, einen Remote-Exploit zu finden. Während viele öffentlich zugängliche Chroma-Instanzen bereits ohne Anmeldedaten erreichbar sind, könnte ein solcher Exploit den Zugriff auf ansonsten geschützte Instanzen ermöglichen und Zugang zum Host-System verschaffen. Dies ist besonders problematisch, wenn es sich um sensible Daten in diesen Datenbanken handelt. Ein Team unternahm einen Angriff auf die Oracle Autonomous AI Database, der schlug jedoch fehl.
Nvidias „Megatron Bridge“ ermöglicht die Konvertierung von Modellen des Formats von Hugging Face und dem Nemotron-Format von Nvidia. Vier Teams versuchten sich an diesem Ziel, wobei das letzte Team auf einen zuvor entdeckten Fehler stieß. Wenn eine Software beliebige Eingaben verarbeiten muss, kann ein Angreifer diese Eingaben im Rahmen seines Angriffs manipulieren. Den Teams zufolge wurden zahlreiche Schwachstellen entdeckt, obwohl letztlich nur eine einzige erforderlich war, um zu gewinnen.
Teilnehmer nutzten selbst LLMs für die Vorbereitung
Bei den Untersuchungen, an denen ich beteiligt war, befragten wir die Teilnehmer zu ihrer Nutzung von GenAI. Alle setzten im Laufe des Wettbewerbs in irgendeiner Form LLMs ein. Die meisten nutzten sie für das obligatorische Whitepaper, das jedem Exploit beizufügen ist. Insbesondere nicht englischsprachige Teams fanden LLMs für Übersetzungen nützlich (auch wenn die Wortwahl teilweise, gelinde gesagt, ungewöhnlich war). Viele setzten für die anfängliche Fehlersuche einen Programmier-Agenten ein, obwohl alle von einer hohen False/Positive-Rate in dieser Phase berichteten.
Das ist nicht überraschend und ähnelt der „normalen“ Fehlersuche, die ebenfalls oft in einer Sackgasse endet. Einige Teams gaben an, GenAI hauptsächlich für die Entwicklung von Exploits heranzuziehen, insbesondere zur Verschleierung des Angriffs, um eine Erkennung durch Endpoint Detection and Response (EDR)-Systeme zu vermeiden. Bei den Offenlegungen, an denen ich teilgenommen habe, berichtete niemand, Anthropic Mythos zu verwenden oder Teil eines KI-Sicherheitsprogramms zu sein.
Meine Erfahrung mit diesen agentischen Coding-Anwendungen ist, dass sie beim Lesen großer Codemengen helfen, das ohne KI viel länger brauchen würde. Außerdem kann ich zwar Python oder C++ gut lesen, verstehe aber nicht alle Feinheiten von Rust oder Go – doch ein agentisches Coding-Tool lässt sich davon nicht beirren. Überraschenderweise ist die zugrunde liegende Mechanik jedoch rudimentärer, als man erwarten könnte, und umfasst viel „grep“-Suche, den übermäßigen Einsatz von „find“, die Ausführung von einfachem Python-Code, das Herunterladen verwandter Inhalte aus dem Internet usw. Es gibt keine ausgefeilte Nutzung eines Satisfiability‑Modulo‑Theories‑Lösers oder Programmabhängigkeit -Graphen. Der Unterschied besteht darin, dass ein agentisches Codierungssystem die Analyse viel schneller durchführen kann als der Mensch, und das reicht aus, um einen erfahrenen Analysten nachzuahmen.
Als ich den Codierungsagenten testete, stellte ich fest, dass ich Exploits sehr nahekommen konnte, bevor der Agent die Konversation als potenziellen Verstoß gegen die Richtlinien markierte. All dies geschah ohne Zugriff auf den mysteriösen Anthropic Mythos, aber ich habe viele Tokens verwendet. Letztendlich denke ich, dass das Harness, das das GenAI-Modell antreibt, möglicherweise wichtiger ist als das GenAI-Modell selbst.
Ausblick
Für den nächsten Pwn2Own kann man davon ausgehen, dass die Teilnehmer an ihren eigenen Tools zur Fehlersuche arbeiten werden, vielleicht sogar unter Verwendung lokaler Modelle, um Informationslecks zu vermeiden. Gleichzeitig scheint es das Problem zu geben, dass durch Vibe Coding ähnlicher Code generiert wird, sodass selbst unabhängige Projekte ähnliche Probleme aufweisen können. Wir haben es weiterhin mit Angriffen auf die Softwarelieferkette und mit Programmierwerkzeugen zu tun, die missbrauchsanfällige Funktionen aufweisen. Im nächsten Jahr könnte es sowohl mehr Einreichungen als auch mehr Rückzüge geben, da sich das Tempo der Softwareentwicklung und das Tempo der Fehlersuche synchron beschleunigen.