Am 31. März 2026 wurden durch eine einzige fehlerhaft konfigurierte Datei 512.000 Zeilen des proprietären Quellcodes von Anthropic öffentlich zugänglich gemacht. Es handelte sich weder um einen Hack noch um einen ausgeklügelten Angriff, sondern lediglich um eine übersehene Einstellung in einer Build-Konfiguration. So einfach war es, die internen Abläufe von Claude Code für jeden mit einem npm-Konto zugänglich zu machen.
Wenn Sie in Ihrem Unternehmen KI-gestützte Softwareentwicklung einsetzen, ist dieser Vorfall von großer Bedeutung. Es geht nicht um Anthropic, sondern darum, welche Schwachstellen Ihre eigene Entwicklungspipeline möglicherweise gerade unbemerkt offenbart. Heute sprechen wir darüber, wie Sie diese neuen Risiken verstehen und minimieren können.
Was geschah wirklich beim Claude-Code-Leak?
Hier eine kurze Zusammenfassung: Anthropic liefert Claude Code als Closed-Source-Paket mit verschleiertem Quellcode über npm aus. Am 30. März 2026 veröffentlichten sie Version 2.1.88, die eine Quellcode-Map-Datei namens cli.js.map enthielt, welche auf den vollständigen, unverschlüsselten TypeScript-Quellcode verwies.
Der Sicherheitsforscher Chaofan Shou machte am 31. März als Erster öffentlich darauf aufmerksam, dass der gesamte Quellcode von Claude Code über eine im npm-Repository veröffentlichte Source-Map-Datei offengelegt worden war. Innerhalb weniger Stunden wurde der Code auf GitHub archiviert und im Internet gespiegelt.
Der geleakte Quellcode umfasste fast 2.000 TypeScript-Dateien und mehr als 512.000 Codezeilen. Das GitHub-Repository, in dem er gesichert war, hatte über 84.000 Sterne und 82.000 Forks.
Anthropic bestätigte den Vorfall: Ein Sprecher teilte The Register mit, es handele sich um „ein Problem mit der Verpackung einer Veröffentlichung, das auf menschliches Versagen zurückzuführen ist, nicht um eine Sicherheitslücke“, und dass keine Kundendaten oder Zugangsdaten betroffen seien.
Das ist eine typische Folge menschlichen Versagens und einer der vielen Gründe, warum Entwickler heutzutage Automatisierung einsetzen. Hätte eine vollständige Automatisierung des Release-Prozesses dieses Problem jedoch verhindern können? Schauen wir uns den Claude-Code-Leak und seine Auswirkungen auf die KI-Automatisierung und -Entwicklung im großen Maßstab genauer an.
Die technischen Mechanismen: Warum der Code-Leak von Claude so leicht zu übersehen war
Wenn Sie kein Entwickler sind, hier eine Kurzfassung, wie so etwas passieren kann. Beim Erstellen von JavaScript- oder TypeScript-Anwendungen wird der Code absichtlich gebündelt und minimiert (also stark komprimiert, sodass er kaum noch lesbar ist). Source-Map-Dateien sind Debugging-Tools, die diesen Vorgang umkehren. Sie ordnen den minimierten Code dem ursprünglichen Quellcode zu. Auf Ihrem Rechner ist das sehr nützlich, kann aber im Produktivbetrieb problematisch werden.
Laut der Analyse des offengelegten Claude-Code-Quellcodes entstand das Leck durch einen Verweis auf einen nicht verschleierten TypeScript-Quellcode in der im npm-Paket enthaltenen Map-Datei.
Ein einziges falsch konfiguriertes .npmignore- oder files-Feld in der package.json-Datei kann alles offenlegen.
Manchmal reicht schon eine einzige Datei oder eine übersehene Ausnahme, und schon steckt man in großen Schwierigkeiten. Im Fall von Anthropic generierte die Build-Toolchain (angeblich Bun) Source Maps, die nicht vom veröffentlichten Artefakt ausgeschlossen wurden, sodass die .npmignore-Konfiguration sie nicht berücksichtigte. Man kann es sich so vorstellen: Es ist, als würde man seine interne Roadmap auf die Rückseite jedes ausgelieferten Produkts drucken. Das Produkt funktioniert zwar einwandfrei, aber jeder, der es weitergibt, weiß nun alles darüber.
Genau das macht den Claude-Code-Leak so lehrreich für Entwicklerteams. Der Fehler wurde nicht durch eine extreme oder ungewöhnliche Kombination von Faktoren verursacht, sondern durch etwas, das in jedem schnelllebigen Team mit häufigen Releases vorkommen kann. Der einzig zuverlässige Weg, ähnliche Probleme zu erkennen, besteht darin, die richtigen Prüfungen vor der Veröffentlichung einzurichten, nicht erst danach.
Was enthielt der durchgesickerte Claude-Code?
Das Leck enthielt das geistige Eigentum und die interne Roadmap von Anthropic, praktisch vollständig. Folgendes fand die Community in den 1.906 TypeScript-Dateien:
Architektur und Werkzeuge:
- Eine auf Plugins basierende Werkzeugarchitektur mit etwa 40 einzelnen Werkzeugen (Dateilesen, Bash-Ausführung, LSP-Integration), die jeweils durch Berechtigungen geschützt sind
- Eine Abfrage-Engine mit 46.000 Zeilen, die alle LLM-API-Aufrufe, Streaming, Caching und Tool-Aufrufschleifen verarbeitet.
- Multiagenten-Orchestrierungslogik, die bisher nicht dokumentiert war
Noch nicht veröffentlichte Funktionen:
- Eine Funktion namens KAIROS ist ein permanenter Hintergrundprozess, der regelmäßig Fehler behebt oder Aufgaben autonom ausführt und Push-Benachrichtigungen versendet, ohne auf Benutzereingaben zu warten. Ergänzend dazu gibt es einen „Traummodus“, der es Claude ermöglicht, im Hintergrund kontinuierlich Ideen zu entwickeln.
- Ein Begleittier im Tamagotchi-Stil (eine deterministische Spezies basierend auf Ihrem Benutzer-ID-Hash), dessen interne Veröffentlichung für April 2026 und dessen vollständige Markteinführung für Mai 2026 geplant ist.
Darüber hinaus zeigt der im geleakten Code enthüllte „Undercover-Modus“, dass Anthropic Claude Code nutzt, um unbemerkt Beiträge zu öffentlichen Open-Source-Repositories zu leisten. Die Systemmeldung für diesen Modus lautet: „Sie arbeiten im Undercover-Modus in einem öffentlichen Open-Source-Repository. Ihre Commit-Nachrichten, PR-Titel und PR-Texte DÜRFEN KEINE internen Anthropic-Informationen enthalten. Lassen Sie Ihre Tarnung nicht auffliegen.“
Dieses Detail sorgte insbesondere in der Entwicklergemeinschaft für heftige Kontroversen, da es einen KI-Agenten zeigt, der absichtlich inkognito in öffentlichen Repositories operiert. Ob man das nun besorgniserregend findet oder nicht, Fakt ist: Diese Information war nie für die Öffentlichkeit bestimmt. Nun ist sie jedoch unauslöschlich im Gedächtnis des Internets verankert.
Darüber hinaus enthüllte der Code-Leak von Claude interne Details zur Performance des Modells. Der Code bestätigt, dass Capybara der interne Codename für eine Variante von Claude 4.6 ist. Entwickler stellten eine Fehlalarmrate von 29–30 % in Version 8 fest, was im Vergleich zu den 16,7 % in Version 4 einen tatsächlichen Rückgang darstellt. Sie bemerkten außerdem ein „Gegengewicht zur Durchsetzungsfähigkeit“, das verhindern soll, dass das Modell bei Refaktorierungen zu aggressiv vorgeht. Für Wettbewerber ist dies ein neuer Maßstab, und für Sicherheitsforscher liefert es einen Überblick über die Schutzmechanismen und deren Funktionsweise.
Die größere Bedrohung: Der Axios-Lieferkettenangriff
An dieser Stelle wird die Geschichte für Ihr Team deutlich ernster. Der Claude-Code-Leak war zwar peinlich für Anthropic, stellte aber keine direkte Sicherheitslücke für die Nutzer dar. Der zeitgleiche Axios-Angriff hingegen war eine Bedrohung von höchster Priorität.
Am 30./31. März 2026 wurde das Axios-npm-Paket Opfer eines der bis dato schwerwiegendsten Angriffe auf die npm-Lieferkette. Mit über 100 Millionen Downloads pro Woche ist Axios ein grundlegender HTTP-Client, der im gesamten JavaScript-Ökosystem weit verbreitet ist. Ein Angreifer kaperte das npm-Konto des Hauptentwicklers und veröffentlichte zwei manipulierte Versionen, die einen plattformübergreifenden Remote-Access-Trojaner (RAT) auf jedem Rechner installierten, auf dem `npm install` ausgeführt wurde.
Nutzer, die Claude Code am 31. März 2026 zwischen 00:21 und 03:29 UTC über npm installiert oder aktualisiert haben, haben möglicherweise versehentlich eine schädliche Version von axios (1.14.1 oder 0.30.4) installiert, die einen Remote-Access-Trojaner enthält. Sie sollten umgehend die Projekt-Sperrdateien auf diese spezifischen Versionen oder die Abhängigkeit plain-crypto-js überprüfen.
Microsoft Threat Intelligence ordnete die Kompromittierung von Axios npm der nordkoreanischen Terrororganisation Sapphire Sleet zu. Es handelte sich nicht um einen opportunistischen Angriff, sondern um einen gezielten, zeitlich präzise geplanten Anschlag mit maximaler Wirkung.
Der Angriff war erfolgreich, weil er eine Vertrauenslücke ausnutzte, die in nahezu jedem modernen JavaScript-Projekt existiert: Der Angreifer verwendete ein gestohlenes, langlebiges npm-Zugriffstoken, um direkt im npm-Repository zu veröffentlichen und so die CI/CD-Pipelines vollständig zu umgehen. Legitime Axios-Releases enthalten OIDC-Provenienz-Metadaten, die das npm-Paket mit einem bestimmten GitHub-Actions-Lauf verknüpfen. Die manipulierten Versionen enthielten diese Metadaten nicht, da sie direkt veröffentlicht wurden und somit keine nachvollziehbare Build-Spur hinterließen. Die meisten Teams hätten daher nichts von dem Problem bemerkt.
Was beide Vorfälle über Ihre Pipeline aussagen
Zwei separate Vorfälle am selben Tag, im selben Softwarepaket-Ökosystem. Das ist kein Zufall, sondern ein Muster. Und es deutet auf strukturelle Risiken hin, die in den meisten modernen Entwicklungspipelines vorhanden sind.
- Durchsickern von Artefakten
Die meisten Teams führen vor der Veröffentlichung nie `npm pack –dry-run` aus. Sie vertrauen darauf, dass die Build-Toolchain korrekt arbeitet. Auch das Team von Anthropic tat dies, was zum Code-Leak von Claude führte. Source Maps, interne Konfigurationen, `.env.example`-Dateien mit realistisch wirkenden Werten – all dies kann unbemerkt in einem veröffentlichten Paket landen. - Blindheit gegenüber der Abhängigkeit von Dritten
Die Analyse von Angriffen in den Jahren 2025–2026 zeigt ein wiederkehrendes Muster: Angreifer verschaffen sich zunächst über kompromittierte Zugangsdaten Zugriff, und dieselbe Angriffskette wiederholt sich. Systemadministratoren werden Opfer von Phishing, Zugangsdaten werden missbraucht, und Schadcode bleibt viel zu lange unentdeckt. Claude Code nutzte Axios, und Ihre Anwendung wahrscheinlich auch. - Übermäßige Abhängigkeit von automatisierten Installationen
Die Ausführung von `npm install` in einer CI/CD-Pipeline ohne Überprüfung der Herkunft, Versionsfixierung oder SBOM-Tracking ist für die meisten Teams Standard. So gelangt auch eine RAT (Remote Access Trojan) ohne einen einzigen verdächtigen Klick auf den Rechner eines Entwicklers. - Fehlende Veröffentlichungstore
Die Lehre aus dem Claude-Code-Leak ist eindeutig: Die Datei `.npmignore` ist ressourcenintensiv. Sie sollte wie eine Sicherheitsbarriere behandelt werden. Die meisten Entwicklerteams haben keinen formalen Prüfschritt zwischen dem Erstellen und Veröffentlichen des Build-Prozesses. Genau in dieser Lücke entstehen solche Vorfälle.
Das ist keine reine Theorie; beispielsweise kaperten Angreifer im September 2025 18 beliebte npm-Pakete, die zusammen wöchentlich über 2 Milliarden Mal heruntergeladen werden. Solche Angriffe finden in großem Umfang statt und treffen reale Teams.
Was Ihr Team jetzt tun sollte
Folgendes sollte eine Überprüfung Ihrer Pipeline umfassen, angesichts der Ereignisse vom 31. März:
Überprüfen Sie Ihre npm-Veröffentlichungskonfiguration vor Ihrem nächsten Release. Führen Sie `npm pack –dry-run` aus und untersuchen Sie jede Datei, die mitgeliefert werden soll. Achten Sie auf Folgendes:
- Alle .map-Dateien in dist/
- Versehentlich miteinbezogene Quellverzeichnisse
- Konfigurationsdateien mit internen Pfaden oder Tokens
Kennzeichnen Sie Ihre .npmignore-Datei als Sicherheitsgrenze und nehmen Sie sie in jede Release-Checkliste auf.
Fixieren Sie Ihre kritischen Abhängigkeiten, indem Sie das Caret-Zeichen (^) und die Tilde (~) aus der package.json-Datei für Bibliotheken wie Axios entfernen, die tief in Ihrem Abhängigkeitsbaum liegen. Microsoft empfiehlt, die automatischen Aktualisierungsfunktionen für npm-Pakete in Organisationen zu deaktivieren, in denen die Sicherheitslage vor der Bereitstellung überprüft werden muss.
Überprüfen Sie jetzt Ihre Sperrdateien, falls Sie oder Ihr Team am 31. März 2026 zwischen 00:21 und 03:29 UTC den Befehl „npm install“ ausgeführt haben. Suchen Sie umgehend in Ihren Sperrdateien:
grep -r "1.14.1\|0.30.4\|plain-crypto-js" package-lock.jsonFür alle internen und kritischen Drittanbieterpakete sind Herkunftsprüfungen mit `npm publish` und SLSA Level 2+ erforderlich. Fehlt die OIDC-Herkunft bei einer neuen Version eines Hauptpakets, sollte eine automatische Warnung ausgelöst werden. Die meisten Teams haben dies noch nicht eingerichtet, da sie es bisher nicht benötigt haben.
Fügen Sie Ihrer CI/CD-Pipeline für jedes Release einen Veröffentlichungsprüfungsschritt hinzu. Integrieren Sie einen Schritt zur Artefaktprüfung vor der Veröffentlichung, der Quellzuordnungen, Debug-URLs und sourceMappingURL-Direktiven in Ihrer endgültigen verteilten Ausgabe überprüft.
Überprüfen Sie die Verwendung Ihrer KI-Codierungswerkzeuge in sensiblen Umgebungen und verfolgen Sie beim Einsatz von Claude Code in unbekannten Umgebungen eine Zero-Trust-Strategie. Vermeiden Sie die Ausführung des Agenten in frisch geklonten oder nicht vertrauenswürdigen Repositories, bis Sie die Datei `.claude/config.json` und alle benutzerdefinierten Hooks manuell geprüft haben. Dasselbe gilt für alle KI-Werkzeuge mit Dateisystem- und Shell-Zugriff. Wir haben dies ausführlich in unserem Artikel zu den Best Practices für OpenClaw-Sicherheit erläutert.
Die übergeordnete Frage: Wie gut kennen Sie Ihre Pipeline?
Die meisten Gründer und Entwicklungsleiter können ihre Produktarchitektur detailliert beschreiben. Weniger jedoch können mit der gleichen Sicherheit genau beschreiben, was ihre CI/CD-Pipeline ausliefert, welchen Abhängigkeiten sie automatisch vertraut und was ein Angreifer mit einem kompromittierten npm-Token ihren Entwicklern morgen präsentieren könnte.
Der Schlüssel zur Vermeidung von Vorfällen wie dem Claude-Code-Leak liegt in der Entwicklung geeigneter Prüfprozesse, die eine schnelle und risikofreie Auslieferung ermöglichen. Ein professionelles Software-Audit, das Build-Konfiguration, Abhängigkeitskette, CI/CD-Pipeline und Veröffentlichungsprozess umfasst, dauert Tage, nicht Wochen. Der Anthropic-Vorfall erstreckte sich über Stunden, und das Angriffsfenster für Axios betrug lediglich 39 Minuten.
Wenn Sie KI-gestützte Entwicklungstools einsetzen und sicherstellen möchten, dass die dazugehörige Pipeline sicher und ordnungsgemäß verwaltet wird, ist Redwerk genau der richtige Partner für Technologieunternehmen – und das schon seit 2005. Unser Code-Review-Service umfasst die Konfiguration von Builds und Abhängigkeiten, und unsere DevOps-Beratung beinhaltet die Härtung von CI/CD, wodurch die Wahrscheinlichkeit solcher Vorfälle für Ihr Team deutlich sinkt.
Der Claude-Code-Leak entstand durch eine einzige falsch konfigurierte Datei. Der Axios-Angriff war erfolgreich, weil ein Konto kompromittiert und ein npm-Token ungeschützt war. Beides sind Beispiele für kleine, prozessbezogene Fehler, die selbst erfahrene Teams übersehen, bis es nicht mehr anders geht.
Was der 31. März wirklich offenbart hat, ist nicht, dass Anthropic einen Fehler gemacht hat. Vielmehr zeigt er, dass die moderne JavaScript-Entwicklungspipeline mit ihren komplexen Abhängigkeitsstrukturen, automatisierten Installationen und standardmäßig vertrauenswürdigen Paketregistrierungen deutlich angreifbarer ist, als den meisten Teams bewusst ist. Und je schneller Sie veröffentlichen, desto wahrscheinlicher ist es, dass irgendwo zwischen Ihrem Code und Ihren Nutzern eine Sicherheitslücke besteht. Wenn Sie dies in Ihrer Pipeline verhindern möchten, kontaktieren Sie uns. Lassen Sie uns gemeinsam Ihre Sicherheitslücken schließen.
Check out how we helped Complete Network's Project Science boost code maintainability by 80%
