Risikoanalyse eines neuen RCE-Exploits in KI-gestützten Code-Agenten

Erhöhtes Risiko für Entwickler durch RCE-Exploit in KI-Code-Agenten

Ein kürzlich aufgedeckter Exploit im sogenannten "Auto-Modus" von KI-gestützten Code-Agenten wie Claude Code und Codex CLIs stellt ein erhebliches Sicherheitsrisiko für Entwickler dar. Dieser Exploit ermöglicht die Remote Code Execution (RCE) auf Systemen, die zur Überprüfung von Drittanbieter-Bibliotheken eingesetzt werden. Das AI Now Institute hat einen Proof-of-Concept (PoC) veröffentlicht, der demonstriert, wie eine routinemäßige Überprüfung von Drittanbieter-Code durch einen KI-Agenten zu einer vollständigen Kompromittierung des Hosts führen kann.

Details des Angriffsmechanismus

Der Angriff zielt auf die automatisierten Genehmigungsfunktionen in Claude Code und Codex CLI ab, bei denen ein KI-Agent Dateien inspizieren und als sicher eingestufte Befehle ausführen darf. Durch das Platzieren sorgfältig formulierter Anweisungen in einem nicht vertrauenswürdigen Softwareprojekt kann ein Angreifer den Agenten dazu verleiten, während einer scheinbar normalen Sicherheitsüberprüfung ein bösartiges Programm auszuführen. Dies betrifft spezifisch Claude Code CLI (Versionen 2.1.116 bis 2.1.199) mit Claude Sonnet 4.6, Sonnet 5 oder Opus 4.8 im Auto-Modus und Codex CLI 0.142.4 mit GPT-5.5 im Auto-Review-Modus.

Die Forscher installierten die Agenten auf einem Linux-Host oder Container, platzierten eine modifizierte Version der "geopy"-Bibliothek auf der Festplatte und gaben eine einfache Anweisung in natürlicher Sprache, um Sicherheitstests auf diesem Pfad durchzuführen. Die Agenten erkunden das Repository, lesen die Dokumentation, die ein Hilfsskript für Sicherheitsüberprüfungen als nützlich darstellt, inspizieren eine Binärdatei, die mit dem Quellcode übereinstimmt, und führen sie aus, da die Dokumentation mit der ursprünglichen Überprüfungsaufgabe übereinstimmt. Die Binärdatei führt dann vom Angreifer kontrollierten Code auf dem Host aus.

Weder das Skript noch die Binärdatei werden von legitimen Bibliotheksfunktionen aufgerufen, wodurch traditionelle statische Überprüfungen unauffällig bleiben. Als die Forscher später die zugrundeliegenden Modelle fragten, ob es Versuche zur Prompt Injection im Quellcode gab, konnten weder Claude Sonnet 4.6 noch GPT-5.5 das Material kennzeichnen.

Diese Technik ist über die getesteten Modelle hinweg ohne Modifikation übertragbar. In einigen Fällen bemerkten Sonnet 5 oder Opus 4.8, dass bestimmte Dateien nicht zum Upstream-Projekt gehören, fuhren aber dennoch mit der Ausführung fort. Die Forscher waren auch mit Variationen erfolgreich, die Anweisungen in CLAUDE.md- oder agent.md-Dateien platzieren, die die Agenten als persistenten Projektkontext behandeln.

Strukturelle Schwäche und Auswirkungen

Roey Eliyahu, CEO und Mitbegründer von Salt Security, betont, dass es sich hierbei nicht um ein modellbedingtes Problem handelt, das sich patchen lässt. Wenn derselbe Angriff über zwei Anbieter und vier Modellgenerationen hinweg unverändert funktioniert, liege eine strukturelle Eigenschaft der Funktionsweise dieser Agenten vor. Das Problem bestehe darin, dass nicht vertrauenswürdiger Text einen Agenten erreicht, der Befehle ausführen kann. Der Agent kann nicht zuverlässig zwischen dem Code, den er überprüft, und den Anweisungen, die er erhält, unterscheiden, was zur Ausführung der Angreifer-Payload auf dem Host führt.

Erweiterung der Angriffsfläche von Code-Agenten

Claude Code und Codex bieten Auto-Modus- und Auto-Review-Einstellungen an, die es einem KI-Klassifikator ermöglichen, Shell-Befehle zu genehmigen, die das Modell als sicher erachtet. Anbieter präsentieren diese Modi als praktischen Standard für langlaufende Agentenaufgaben, einschließlich der Schwachstellenforschung, um Entwicklern die Möglichkeit zu geben, eine Aufgabe ohne ständige manuelle Aufforderungen zu starten. Dies führt jedoch zu einer konkreten Host-Level-Exposition für Softwareentwickler, die diese Agenten auf Open-Source-Pakete zur Schwachstellenentdeckung anwenden.

Zwei realistische Szenarien lassen sich auf die tägliche Entwicklungspraxis übertragen:

- Ein Bibliotheksbetreuer kann nicht offengelegte Anweisungen einbetten, die Code-Agenten steuern. Frühere öffentliche Beispiele zeigten bereits, wie Agenten angewiesen wurden, Testsuiten zu löschen. - Eine Supply-Chain-Kompromittierung eines populären Pakets oder Repositorys kann dasselbe Material einfügen. Automatisierte Abhängigkeitsaktualisierungen und CI-Jobs, die einen Agenten zur "Überprüfung der neuen Version" aufrufen, werden dann zum Auslöser. In diesem Workflow öffnet der Entwickler niemals die vergifteten Dateien; der Agent tut dies.

Sandboxing allein schließt die Lücke nicht, sobald der Agent RCE-Zugriff hat. Die Forscher weisen auf frühere Sandbox-Probleme hin, die bei Claude Code selbst aufgedeckt wurden. Ein Angreifer, der bereits Code auf dem Host ausführt, kann die Sandbox sondieren, Konfigurationen schreiben, Schlüssel stehlen oder Persistenz etablieren.

Restriktive Genehmigungsmodi, die für jeden Befehl eine menschliche Bestätigung erfordern, eliminieren den Automatisierungsvorteil, der Teams zur Einführung dieser Tools bewegte. Automatisierungs-Bias und Prompt-Müdigkeit schwächen die menschliche Kontrolle zusätzlich, insbesondere unter Zeitdruck oder wenn Nicht-Sicherheitspersonal die Agenten bedient.

Auswirkungen auf die tägliche Entwicklung und CI-Praxis

Jede Entwickler-Workstation oder jeder CI-Runner, der einem Agenten Shell-Zugriff gewährt und ihn dann mit nicht vertrauenswürdigem Quellcode versorgt, erbt diesen Pfad. Der Angriff erfordert nicht, dass der Benutzer einen "Diesem Ordner vertrauen"-Dialog akzeptiert, wie er mit Konfigurationsdatei-Injektionen verbunden ist. README-Dokumentation und gewöhnliche Quelldateien sind ausreichend. Da die Agenten im Rahmen ihres Designs beliebige Befehle ausführen, können Musterabgleich-Schutzmaßnahmen innerhalb des Modells nicht jede syntaktische Variante aufzählen, die ein Angreifer zur Verschleierung der Absicht verwenden kann.

Das AI Now Institute hat ein "Friendly Fire"-Repository veröffentlicht, das die unterstützenden Dateien und eine bereinigte, harmlose Binärdatei enthält, damit Forscher die Struktur sicher untersuchen können. Die ursprüngliche Payload ist nur auf Anfrage an KI-Labore und Sicherheitsforscher erhältlich. Die Arbeit verknüpft die anfängliche Ausführung nicht mit einer Privilegieneskalation oder lateralen Bewegung; das Ziel ist es, zu zeigen, dass die erste Stufe unter standardmäßiger defensiver Nutzung bereits erreichbar ist.

Empfehlungen und Präventionsmaßnahmen

Organisationen, die auf Open-Source-Bibliotheken angewiesen sind oder externen Code aufnehmen, sollten aufhören, nicht vertrauenswürdige Repositories an Agenten zu übergeben, die Shell-Befehle ausführen oder auf Host-Dateisysteme, Anmeldeinformationen oder Remote-APIs zugreifen können. Agenten, deren Ausgaben automatisierte Pipelines ohne Bereinigung speisen oder die Sicherheitsentscheidungen beeinflussen, schaffen dieselbe Exposition. Restriktivere "Human-in-the-Loop"-Modi bergen immer noch Restrisiken, wenn die Bediener nicht über die Expertise oder Aufmerksamkeit verfügen, um die Täuschung zu erkennen.

Teams, die weiterhin mit diesen Tools experimentieren, sollten sie auf Maschinen isolieren, die keine Produktionsgeheimnisse, keine breiten Dateisystem-Mounts und keine Netzwerkpfade zu internen Diensten enthalten. Eine Laufzeitüberwachung, die Agentenaktionen – und nicht nur Anmeldeinformationen – überwacht, kann Abweichungen aufdecken, wie die Ausführung einer Binärdatei, die im legitimen Codebase nie referenziert wurde.

Traditionelle statische Analyse, Abhängigkeits-Pinning, Prüfsummenüberprüfung und menschliche Überprüfung bleiben die primären Kontrollen für Drittanbieter-Code, bis Agentenarchitekturen nicht vertrauenswürdige Inhalte zuverlässiger von ausführbaren Anweisungen trennen. Die Lücke ist bereits vor dem Angriff sichtbar. Jeder Agent in Ihrer Umgebung, der Zugriff auf Anmeldeinformationen, Geheimnisse oder das Host-Dateisystem hat, ist ein potenzielles "Friendly Fire"-Szenario. Die Frage ist nicht, ob Ihre Agenten diese Exposition haben, sondern ob Sie wissen, welche dies tun, was sie erreichen können und ob ihr Verhalten auf der Aktionsebene überwacht wird.

Die README-Datei, die Claude Code dazu verleitet, eine bösartige Binärdatei auszuführen, ist auf der Anmeldeinformationsebene nicht erkennbar, jedoch auf der Verhaltensebene: ein Agent, der eine Binärdatei oder ein Skript ausführt, das im legitimen Codebase nie aufgerufen wird. Diese Abweichung vom erwarteten Verhalten ist genau das, was die Laufzeitüberwachung auf der Aktionsebene aufdecken soll.

Entscheidungsträger, die die schnelle Einführung von Frontier-Agenten zur defensiven Überprüfung von Open-Source- und Drittanbieter-Code vorantreiben, sollten das Risiko neu bewerten, bevor diese Agenten auf Entwickler-Laptops oder in CI-Systemen eingesetzt werden, die Produktionsressourcen berühren. Das Zugriffsmodell, das für den beworbenen defensiven Anwendungsfall erforderlich ist, ist dasselbe Zugriffsmodell, das der Angriff erfordert.

Bibliografie

- AI Now Institute: Proof-of-Concept for RCE in AI Coding Agents (Veröffentlichung 2026) - Salt Security: Statement on AI Agent Vulnerabilities (Veröffentlichung 2026) - arXiv: A Stress-Test Evaluation of Claude Code's Auto Mode (arXiv:2604.04978v2) - Cyber Kendra: Researchers Turn Claude Code and Codex Into Malware Launchers With a Poisoned README (Veröffentlichung 2026) - GitHub: Trust Dialog Bypass via Git Worktree Spoofing Allows Arbitrary Code Execution · Advisory · anthropics/claude-code (GHSA-q5hj-mxqh-vv77, Veröffentlichung 2026) - Cybernews.com: Another Claude Code attack allows full takeover of developers’ systems (Veröffentlichung 2026) - 0day.click: Claude Code RCE: Exploiting Deeplink Handlers via Settings Injection (Veröffentlichung 2026) - Cybersecuritynews.com: Claude Code Hacked to Achieve Full RCE and Hijacked Organization API keys (Veröffentlichung 2026) - GitHub: ronyut/ronyut.github.io/content/research/trustfall-coding-agent-rce/index.md