Fake AI SDK npm Packages Impersonate Anthropic Claude

On July 17, 2026, supply chain security scanners flagged a fresh batch of malicious npm packages built to look like AI and blockchain developer SDKs. The names are the tell. anthropic-claude-latest, ai-pro-sdk, chain-sdk-js, and theta-sdk-js all impersonate the kind of tooling developers reach for when they wire an application to a large language model or a crypto network. Each was published to the public npm registry, marked as malware, and pulled into our catalog as critical the same day. This is not a single break-in at one maintainer account. It is the latest run in a months-long wave of impersonation packages aimed at people building AI and Web3 software.

What happened

On 2026-07-17, four npm packages that pose as AI and crypto SDKs were flagged as malicious: anthropic-claude-latest, ai-pro-sdk, chain-sdk-js, and theta-sdk-js. None of them provide a working SDK. They exist to run attacker code on a developer machine or in a CI job the moment the package is installed or imported.

The naming is deliberate. anthropic-claude-latest borrows the vendor name (Anthropic) and product name (Claude) plus the word "latest" so it reads like an official release channel. ai-pro-sdk and chain-sdk-js use generic, plausible SDK names that an AI or blockchain developer might type from memory or paste from a hallucinated code suggestion. theta-sdk-js leans on the Theta blockchain brand. These are the same tricks we saw earlier this month with the claude-token-tracker-mcp package on 2026-07-16 and the peer-to-peer impostor ai-p2p flagged in the same window.

Exact install counts and payload hashes for the newest packages were still being published as of July 17. What is confirmed is the pattern. npm has absorbed a sustained run of malicious package uploads through 2026, and Palo Alto Networks Unit 42 has been tracking the volume in a report it updates as new families appear. The AI and SDK impostors are one slice of that traffic, and they keep coming because the target list keeps growing.

Timeline

This wave did not start today. It has been building for weeks.

• 2026-07-08: A cluster of malicious npm packages impersonating AI and Model Context Protocol (MCP) tooling was documented. See Malicious npm Packages Impersonate AI and MCP Tooling.
• 2026-07-16: claude-token-tracker-mcp and ai-p2p were flagged, both leaning on AI branding.
• 2026-07-17: anthropic-claude-latest, ai-pro-sdk, chain-sdk-js, and theta-sdk-js were added as critical.

Treat these dates as detection dates, not necessarily publish dates. Malicious packages are often live on npm for hours or days before a scanner catches them, so a package flagged today may have already been installed by someone yesterday.

Who is affected

The target is developers, not end users. Anyone building against an AI provider, an MCP server, or a blockchain SDK is in scope, because that is exactly the audience these package names are written to catch.

Two mechanics put teams at risk. The first is typosquatting and brand confusion, where a name like anthropic-claude-latest looks close enough to an official package that a tired engineer installs it without checking. The second is slopsquatting, where an AI coding assistant hallucinates a package name that does not exist, an attacker registers that name, and the next developer who follows the same suggestion pulls the malicious version. Both routes end at the same place: npm install on a developer laptop or a CI runner.

CI runners are the worse case. A build agent usually holds npm publish tokens, cloud credentials, and registry secrets in environment variables. Researchers at GBHackers and Cyber Press have documented fake SDK "facades" on npm and PyPI that mimic real payment libraries and quietly harvest CI/CD secrets, which is the same objective these AI and crypto impostors are set up to serve. Once secrets leave a runner, the attacker can push their own package versions and turn one compromised install into a downstream supply chain problem.

How the attack works

Malicious npm packages in this family usually run in one of two spots, and sometimes both.

The first is install time. A postinstall or preinstall script fires automatically when the package is added, with no import and no application code needed. That is why npm's move to block install scripts by default in v12 matters, covered in npm v12 Blocks Install Scripts to Curb Supply Chain Attacks. Until that default reaches your toolchain, an install script is free code execution.

The second is import time. The payload sits in the module body and runs the first time your code calls require() or import. Microsoft's analysis of the recent AsyncAPI compromise described exactly this import-time delivery, where a package looks inert on disk but executes on first use. An impostor SDK is a natural fit for that technique, because a developer who installs a fake "SDK" is very likely to import it right away to test it.

Once running, the goal is collection and exfiltration. The typical shopping list is environment variables, npm and cloud tokens, SSH keys, .npmrc contents, and anything that looks like a secret, sent to an attacker endpoint over HTTP or DNS. The exact indicators for the July 17 packages were still being catalogued at publication time, so verify against the specific advisory for each name before you assume behavior.

How to check if you are affected

Start with your lockfiles, because they record what actually resolved, not just what you asked for.

# Search every lockfile in the repo for the flagged names
grep -RniE "anthropic-claude-latest|ai-pro-sdk|chain-sdk-js|theta-sdk-js|claude-token-tracker-mcp|ai-p2p" \
  package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

Then confirm whether any are installed in the current tree and why they are there:

npm ls anthropic-claude-latest ai-pro-sdk chain-sdk-js theta-sdk-js 2>/dev/null
npm why chain-sdk-js

If you run builds in CI, grep the build logs and cached workspaces on your runners too, not just developer machines. A package that ran once on a shared runner has already had access to that runner's secrets.

Remediation

If none of the names appear, you are clear on this batch. Keep the grep command in your review checklist for the next wave. If any name does appear, act as if secrets were exposed.

Remove the package and reinstall without running scripts:

npm uninstall anthropic-claude-latest ai-pro-sdk chain-sdk-js theta-sdk-js
npm ci --ignore-scripts

Rotate anything the process could have reached. On a developer box that means local tokens and SSH keys. On a CI runner it means npm publish tokens, cloud provider keys, and registry credentials.

# Revoke npm tokens and issue new ones
npm token list
npm token revoke <token-id>

For ongoing defense, pin exact versions, require lockfiles in review, and set ignore-scripts=true in a project .npmrc for teams that do not need install hooks. Confirm the real package name from vendor documentation before adding any SDK. Anthropic, for example, ships its official TypeScript client as @anthropic-ai/sdk, so a bare anthropic-claude-latest in your dependency list is a red flag on its own.

FAQ

Is anthropic-claude-latest a real Anthropic package?

No. Anthropic publishes its official SDKs under scoped, documented names such as @anthropic-ai/sdk. There is no official package called anthropic-claude-latest, and the one on npm was flagged as malware on 2026-07-17. If you need the Claude client, install it from Anthropic's own documentation rather than searching npm for a name that includes "latest."

How do I know if I am affected by these fake AI SDK packages?

Grep your lockfiles for the exact names (anthropic-claude-latest, ai-pro-sdk, chain-sdk-js, theta-sdk-js). If nothing matches, you did not resolve them. If something matches, remove it, reinstall with --ignore-scripts, and rotate any secret that was present on the machine or CI runner where the install happened.

Are the packages still available on npm?

Packages confirmed as malware are usually taken down by npm quickly after they are reported, so the specific names may already be gone by the time you read this. That does not undo an install that already happened. Removal from the registry stops new victims, but it does not clean a machine that already ran the payload.

What should I do if one ran in CI?

Treat every secret on that runner as compromised. Revoke and reissue npm tokens, cloud keys, and registry credentials, then check whether any packages your team owns were published or modified after the install. That last step matters because stolen publish tokens are how a single fake SDK turns into a second-stage supply chain attack.