Anthropics Claude Code Leak: Was Entwicklerteams jetzt wi...

Robin Böhm

· Veröffentlicht am 02.04.2026

TL;DR: Am 31. März 2026 veröffentlichte Anthropic versehentlich über 512.000 Zeilen TypeScript-Quellcode seines KI-Programmierwerkzeugs Claude Code auf npm – ausgelöst durch eine fehlende .npmignore-Konfiguration. Der Vorfall ist ein Lehrstück über Supply Chain Security, NPM-Publishing-Prozesse und Incident Response. Anthropic, das US-amerikanische KI-Unternehmen hinter dem Sprachmodell Claude, hat am 31. März 2026 versehentlich den gesamten Quellcode seines KI-Coding-Assistenten Claude Code öffentlich zugänglich gemacht. Auslöser war ein menschlicher Fehler beim Veröffentlichen eines npm-Pakets: Version 2.1.88 enthielt eine 59,8 MB große Source Map, über die sich 512.000 Zeilen proprietären TypeScript-Quellcodes rekonstruieren ließen. Innerhalb weniger Stunden wurde das Repository auf GitHub über 50.000 Mal geforkt – und der Code ist seitdem permanent im Netz verteilt.

Die wichtigsten Punkte

• 📅 Datum: 31. März 2026, entdeckt um ca. 04:23 UTC
• 🎯 Betroffene Teams: Alle Organisationen, die npm-Pakete veröffentlichen oder KI-Coding-Tools einsetzen
• 💡 Kernursache: Fehlende .npmignore-Konfiguration ließ eine Source Map im npm-Paket
• 🔧 Tech-Stack: npm, TypeScript, Cloudflare R2 Storage, GitHub
• ⚠️ Schadensausmaß: 512.000 Zeilen Code, ~50.000+ GitHub-Forks, DMCA-Maßnahmen weitgehend wirkungslos

Was ist passiert – und was bedeutet das für Teams?

Claude Code ist Anthropics kommerzieller KI-Programmierassistent, der Entwickler beim Schreiben und Debuggen von Code unterstützt. Bei einem Routine-Update wurde Version 2.1.88 auf npm veröffentlicht – mit einem kritischen Konfigurationsfehler: Eine Source Map, die normalerweise nur für das interne Debugging gedacht ist, wurde nicht aus dem Paket ausgeschlossen. Diese Source Map referenzierte eine TypeScript-Quelldatei auf einem öffentlich zugänglichen Cloudflare R2 Storage Bucket. Das Ergebnis: Sicherheitsforscher Chaofan Shou entdeckte die Lücke und machte sie auf X publik. Der Post erzielte über 28,8 Millionen Aufrufe. Das exportierte Repository wuchs in weniger als zwei Stunden auf über 50.000 Stars – laut Berichten eines der am schnellsten wachsenden GitHub-Repositories der Geschichte. Anthropic zog das betroffene npm-Paket nach ca. acht Stunden zurück und bestätigte: „Eine Veröffentlichung von Claude Code enthielt heute einen Teil des internen Quellcodes. Es waren keine sensiblen Kundendaten oder Anmeldedaten betroffen.” Das Unternehmen bezeichnete den Vorfall als „Problem bei der Veröffentlichung, das durch menschliches Versagen verursacht wurde, nicht um eine Sicherheitslücke.”

Was der Leak offenbarte – und warum das relevant ist

Der Quellcode enthielt mehr als nur Implementierungsdetails. Die Community entdeckte im Code:

• Self-Healing Memory Architecture: Ein dreistufiges Memory-System mit MEMORY.md (Index), On-Demand-Topic-Files und Session-Transcripts, das automatisch Memories zusammenführt, dedupliziert und während Inaktivitätsphasen bereinigt
• KAIROS: Ein autonomer Background-Agent-Modus, der zum Zeitpunkt des Leaks noch nicht öffentlich verfügbar war
• Strukturierte Memory-Systeme: File-Read-Deduplication, Tool-Result-Sampling und QueryEngine für die Core-Agent-Infrastruktur Für Teams, die KI-Coding-Tools im Unternehmenseinsatz evaluieren oder bereits nutzen, wirft das Fragen auf: Welche Informationen verarbeiten diese Tools, und wie werden sie intern gehandhabt?

Die eigentliche Lektion: Supply Chain Security bei npm

Der Vorfall ist vor allem ein Lehrstück für alle Teams, die npm-Pakete veröffentlichen – ob für interne Tools oder öffentliche Libraries. Die Ursachenkette ist erschreckend einfach: Fehlkonfiguration → Source Map im Paket → Öffentlicher Storage-Bucket → Vollständiger Code-Leak Jeder Schritt wäre mit Standardpraktiken vermeidbar gewesen:

1. .npmignore oder files-Feld in package.json korrekt konfigurieren – Source Maps, Build-Artefakte und Debug-Dateien müssen explizit ausgeschlossen werden
2. Pre-Publish-Checks automatisieren – Vor jeder Veröffentlichung sollte automatisch geprüft werden, welche Dateien tatsächlich im Paket landen (z. B. mit npm pack --dry-run)
3. Interne Assets niemals in öffentlich zugänglichem Storage ablegen – Was von einem npm-Paket referenziert wird, muss mit Authentifizierung geschützt sein
4. Build-Pipelines um Security-Gates erweitern – Ein automatischer Scan auf versehentlich enthaltene Geheimnisse, Credentials oder Source Maps sollte Standard sein

Incident Response: Acht Stunden sind zu lang

Anthropic reagierte professionell und transparent – aber das Zeitfenster von acht Stunden zwischen Entdeckung und Paket-Rückzug war zu lang. Bis dahin hatte sich der Code bereits unwiderruflich verteilt. Die DMCA-Maßnahmen blieben weitgehend wirkungslos: Entwickler erstellten DMCA-resistente Clean-Room-Rewrites, dezentrale Mirrors gingen online. Für Teams bedeutet das: Incident-Response-Pläne müssen npm-Veröffentlichungsfehler explizit abdecken. Die Eskalationskette, den Ablauf der Paket-Rücknahme und die Kommunikation sollten vorab definiert sein – nicht erst, wenn der Tweet mit 28 Millionen Views bereits online ist.

Was bedeutet das für Teams und Organisationen?

Der Anthropic-Vorfall trifft einen wunden Punkt: Auch gut kapitalisierte, technologisch führende Unternehmen sind vor einfachen Konfigurationsfehlern nicht gefeit. Die Lernkurve für Entwicklerteams ist steil – und die Konsequenzen können weitreichend sein:

• Geistiges Eigentum kann irreversibel kompromittiert werden
• Wettbewerber erhalten Einblick in proprietäre Architekturentscheidungen
• Angreifer können Schwachstellen in der internen Logik identifizieren, bevor Patches ausgerollt werden
• Reputationsschäden entstehen, auch wenn keine Kundendaten betroffen sind Die gute Nachricht: Die technischen Gegenmaßnahmen sind bekannt und umsetzbar. Was fehlt, ist oft die organisatorische Verankerung – als Teil von Code Reviews, CI/CD-Pipelines und Security-Training.

Praktische nächste Schritte

1. npm-Publishing-Prozesse im eigenen Team auditieren: Sind .npmignore und files-Felder in allen Paketen korrekt konfiguriert? Wird regelmäßig mit npm pack --dry-run geprüft?
2. Secrets-Scanning in CI/CD integrieren: Tools wie GitLeaks, Trufflehog oder GitHub Advanced Security können versehentlich eingebettete Credentials und Source Maps erkennen
3. Incident-Response-Playbook für Veröffentlichungsfehler erstellen: Wer entscheidet über einen Paket-Rückzug? Wie wird kommuniziert?
4. Security-Schulung für alle, die npm-Pakete veröffentlichen: Nicht nur Entwickler, auch DevOps und CI/CD-Verantwortliche müssen die Risiken kennen