We Scanned the Claude Code Leak Repo. Here’s What We Found.

When the Claude Code source leak mirror started circulating, we wanted to answer a practical question:

If you treat this as a real engineering artifact and run a dependency vulnerability workflow on it, what do you actually find?

We used the public repository:

• yasasbanukaofficial/claude-code

The setup challenge: no package manifests in the leaked source

Because this mirror is reconstructed from published sourcemaps, the original package metadata was incomplete for normal dependency scanning:

• no original package.json/package-lock.json pair to trust as canonical build input

So we did a best-effort reconstruction:

1. Parsed import / require specifiers across src/**
2. Built an inferred package.json from detected third-party packages
3. Generated a lockfile (npm install --package-lock-only)
4. Ran Verimu in offline mode

The exact scan command

unset VERIMU_API_KEY
npx --yes /Users/chris/enterprise/verimu scan --path /Users/chris/playground/claude-code --skip-upload

Scan results (offline run)

• Projects discovered: 1
• Ecosystem: npm
• Dependencies analyzed: 844
• Total vulnerabilities: 2
• Critical: 0
• High: 0
• Medium: 0
• Low: 1
• Unknown: 1

What we found

1) CVE-2026-34451 (@anthropic-ai/sdk)

• Package range: @anthropic-ai/sdk@>=0.79.0, <0.81.0
• Fixed version: 0.81.0
• Description (OSV): memory tool path validation issue enabling sandbox escape to sibling directories
• Verimu evidence status: direct_evidence (20 code snippets)

Example snippet (from usage-context evidence):

import type { ContentBlockParam } from '@anthropic-ai/sdk/resources/messages.mjs'

This type of direct import evidence is useful because it confirms the vulnerable package family is not just present in the lockfile; it is referenced throughout source modules.

2) CVE-2025-54798 (tmp)

• Package range: tmp@>=0, <0.2.4
• Fixed version: 0.2.4
• Description (OSV): symlink-based arbitrary temporary file/directory write risk via dir parameter
• Verimu evidence status: indirect_no_evidence

For this one, Verimu did not find direct source usage snippets, but the lockfile chain is clear:

"node_modules/external-editor": {
  "dependencies": {
    "tmp": "^0.0.33"
  }
},
"node_modules/tmp": {
  "version": "0.0.33"
}

That means this is a transitive supply-chain exposure path, not a confirmed direct callsite in the analyzed source.

High-level risk assessment

Finding	Evidence quality	Potential impact	Priority
CVE-2026-34451 in @anthropic-ai/sdk	Direct source evidence + vulnerable range match	Higher-concern class (sandbox boundary implications)	P1 / Highest in this run
CVE-2025-54798 in tmp	Lockfile/transitive evidence only	Context-dependent local temp-path abuse scenarios	P2 / Important, but secondary

Important nuance: the scanner reported no critical severity CVEs in this run.
But for triage, the most material finding is still CVE-2026-34451 because of impact class and direct package usage evidence.

What this does and does not prove

This workflow proves:

• the repo can be converted into a scanable dependency graph with reconstruction
• known CVEs can be identified and prioritized with code-context evidence

It does not prove:

• exploitability in a specific runtime deployment
• that reconstructed manifests exactly match Anthropic’s original internal release graph

Why this matters

Most teams do not fail security because they never run a scanner. They fail because they treat scan output as either absolute truth or useless noise.

The right path is in the middle:

1. Build the best dependency graph you can
2. Run repeatable scans
3. Separate direct evidence from transitive exposure
4. Prioritize by impact class, not just label color

That is exactly what we did here.

---

Get started free → or book a demo if you want this same SBOM + CVE + code-evidence workflow on your own repositories.