Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure
Back to Blog

AntV npm compromise: what the package evidence shows

Socket and SafeDep documented hundreds of malicious AntV-related npm releases. Compare exact versions, understand the two execution paths, and scope credentials exposed on affected hosts.

Editorial record: earlier Argus detection counts and timing were removed because the underlying event tally could not be reproduced. Incident scope and payload details are attributed to Socket and SafeDep.

Ben Kim
Written by
Ben Kim
Published
Updated
11 min read708 words
Share:
AntV npm compromise: what the package evidence shows

What happened on May 19

A compromised npm publishing account associated with the AntV ecosystem released malicious package versions on May 19, 2026. Socket counted 639 versions across 323 packages; SafeDep counted 637 versions across 317 packages in its incident snapshot. Those are separate investigators’ tallies, not measurements from Cremit. Check the package and version list in the source you use before treating either count as a final universal total.

The compromised account had publishing rights for many established packages. The lesson is practical: a familiar maintainer name and a mature package do not make a new release safe. The malicious versions had to be identified by the release contents and independent advisories, rather than by account reputation alone.

How the malicious update reached a host

SafeDep found a preinstall hook that ran an obfuscated Bun script. It also found a GitHub-hosted optional dependency in 630 of the 637 versions it analyzed. The second route matters because disabling install scripts alone does not cover every way a dependency can cause execution. The exact package manifest and lockfile are better evidence than a campaign label.

The payload searched the host for credentials, including npm and GitHub tokens, cloud credentials, SSH keys and other local secrets. SafeDep documents the credential targets and an exfiltration endpoint at t.m-kosche.com. Finding an affected version in a lockfile establishes exposure to a malicious dependency; it does not by itself prove the payload ran or that a particular token left the host.

What the detection signals can and cannot prove

An OSV malicious-package advisory is strong evidence about a listed package version. A new publisher, a sudden burst of releases or a large tarball change is a reason to investigate, but each has legitimate explanations. We would review the version-specific advisory, manifest diff, publish time and execution path together before calling a release malicious.

The Argus incident monitor has an advisory-based decision route: when a package event has an OSV MAL flag and its heuristic score reaches the configured threshold, the decision can bypass a contrary small-model label. That code path describes a classification rule. It does not prove when the advisory became available, how many May 19 events were processed, or how quickly they were published to the feed.

An earlier version of this article said Argus published 324 catches and 11 campaign alerts within 30 minutes. We could not reproduce that tally from the available May 19 event records, so we removed the speed and coverage claim. The same applies to an asserted count of publisher-handle takeovers: a publisher-field change is a clue, not proof that each account was separately compromised.

A check an operator can perform

  • Compare the exact package and version in the lockfile with the affected-version lists in Socket and SafeDep. Do not flag an entire package history when only specific releases are listed.
  • If an affected release was installed or built, identify the developer or CI hosts that processed it. Check install logs and network telemetry for execution and egress; absence of a log is not proof that execution did not occur.
  • Scope credentials that were reachable from those hosts. Revoke and reissue exposed tokens through their issuers, beginning with publish credentials and high-privilege cloud or source-control access. A developer who merely declared a dependency does not automatically need every npm token rotated.
  • Pin to a confirmed clean version, review the manifest and lockfile change, and prevent the affected versions from re-entering the build. Keep the original logs and package metadata for incident review.

Where Cremit Platform fits

Argus monitors public package events. Cremit Platform is a separate product for investigating credentials found in connected sources: it records the source, can check validity for supported types, examines AWS and GCP key access where supported, and helps assign an owner and track response. It does not certify that a package is safe or automatically rotate every credential on a host.

Sources and editorial record

Socket: AntV packages compromised — incident scope and affected packages.

SafeDep: Mini Shai-Hulud strikes again — package list, manifest changes and payload analysis.

OSV advisory example: MAL-2026-3982 — one version-specific malicious-package record.

Originally published May 19, 2026. Substantially revised October 5, 2026 to distinguish external incident findings from internal detection claims whose underlying tally was not available for verification.

Share it with your networkLinkedInX

Read next

Get the next one in your inbox

Monthly NHI security brief from Cremit. One email, high signal.

We never sell your email. Unsubscribe anytime.

AntV npm compromise: affected versions and response | Cremit