Claude Code Source Map Leak
Anthropic hat eine Source Map mit dem Code darin ausgeliefert. Teams sollten das als Release-Fehler betrachten.
Anthropic hat @anthropic-ai/claude-code@2.1.88 mit cli.js.map im Tarball auf npm veröffentlicht. Ich habe das Paket aus dem Registry heruntergeladen und selbst überprüft. Die Source Map enthielt 4.756 eingebettete Quellcode-Einträge. Wenn man node_modules entfernt, exponierte das Paket immer noch 1.906 von Anthropic besessene Dateien und etwa 515.000 Codezeilen, fast alles TypeScript oder TSX.
Wenn eine Source Map mit sourcesContent ausgeliefert wird, haben Sie keine harmlose Debug-Datei ausgeliefert. Sie haben Quellcode in JSON ausgeliefert.
Als ich nachsah, hatte Anthropic bereits mit der Bereinigung begonnen. Die npm-Versionsseite wurde als veraltet markiert mit der Nachricht Unpublished. Das offizielle GitHub-Repository und die Setup-Dokumentation kennzeichnen die npm-Installation jetzt als veraltet und leiten Benutzer zum nativen Installer um. Die Reaktion war schnell. Das Artefakt war bereits öffentlich.
Kopien und Analysen waren zu diesem Zeitpunkt bereits im Umlauf. So verhalten sich öffentliche Artefakte im Internet. Sobald etwas Nützliches in einem Registry landet, ist die Bereinigung ein Kampf gegen den Wind.
Wenn Sie sich mehr dafür interessieren, was der exponierte Code über das Agenten-Design aussagt, als für das Leck selbst, hat Shreyansh einen separaten Artikel über die Architektur von Claude Code, die uns über den Aufbau von Produktions-KI-Agenten lehrt geschrieben. Dieser Beitrag befasst sich mit dem langweiligeren Teil, der Release-Hygiene, denn langweilige Fehler richten immer noch großen Schaden an.
Was wurde ausgeliefert
Hier ist, was ich aus dem npm-Paket, den Registry-Metadaten und den öffentlichen Seiten von Anthropic verifizieren konnte:
@anthropic-ai/claude-code@2.1.88 wurde als öffentliches Paket auf npm veröffentlicht.- Der Tarball enthielt
cli.js.map neben cli.js, README.md, LICENSE.md, package.json, bun.lock und sdk-tools.d.ts.
cli.js.map enthielt ein ausgefülltes sourcesContent-Array.- Die Map enthielt insgesamt 4.756 eingebettete Dateien.
- Ohne
node_modules deckte die Map immer noch 1.906 von Anthropic besessene Dateien ab.
- 1.888 dieser Dateien waren
.ts oder .tsx.
- Der von Anthropic besessene Teil der Map enthielt etwa 515.000 Zeilen.
- Die npm-Seite markierte die Version später als veraltet mit der Autorennachricht
Unpublished.
- Anthropic's Repository und Setup-Dokumentation kennzeichnen die npm-Installation jetzt als veraltet.
Ich reproduziere bewusst keinen Code aus der Map und verlinke keine Spiegel-Repositories. Es gibt bereits genügend öffentliches Rauschen darum. Dieses Paket exponierte weit mehr als nur ein CLI-Binary.
Warum das wichtig ist
Leute reden immer noch über Source Maps, als wären sie harmlose Überbleibsel. Manchmal sind sie das. Source Maps können ein geringes Risiko darstellen, wenn sie innerhalb des privaten Fehler-Trackings bleiben und die ursprüngliche Quelle weglassen. Eine öffentliche Map mit sourcesContent ist eine Quellcode-Veröffentlichung.
Was mich am meisten störte, war, wie alltäglich diese Fehlerquelle ist. Die Map erklärte nicht nur Stack Traces. Sie enthüllte interne Strukturen, Prompt-Verdrahtung, Routing-Logik, Telemetrie-Pfade, Feature-Flag-Plumbing und Orchestrierungsentscheidungen. Ich halte diese Beschreibung bewusst auf hohem Niveau. Ich möchte keinen Sicherheitspost in eine geführte Tour durch den Code eines anderen verwandeln.
Für ein KI-Coding-Produkt senkt diese Art von Leck die Kosten für Prüfung, Nachahmung und Angriffsplanung. Das Reverse Engineering eines gebündelten CLIs dauert seine Zeit. Das Lesen einer Source Map mit dem bereits eingebetteten Code dauert Minuten.
Gleiche Familie, anderer Grund
Ich habe letzte Woche über den Telnyx PyPI-Kompromiss geschrieben. Dieser war böswillig. Dieser hier sieht nach einem Fehler im Release-Engineering aus. Operativ gesehen reimen sie sich.
Ich komme immer wieder auf eine Zeile zurück: Das Artefakt ist die Grenze.
Teams verbringen die meiste Energie mit Anwendungscode und Laufzeitkontrollen und behandeln dann das Paket, das Container-Image, die GitHub Action, das Helm-Chart und das Browser-Bundle wie Verpackungsdetails. Angreifer machen diesen Unterschied nicht. Unfälle auch nicht.
Wir haben das gleiche Muster gesehen beim xz-Backdoor, bei Kompromittierungen von GitHub Actions, bei PyPI-Credential-Stealern, bei bösartigen npm-Updates, bei exponierten Container-Layern und jetzt bei einem öffentlichen npm-Paket, das seinen eigenen Quellbaum als JSON mitführte. Die Fehlerarten ändern sich. Die Vertrauensgrenze nicht. Was auch immer Sie ausliefern, wird zu dem, was die Leute inspizieren, spiegeln, vergleichen, installieren und angreifen.
So verhindern Sie, dass dies geschieht
Das zu vermeiden ist nicht glamourös. Es ist grundlegende Release-Disziplin, und genau deshalb funktioniert es.
1. Veröffentlichen Sie keine Source Maps mit eingebettetem Quellcode
Wenn Sie ein Closed-Source-npm-Paket ausliefern, sollten öffentliche Source Maps deaktiviert sein, es sei denn, Sie sind damit einverstanden, den darin enthaltenen Code zu veröffentlichen. Private Fehlersuche ist in Ordnung. Öffentliche sourcesContent sind ein Release-Ereignis.
Für Frontend- und CLI-Builds bedeutet das normalerweise:
- Deaktivieren Sie öffentliche Source Maps für das Paket
- Generieren Sie versteckte Maps und laden Sie sie in private Fehler-Tracking-Systeme hoch
- Verwenden Sie No-Sources-Maps, wenn Sie Symbole benötigen, ohne Code auszuliefern
- Überprüfen Sie die Standardeinstellungen des Bundlers, wann immer Sie die Build-Toolchain ändern
2. Machen Sie npm pack zu einem harten Release-Gate
Vertrauen Sie nicht dem dist/-Ordner. Überprüfen Sie den Tarball, den Sie veröffentlichen wollen.
Jede Release-Pipeline sollte das Paket erstellen, npm pack ausführen, den Tarball entpacken und fehlschlagen, wenn die Inhalte von der Richtlinie abweichen. Schlagen Sie das Release mindestens dann fehl, wenn:
- eine
.map-Datei sourcesContent enthält
- ein Paket Dateien außerhalb einer Whitelist enthält
- der Tarball interne Dokumente, Prompts, Fixtures oder Konfigurationen enthält, die nicht in das Paket gehören
- sich das Manifest ohne ausdrückliche Überprüfung ändert
Ein einfaches Gate ist besser, als das Problem auf X zu entdecken:
npm pack
tar -xzf *.tgz
node -e 'const fs=require("fs"); const map=JSON.parse(fs.readFileSync("package/cli.js.map","utf8")); if (Array.isArray(map.sourcesContent) && map.sourcesContent.some(Boolean)) { console.error("Refusing to publish embedded source maps"); process.exit(1); }'
3. Veröffentlichen Sie aus einem sauberen, erlaubten Verzeichnis
Viele Lecks passieren, weil Teams aus dem Stammverzeichnis eines Monorepos oder aus einem dist/-Verzeichnis veröffentlichen, das sich mit der Zeit angesammelt hat. Bauen Sie in ein sauberes Release-Verzeichnis. Kopieren Sie nur das hinein, was zum Paket gehört. Verwenden Sie das Feld files in package.json als Whitelist. Behandeln Sie .npmignore als Sicherheitsnetz, nicht als Plan.
4. Behandeln Sie operative KI-Assets als veröffentlichungssensibel
KI-Teams schützen normalerweise Gewichte, API-Schlüssel und Kundendaten. Sie werden viel lockerer mit Prompts, Routing-Logik, Fallback-Verhalten, Telemetrie-Schaltern, internen Feature-Flags und Tool-Berechtigungen. Das ist ein Fehler.
Auch wenn diese Assets rechtlich nicht geheim sind, tragen sie dennoch Produktwert und Angriffswert. Wenn ein Release-Artefakt sie enthält, gehen Sie davon aus, dass sie gelesen werden.
5. Überprüfen Sie, was das Registry nach der Veröffentlichung liefert
Selbst gute CI-Pipelines übersehen Dinge. Ziehen Sie die exakte Version, die Sie gerade veröffentlicht haben, aus dem Registry oder einem Spiegel, überprüfen Sie sie erneut und alarmieren Sie bei Abweichungen. Wenn etwas durchrutscht, zählen Minuten.
Halten Sie Debug-Artefakte standardmäßig privat. Source Maps gehören weitaus häufiger in private Observability-Workflows als in öffentliche Paket-Registries.
Unsere Voreingenommenheit bei Kolsetu
Wir bauen für regulierte Branchen, daher können wir nicht so tun, als würde das Release-Engineering außerhalb des Sicherheitsmodells stehen. Ein Paket, ein Container oder ein Browser-Bundle kann innerhalb von Minuten heruntergeladen, gespiegelt, indiziert und durchsucht werden. Diese Annahme ändert, wie Sie Software veröffentlichen.
Unsere Standardhaltung ist einfach:
- Überprüfen Sie das endgültige Artefakt, nicht nur den Ordner, der es erzeugt hat
- Halten Sie Debug-Assets privat
- Liefern Sie aus einem erlaubten Release-Verzeichnis
- Gehen Sie davon aus, dass jedes öffentliche Artefakt sofort lesbar wird
Ich denke, viele KI-Teams unterschätzen immer noch die Release-Disziplin, weil Modelle unterhaltsamer zu diskutieren sind, obwohl die Verpackung der Ort ist, an dem viel vermeidbarer Schaden entsteht.
Abschließender Gedanke
Was hier passiert ist, ist für Anthropic peinlich. Es ist auch für den Rest der Branche nützlich. Ein öffentliches npm-Paket ist ein Offenlegungskanal, und eine Source Map mit sourcesContent ist Quellcode. Teams, die KI-Produkte entwickeln, verbringen endlose Zeit mit Modellen, Prompts, Evals und Tools und eilen dann die letzte Meile der Verpackung. Diese letzte Meile entscheidet, was die Welt tatsächlich lesen kann.
Die nächste Runde von KI-Sicherheitsfehlern wird nicht nur aus dem Modellverhalten resultieren. Einige werden aus CI, Registries, Containern, Browser-Bundles, GitHub Actions und Build-Ausgaben stammen, die niemand genau genug überprüft hat. Das Modell bekommt die Schlagzeilen. Das Artefakt entscheidet, was die Welt sehen kann.
Referenzen
Virendra Singh Bhalothia
