On 31 March 2026, Anthropic shipped version 2.1.88 of their Claude Code CLI to npm. Inside the package sat a 59.8 MB JavaScript source map file — a debugging artefact that mapped the minified production bundle back to the original TypeScript. That source map pointed to a publicly accessible zip archive on Anthropic’s Cloudflare R2 storage bucket. Within hours, the archive — roughly 1,900 TypeScript files and over 512,000 lines of code — had been downloaded, backed up, and forked more than 41,500 times on GitHub.

This was not a breach. No customer data was exposed. No credentials leaked. Anthropic called it “a release packaging issue caused by human error,” and that description is accurate. But the incident is worth examining closely, because it exposes a class of risk that most organisations building and shipping software at pace have not adequately addressed: what happens when your build pipeline becomes the vulnerability?

What source maps are and why they matter

Source maps (.map files) exist to make debugging easier. When you bundle and minify JavaScript or TypeScript for production, the output is deliberately unreadable — variable names are shortened, whitespace is stripped, modules are concatenated. A source map reconnects that compressed output to the original source, letting developers see meaningful stack traces and step through real code in browser dev tools.

The problem is that source maps contain — or point to — everything. Original file paths, function names, comments, business logic, internal architecture. If they ship to production, anyone who downloads them gets a near-complete view of the codebase. In Anthropic’s case, the map file didn’t just contain inline source; it referenced an external archive containing the full TypeScript project.

What the leak revealed

The exposed codebase included details that go well beyond “some code”:

• 44 feature flags for capabilities that were fully built but not yet shipped — effectively a product roadmap visible to competitors and researchers.
• Internal security mechanisms, including a native client attestation system that injects a cryptographic hash into API requests to prevent spoofed clients.
• Operational data embedded in code comments, including metrics on internal failure rates and bug references.
• 23 numbered bash security checks defending against specific injection vectors — useful defensive knowledge that simultaneously hands attackers a checklist of what to probe.

For any organisation, exposing feature flags and internal security architecture is a serious intelligence gift to adversaries. It’s not catastrophic in the way a database breach is, but it materially changes the attacker’s information advantage.

How it happened

The root cause appears straightforward: the npm package’s configuration (likely .npmignore or the files field in package.json) did not exclude the .map file from the published artefact. A single misconfiguration in the packaging step meant the source map — and by extension, the entire original codebase — shipped to a public registry.

This was the second time it had happened. A similar source map exposure affected an earlier Claude Code version roughly thirteen months prior. That recurrence is the part worth paying attention to. A one-off mistake is human. The same class of mistake recurring suggests a gap in the controls, not just the people.

The build pipeline as attack surface

Most security teams spend significant energy on runtime protection — WAFs, endpoint detection, network segmentation, access controls. Far fewer invest the same rigour in the build and release pipeline, which is where artefacts are constructed, signed, and shipped to users. That pipeline is a high-value target precisely because it operates with elevated trust: it has access to source code, secrets, signing keys, and publishing credentials.

The Anthropic incident wasn’t an attack on the pipeline. It was a packaging error. But the controls that would prevent this error are the same controls that defend against deliberate supply chain attacks. That’s what makes it a useful case study.

What you can do about it

These are practical controls that any team shipping software can adopt. None of them are exotic, but too many organisations treat them as optional.

1. Treat artefact contents as a security boundary

Every artefact you publish — npm package, Docker image, pip wheel, Maven JAR — should be treated as a potential data leak vector. The question is simple: does this artefact contain anything that shouldn’t be public?

• Explicitly declare what gets included in published packages. In npm, use the files allowlist in package.json rather than relying on .npmignore to exclude things. Allowlists fail safe; denylists don’t.
• Automate a post-build check that inspects the final artefact before publishing. A script that unpacks the tarball and checks for .map files, .env files, internal documentation, or unexpected file sizes catches mistakes before they reach the registry.

2. Strip source maps from production builds

Source maps should be generated in development and CI environments for debugging. They should not ship in production artefacts unless there is a specific, documented reason.

Most bundlers (Webpack, esbuild, Rollup, Vite) have configuration options to control source map generation per environment. Verify these settings are correct in your production build configuration, and write a CI check that fails the build if .map files appear in the output directory when building for release.

3. Scan published artefacts automatically

Add a pipeline stage after the artefact is built but before it is published that scans for sensitive content:

• Source maps and debug symbols
• Hardcoded credentials, API keys, and tokens
• Internal file paths or hostnames
• Unexpectedly large files (the 59.8 MB map file in a CLI package should have triggered a size anomaly)
• Feature flags or configuration that reveals unreleased capabilities

Tools like npm pack --dry-run, secretlint, trufflehog, or custom scripts can handle this. The key is that it runs as an automated gate, not a manual review.

4. Use pipeline policy-as-code

Define what a valid release artefact looks like, and enforce it automatically. Policy-as-code frameworks (Open Policy Agent, Conftest, or even a shell script with assertions) can verify:

• Only expected file types are present
• No files exceed a size threshold
• The package version matches the git tag
• Required signatures or attestations are present

When the policy fails, the pipeline stops. No human judgement required.

5. Sign and attest your artefacts

Signing doesn’t prevent a misconfigured build, but it does create an auditable chain of provenance. If you can prove which pipeline produced which artefact from which commit, you can investigate incidents faster and verify integrity after the fact.

npm supports package provenance via Sigstore. Docker has content trust and cosign. Use them.

6. Separate build and publish permissions

The credentials that build the artefact should not be the same credentials that publish it. Separation of duties limits the blast radius of a single compromised or misconfigured step:

• Build pipelines produce artefacts and store them in a staging area.
• A separate publish step — ideally requiring explicit approval or an automated policy gate — pushes the artefact to the public registry.
• Publishing credentials are short-lived and scoped to the publish step only.

7. Review your pipeline after every incident — including near-misses

Anthropic’s first source map exposure was, in hindsight, a near-miss that predicted the second. Treat pipeline incidents the way you’d treat a production security incident: run a post-mortem, identify the control gap, implement the fix, and verify it holds.

If your build toolchain changes — new bundler, new runtime, new CI platform — re-validate your artefact security assumptions. Toolchain migrations are where assumptions break.

The speed problem

There’s a broader point here that goes beyond any single incident. Organisations are shipping software faster than ever. AI-assisted development is accelerating that further. When the cycle time from code to production is measured in minutes, the window for a human to catch a packaging error is vanishingly small.

That’s not an argument against speed. It’s an argument for automated controls that operate at the same speed as the pipeline. Manual reviews don’t scale. Policy gates do.

The role of application security is shifting. It’s no longer enough to review code and run penetration tests. Security teams need to own the integrity of the build and release pipeline — designing automated checks, enforcing artefact policies, managing signing infrastructure, and treating the CI/CD system as critical infrastructure that deserves the same protection as production.

The takeaway

Anthropic’s source map leak was a genuine mistake, made by a capable team, building at pace. That’s exactly why it’s worth learning from. If it can happen to an organisation with the engineering talent and security awareness that Anthropic has, it can happen to anyone who hasn’t built the automated controls to prevent it.

The fix isn’t “be more careful.” The fix is: build the gates, automate the checks, and assume that humans under pressure will make the same mistake twice unless the pipeline won’t let them.

---

Sources: The Register, VentureBeat, The Hacker News, Alex Kim’s technical analysis