Supply Chain Security Mar 31, 2026

Claude Code Source Leak: What It Teaches Us About Build Pipeline Security

A forgotten source map in an npm package exposed Anthropic's entire Claude Code codebase. It's a common mistake with an easy fix, and a good reminder to audit your own build pipeline.

What Happened

On March 31, 2026, security researcher Chaofan Shou publicly documented that Anthropic had accidentally shipped a source map file (.map) inside the npm package for Claude Code, their agentic CLI tool for software engineering.

Source maps are JSON files that map bundled or minified JavaScript back to its original source code. They're useful for debugging but typically contain the full, unobfuscated source embedded as strings. In this case, the source map referenced TypeScript files hosted in Anthropic's R2 storage bucket, making the complete src/ directory publicly downloadable.

The result: roughly 1,900 TypeScript files and 512,000 lines of code for Claude Code were exposed to anyone who installed or inspected the npm package.

To be clear, this wasn't a hack or a breach. It was a build configuration mistake. Claude Code is built with Bun, which generates source maps by default. The .map file wasn't excluded from the npm package, and the referenced source files were accessible in cloud storage. Anthropic pushed an update to remove the source maps and pulled earlier versions from the npm registry, but by then the source had been archived to multiple public GitHub repositories.

What Was Exposed

The leaked source revealed the full internal architecture of Claude Code. Some highlights that made the rounds on Hacker News and developer communities:

  • The complete tool system (~40 tools), each with its own permission model for file access, shell execution, and web requests
  • A 46,000-line query engine module handling all LLM API calls, streaming, and caching
  • ~50 slash commands and ~140 React/Ink terminal UI components
  • The permission system, including an ML-powered auto-approval classifier and multiple permission modes
  • Unreleased internal features gated behind compile-time flags, including a persistent assistant mode, multi-agent orchestration, and a memory consolidation system
  • Internal project codenames and feature flags

What was not exposed: Claude model weights, API keys, user data, or credentials. The security impact is primarily about intellectual property and competitive intelligence rather than direct user harm.

Why This Matters Beyond Anthropic

This incident is worth writing about not to point fingers at Anthropic, but because the root cause is something that affects every team shipping JavaScript or TypeScript packages. Source map leaks are one of the most common and most overlooked ways that proprietary source code ends up public.

Source Maps Are Dangerous Defaults

Most modern bundlers (Webpack, esbuild, Vite, Bun) generate source maps by default or make it very easy to enable them. That's fine for development. The problem is when those source maps follow the built artefacts into production, whether that's a deployed web application or a published npm package.

A source map for a bundled file typically contains:

  • The complete original source code of every file that was bundled
  • Original file paths (revealing directory structure and naming conventions)
  • Variable and function names before minification

If your bundled output is 1 file, the source map is your entire codebase in JSON format. That's a significant exposure if the product is proprietary.

npm Packages Are Publicly Readable

Everything in an npm package is downloadable by anyone. There's no access control on package contents. If a file ends up in the tarball, it's public. This is by design, and it means your .npmignore or package.json files field is a security boundary, not just a convenience.

The same applies to Docker images, PyPI packages, Maven artifacts, and any other public package registry. If you push it, assume someone will look inside.

How to Prevent Source Map Leaks

1. Disable Source Maps in Production Builds

Configure your bundler to skip source map generation for anything that ships to users or gets published. In most tools this is a single flag:

  • Webpack: set devtool: false in your production config
  • esbuild: omit --sourcemap from production build commands
  • Vite: set build.sourcemap: false
  • Bun: omit the --sourcemap flag, or use --sourcemap=none

If you need source maps for error tracking (Sentry, Datadog, etc.), generate them and upload them to your monitoring service, then delete them from the build output before packaging.

2. Audit What Goes Into Your Packages

Before every publish, run npm pack --dry-run and inspect the file list. Better yet, add it to your CI pipeline as an automated check. Flag any .map files, .env files, test fixtures with credentials, or anything else that shouldn't be public.

Use the files field in package.json as an allowlist (safer than .npmignore as a denylist, since you can't accidentally forget to exclude a new file type).

3. Scan Cloud Storage Buckets

In this case, the source map referenced files in an R2 storage bucket that was publicly accessible. Even without the source map, those files were downloadable if you knew the URL. Regular scans of your cloud storage for unintended public access are a basic hygiene step that catches these issues before someone else does.

4. Treat Build Pipelines as Attack Surface

Your CI/CD pipeline determines what ends up in production artefacts. Treat it with the same rigour as your application code:

  • Review build configurations in code review, not just application logic
  • Pin bundler and build tool versions to avoid surprise behaviour changes
  • Run automated checks that verify published artefacts don't contain sensitive content
  • Use separate build profiles for development and production, and make sure the right one runs in CI

5. Check Your Deployed Web Apps Too

Source maps in npm packages are one vector. The other common one is shipping .map files alongside your bundled JavaScript in production web applications. Anyone can open browser DevTools and see if source maps load. Worse, automated scanners specifically look for .js.map files appended to script URLs.

If your production web application serves source maps, you're handing the full source to anyone who visits your site.

A Broader Pattern

This isn't the first time build artefacts have exposed proprietary code, and it won't be the last. The ShinyHunters Salesforce breach we covered recently was another case of a configuration oversight leading to mass data exposure. The root cause is almost always the same: defaults that make sense for development end up in production because nobody explicitly turned them off.

The OWASP Top 10 2025 includes Security Misconfiguration (A02) as the second highest risk category. Source map leaks fit squarely in that bucket. They're not sophisticated attacks. They're configuration oversights that expose far more than anyone intended.

Anthropic responded quickly by removing the source maps and pulling affected package versions. But as with most accidental exposures, the window between publication and discovery was long enough for the source to be widely archived. Prevention is the only reliable defence here. Once it's public, it's public.

Scan Your External Attack Surface

Publicly accessible storage buckets, misconfigured services, and exposed panels are exactly the kind of issues that external vulnerability scanning catches. Luna's 11,000+ security templates check for publicly accessible cloud storage, exposed management interfaces, default credentials, and other common misconfigurations that leak sensitive information. As this incident shows, a layered security testing approach that includes external scanning is how you catch these issues before they end up on Hacker News. Set up a scan and find out what's exposed.

References