On an ordinary Tuesday, a maintainer account for the @antv ecosystem—a collection of popular data visualization libraries—began publishing trojanized versions of packages your team might already be using. By the time the attack was detected, TeamPCP (operating under the campaign name Mini Shai-Hulud) had pushed 639 malicious versions across 323 unique packages. Each contained a credential-stealing payload designed to harvest AWS keys, Google Cloud credentials, GitHub tokens, and 17 other credential types from developer workstations.
This wasn't a zero-day exploit or a sophisticated infrastructure breach. It was a compromised maintainer account—the kind of access control failure that ISO/IEC 27001:2022's A.5.15 (identity management) and PCI DSS v4.0.1's Requirement 8.3 (multi-factor authentication for all access to system components) are designed to prevent.
Timeline
Initial compromise: The attacker gained access to a legitimate maintainer account for the @antv organization. The exact compromise method remains undisclosed, but the account had sufficient permissions to publish new package versions to npm.
Publication phase: Over an undisclosed period, the attacker published 639 malicious versions across 323 packages in the @antv ecosystem. Each version contained identical stealer payloads disguised within otherwise legitimate code.
Attestation signing: The attacker used Sigstore's attestation pipeline to sign the malicious artifacts with legitimate certificates, making the packages appear trustworthy to automated verification tools.
Detection: The campaign was identified after security researchers noticed unusual publishing patterns and analyzed the package contents. By this point, an unknown number of organizations had already installed the compromised versions.
Which Controls Failed or Were Missing
Access control and authentication: The compromised maintainer account represents a failure of identity verification and privileged access management. The account had broad publishing rights without compensating controls like approval workflows or anomaly detection.
Publishing controls: The npm ecosystem allowed a single compromised account to publish hundreds of versions across hundreds of packages without rate limiting, behavioral analysis, or human review triggers. This violates the principle of least privilege that NIST 800-53 Rev 5's AC-6 mandates for all privileged operations.
Supply chain verification: Organizations consuming these packages lacked the detection mechanisms to identify malicious code before integration. The Sigstore attestation—meant to provide assurance—was weaponized by the attacker to create false legitimacy.
Credential management on developer workstations: The stealer payload succeeded because developers had credentials stored in accessible locations (environment variables, configuration files, shell history). This violates PCI DSS v4.0.1 Requirement 8.3.2, which requires protection of authentication credentials during storage.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 8.3.1: Multi-factor authentication for all access to the cardholder data environment. While npm isn't explicitly CDE, the principle applies: any account with publishing rights to packages used in production systems should require MFA. The compromised maintainer account likely lacked this control.
PCI DSS v4.0.1 Requirement 6.3.2: Your organization must maintain an inventory of bespoke and custom software, and third-party software components. You cannot protect dependencies you don't track. This requirement mandates you know which @antv packages you're using and monitor them for changes.
NIST 800-53 Rev 5 SR-3 (Supply Chain Controls and Processes): Organizations must employ integrity verification mechanisms to detect unauthorized changes to software and firmware. The Sigstore attestation check isn't sufficient—you need additional behavioral analysis and code review for critical dependencies.
ISO/IEC 27001:2022 A.5.19 (Information Security in Supplier Relationships): You must establish and maintain security requirements for services and products from suppliers. This includes defining acceptable security practices for package maintainers and monitoring compliance.
OWASP ASVS v4.0.3 Section 14.2 (Dependency): Applications must use a software bill of materials (SBOM) to track components, and security-relevant updates must be applied in a timely manner. You need automated tooling to detect when a known-good package version is replaced by an unknown version.
Lessons and Action Items for Your Team
Implement npm package pinning immediately: Stop using version ranges (^1.2.3 or ~1.2.3) in your package.json. Pin exact versions and use lock files (package-lock.json or yarn.lock) committed to version control. This prevents automatic updates to compromised versions.
Deploy automated dependency scanning: Tools like Socket, Snyk, or GitHub's Dependabot can detect anomalous package behavior—unusual network connections, filesystem access, or obfuscated code. Configure these tools to block installation of packages that exhibit credential-harvesting patterns. The 20+ credential types this payload targeted would trigger multiple behavioral rules.
Require MFA for all publishing accounts: If you maintain any public packages, enable MFA on your npm account today. If you consume packages from vendors, add MFA requirements to your vendor security questionnaires. Document this in your supplier security policy per ISO/IEC 27001:2022 A.5.19.
Audit developer workstation credential storage: The stealer harvested credentials from environment variables, shell history, and configuration files. Implement a secrets management solution (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) and prohibit storing credentials in code or config files. Run a one-time scan using tools like truffleHog or GitGuardian to identify existing exposures.
Create a dependency approval workflow: For packages with elevated privileges (build tools, CLI utilities, anything that runs in CI/CD), require security review before initial adoption and when major versions change. Document approved packages in your asset inventory per PCI DSS v4.0.1 Requirement 6.3.2.
Monitor package update patterns: Set up alerts for unusual publishing activity on your critical dependencies. If a package that typically updates quarterly suddenly publishes 50 versions in a week, that's a red flag requiring investigation before you accept any updates.
Test your incident response: Run a tabletop exercise where you discover a compromised dependency in production. Who rotates the potentially exposed credentials? How do you identify which systems pulled the malicious version? How quickly can you roll back? Document the answers and assign owners.
The @antv compromise succeeded because multiple controls failed simultaneously: weak authentication on the maintainer account, insufficient publishing restrictions, and inadequate detection mechanisms in consuming organizations. Your job is to ensure that when a similar attack targets your dependencies, at least one of your controls catches it before credentials leave your network.
