Axios, Supply Chains, and a Claude Leak

If you still think npm install is a harmless ritual, this week was a reality check. What looks like dependency management is, in practice, executing third-party code with full trust inside your environment.

Two incidents collided almost perfectly: a compromised release of the widely used Axios package, and an accidental source leak involving Claude Code. Different root causes — same lesson.

1. When a Trusted Package Turns Hostile

Axios is one of the most widely used HTTP clients in the JavaScript ecosystem. That’s exactly what made it such a valuable target.

Attackers gained access to a maintainer account and published malicious versions that appeared legitimate. These versions included hidden behavior that executed during installation — before your app even started.

npm install axios

That single command was enough. No imports, no execution paths, no runtime triggers. Just installing dependencies triggered the payload.

• Malicious versions were live briefly
• CI pipelines executed them automatically
• Payloads cleaned up after themselves

This is the purest form of a supply chain attack: compromise a trusted node, and every downstream system inherits the risk.

2. The Real Problem: Humans in the Loop

Traditional advice focuses on avoiding suspicious packages. But this attack didn’t rely on deception — it relied on trust.

The question is no longer “Is this library safe?”
It’s “Is everyone who can publish to it safe?”

Maintainer accounts are now critical infrastructure. A single compromised credential can ripple across thousands of applications.

3. Meanwhile: The Claude Code Leak

As if that wasn’t enough, another issue surfaced: an apparent leak of internal artifacts via an npm package.

Repository: github.com/nirholas/claude-code

The likely cause? A packaging mistake — unintended files included in a published artifact. Think source maps, internal modules, or entire directories that were never meant to leave the development environment.

It’s the classic failure mode:

• Build pipeline includes too much
• No strict allowlist for published files
• No verification of final package contents

The result is less dramatic than malware, but just as dangerous in the long run: intellectual property exposure and potential security insights for attackers.

4. Why This Keeps Happening

The JavaScript ecosystem optimizes for speed and convenience:

• Deep dependency trees
• Automated installs in CI/CD
• Implicit trust in maintainers
• Minimal verification at install time

In other words, we’ve built a system where executing untrusted code is the default.

5. Practical Defenses

Lock Down Dependencies

• Commit and enforce lockfiles
• Avoid automatic dependency upgrades in CI
• Use deterministic builds

Harden CI/CD

• Run installs in sandboxed environments
• Limit network access during builds
• Use ephemeral credentials

Verify What You Ship

• Audit package contents before publishing
• Use files allowlists in package.json
• Scan for secrets and internal artifacts

Reduce Trust Radius

• Vendor critical dependencies when possible
• Prefer fewer, well-audited libraries
• Monitor dependency changes actively

6. A New Mental Model

It’s time to stop thinking of dependencies as static libraries and start treating them as dynamic, potentially hostile inputs.

import something from "the-internet"

That line has always been powerful. Now it’s also a liability.