Claude Code Sicherheitslücke: GitHub-Repo als Falle

Die Claude Code Sicherheitslücke, die Sicherheitsforscher von Mozillas 0DIN-Plattform demonstriert haben, funktioniert so: Ein harmlos wirkendes GitHub-Repository enthält ein Setup-Skript, das den Entwicklerrechner kapert, sobald ein KI-Coding-Tool wie Claude Code das Projekt einrichtet. Der eigentliche Schadcode steht nicht im Repository. Er wird erst zur Laufzeit per DNS-Abfrage nachgeladen und ist damit weder für den Menschen noch für den KI-Agenten sichtbar (The Decoder).

Das klingt nach einem exotischen Trick. In Wahrheit ist es die Übertragung eines alten Musters auf eine neue Umgebung.

Wie funktioniert die Claude Code Sicherheitslücke konkret?

Ein Angreifer legt ein normal aussehendes Projekt auf GitHub ab. Im Setup-Schritt liegt ein Skript, das beim Einrichten ausgeführt wird. Statt den Schadcode offen zu hinterlegen, lädt das Skript ihn zur Laufzeit über eine DNS-Abfrage nach. So sehen weder ein flüchtiger Blick ins Repository noch der KI-Agent etwas Verdächtiges, weil der gefährliche Teil zum Prüfzeitpunkt schlicht nicht da ist.

Der entscheidende Punkt ist die fehlende Prüfung. Ein KI-Agent, der ein Projekt einrichtet, führt Setup-Befehle oft ohne Rückfrage aus, weil genau das den Komfort solcher Tools ausmacht. Diese Bequemlichkeit ist hier die Angriffsfläche. Was als Zeitersparnis gedacht war, wird zur ungeprüften Ausführung fremden Codes.

Mozillas 0DIN, eine Plattform für die Meldung von Schwachstellen in KI-Systemen, hat das als Proof of Concept gezeigt, nicht als aktive Kampagne im Feld. Diese Unterscheidung ist wichtig: Es geht um die belegte Machbarkeit, nicht um eine dokumentierte Angriffswelle.

Ist das wirklich neu oder nur ein altes Problem in neuem Gewand?

Neu ist der Schauplatz, nicht das Prinzip. Schadcode, der erst zur Laufzeit nachgeladen wird, und manipulierte Pakete in Lieferketten kennen Sicherheitsteams seit Jahren. Die KI-Coding-Schicht verschärft das Risiko, weil ein Agent Schritte automatisiert, die früher ein Mensch zumindest kurz gesehen hat.

In der Diskussion um Claude-Code-Risiken tauchten bereits zuvor verwandte Schwachstellen auf, etwa Exploit-Ketten über npm-Post-Install-Hooks und manipulierten Konfigurationsdateien (Computerwoche, 2026), sowie das Versagen konfigurierter Sperr-Regeln bei komplexen Befehlsketten (all-about-security, 2026). Der rote Faden über all diese Befunde: Der Agent führt aus, was die Umgebung ihm vorlegt, und die Schutzregeln greifen nicht zuverlässig, sobald die Angreifer die Befehle geschickt verschachteln.

Aus meiner Beratungspraxis sehe ich genau hier die Lücke zwischen Demo und Dauerbetrieb. KI-Coding-Tools werden gekauft, weil sie Entwicklung beschleunigen. Über die Frage, was passiert, wenn der Agent einen fremden Befehl ausführt, denkt im Pilotprojekt selten jemand nach.

Welche konkreten Schritte schützen Entwicklerrechner?

Der Schutz beginnt beim Prinzip, nicht beim einzelnen Tool. Behandeln Sie jedes fremde Repository wie nicht vertrauenswürdigen Code und entziehen Sie dem KI-Agenten die Freiheit, beliebige Befehle ungeprüft auszuführen. Die wirksamsten Maßnahmen sind organisatorisch und technisch zugleich:

• Keine automatische Ausführung von Setup-Skripten. Fremde Projekte erst lesen, dann erst einrichten. Wo der Agent Befehle ausführen will, sollte eine Bestätigung dazwischen liegen.
• Sandboxing und Container. Unbekannte Repositories in einer isolierten Umgebung öffnen, die keinen Zugriff auf Produktivdaten, SSH-Schlüssel oder Cloud-Tokens hat.
• Minimale Rechte auf dem Entwicklerrechner. Je weniger ein Skript erreichen kann, desto begrenzter der Schaden, wenn es doch ausgeführt wird.
• Ausgehenden Netzwerkverkehr beobachten. Da der Schadcode per DNS nachgeladen wird, fällt der Angriff auf, wenn ungewöhnliche DNS-Abfragen sichtbar werden.
• Abhängigkeiten und Hooks prüfen. Post-Install-Hooks und nachgelagerte Pakete gehören zu den häufigsten Einfallstoren und lassen sich automatisiert scannen.

Keine dieser Maßnahmen ist spektakulär. Genau das ist der Punkt: Solide Lieferketten-Hygiene schützt zuverlässiger als jedes nachgerüstete Sicherheitsfeature.

Wer KI-Coding-Tools im Team produktiv und mit klaren Leitplanken einsetzen will, statt nur in Demos, findet in einem praxisnahen Workshop zum sicheren Arbeiten mit Claude Code einen strukturierten Einstieg, inklusive der Frage, wie weit Sie einem Agenten Ausführungsrechte überhaupt geben sollten. Sinnvoll vor allem für Teams, die das Tool bereits nutzen und die Konfiguration absichern müssen; wer noch gar nicht einsteigt, braucht das nicht.

Wer trägt die Verantwortung, der Anbieter oder das Team?

Beide, aber nicht symmetrisch. Anbieter wie Anthropic müssen Standardeinstellungen sicherer machen und die Ausführung fremder Befehle stärker begrenzen. Eine spezifische, aktuelle Stellungnahme von Anthropic zu genau diesem 0DIN-Szenario liegt mir nicht vor, das gehört zur ehrlichen Einordnung. Die laufende Konfiguration und die Arbeit mit fremdem Code aber verantwortet das Team, denn dort fällt die Entscheidung, was ausgeführt wird.

Das deckt sich mit dem, was sich bei autonomen Agenten generell zeigt: Sie übernehmen eng umrissene Aufgaben gut, scheitern aber dort, wo Urteil und Verantwortung gefragt sind. Wie weit man Agenten überhaupt eigenständig handeln lassen sollte, beleuchtet auch unsere Analyse dazu, wo der CEO-Bench die Grenzen von KI-Agenten zeigt.

Mein Eindruck als Berater: Die größte Schwachstelle ist nicht das Tool, sondern die Annahme, ein KI-Agent prüfe das, was er ausführt. Er tut es nicht. Er führt aus, was die Umgebung ihm vorlegt.

Zurück zur Ausgangsfrage, wie ein harmloser GitHub-Link zur Falle wird. Die Antwort ist unbequem schlicht: weil Bequemlichkeit und Sicherheit hier direkt gegeneinander stehen. Solange ein Setup-Skript ungeprüft läuft, verschiebt jedes KI-Coding-Tool nur die Stelle, an der der fremde Code ausgeführt wird, nicht die Frage, ob Sie ihm trauen sollten. Der nächste Schritt für Ihr Team ist deshalb kein neues Werkzeug, sondern eine klare Regel: Welche Befehle darf ein Agent ohne Rückfrage ausführen, und welche nicht?