Notifications
Clear all
Topic starter
20/08/2026 5:50 pm
TL;DR: A two-armed npm campaign ships functional Claude Code clones, then hijacks developer API traffic through a proxy CA bundle and WebSocket relay or through ANTHROPIC_BASE_URL phishing, showing that malware can be usable by the victim and hostile to the operator at the same time, according to Xygeni. The identity lesson is that AI coding tools need governed secret handling, publisher trust, and runtime path controls, not just package scanning.
NHIMG editorial — based on content published by Xygeni: FauxCode and the hidden layer of functional Claude Code clones on npm
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a malicious AI coding tool is allowed to proxy developer API traffic?
A: The trust boundary breaks first.
Q: Why do AI tools create NHI governance risk?
A: AI tools create NHI governance risk because they often act with execution authority, data access, and delegated permissions that outlive a single user interaction.
Q: How do security teams know if a developer AI tool has been tampered with?
A: Look for behavioural changes, not just package names.
Practitioner guidance
- Enforce endpoint controls on developer AI tooling Monitor package-installed binaries for unexpected certificate writes, especially creation of ~/.ccr/ca-bundle.crt, and alert on outbound WebSocket relays from node_modules processes.
- Lock down identity-relevant environment variables Watch for unauthorised changes to ANTHROPIC_BASE_URL in ~/.bashrc, ~/.zshrc, and tool settings files, and restrict which approved proxies may be used.
- Review AI coding tools as NHI-like delegates Inventory command-line AI assistants, the secrets they can read, and the APIs they can reach, then assign ownership and review cadence.
What's in the full report
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact package and version indicators for the Claude Code clone cluster, including author identity clues and module names.
- Filesystem and network indicators tied to the CA-bundle MITM path, including where the relay is staged and how it persists.
- The heibai phishing flow, including the local credential cache and shell-profile persistence changes.
- Detection guidance and triage heuristics for defenders who need to hunt similar npm packages across developer fleets.
👉 Read Xygeni's analysis of the FauxCode npm campaign and Claude Code clones →
Working Claude Code clones on npm: what it means for IAM teams?
Explore further
20/08/2026 6:29 pm
Working malicious clones create a governance blind spot that package scanning alone will miss. The package still does what the developer expects, so installation-time signals are weak and user suspicion is low. That is a different class of supply-chain risk from broken typosquats or fake websites. Practitioners should treat runtime behaviour in developer tooling as part of the trust model, not an afterthought.
A question worth separating out:
Q: Who is accountable when an AI assistant rewrites its own traffic path?
A: Accountability usually sits with the teams that own developer endpoint security, identity governance, and software supply-chain controls. If the tool can redirect credentialed traffic, then appsec alone is not enough. The organisation needs clear ownership for AI tooling provenance, secret handling, and runtime network enforcement.
👉 Read our full editorial: FauxCode shows how working npm clones can hijack AI tool traffic
