Between June 29 and July 3, 2026, a threat actor published seven malicious npm packages targeting developers using Vite, a popular frontend build tool. Checkmarx discovered the campaign, dubbed ViteVenom, and traced it to an actor called SuccessKey. The packages delivered a remote access trojan through a four-tier command-and-control infrastructure built on Tron, Aptos, and Binance Smart Chain blockchains.
This wasn't a typical typosquatting attack. The attacker embedded malicious code that retrieved instructions from blockchain smart contracts, making takedown efforts significantly harder than traditional C2 servers.
Timeline
June 29-July 3, 2026: SuccessKey published seven npm packages with names designed to look legitimate to Vite users. The packages contained obfuscated code that established connections to blockchain-based C2 infrastructure.
Discovery: Checkmarx identified the malicious packages during routine supply chain monitoring. By the time of discovery, the packages had already been downloaded by developers who installed them as dependencies.
Post-Discovery: Unlike typical incidents where security teams can request DNS takedowns or server seizures, the blockchain-based C2 infrastructure remained operational even after npm removed the packages. The attacker's commands lived on immutable ledgers across three separate blockchain networks.
Which Controls Failed
Dependency verification: Your team likely runs npm install dozens of times per day. ViteVenom exploited the trust gap between package publication and security review. No automated checks verified package authenticity before installation.
Runtime monitoring: The malicious code executed during the build process. Most organizations monitor production environments but treat build pipelines as trusted space. You probably don't have EDR agents on your CI runners.
Network egress controls: The packages made HTTPS connections to blockchain RPC endpoints. These looked like legitimate API calls in network logs. Your firewall rules likely allow outbound 443 to any destination.
Software Bill of Materials (SBOM): Without automated SBOM generation, you can't answer "which projects used these packages?" after discovery. Manual audits take days. The attacker counted on that delay.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that you maintain an inventory of bespoke and custom software, and third-party software components. This includes package dependencies. You need automated tooling that generates and updates your SBOM with every build.
Requirement 6.4.3 requires that public-facing web applications are protected from attacks through application security testing. While this specifically addresses web apps, the principle extends to your build pipeline. If your CI environment can execute arbitrary code from npm, you're running untrusted code in a privileged context.
NIST 800-53 Rev 5 Control SA-10 (Developer Configuration Management) requires that you track security flaws and flaw resolution within system, system component, and service development. This means logging what dependencies you use, when you added them, and what they do. Most teams fail this control because they treat package.json as configuration, not as security-relevant inventory.
ISO/IEC 27001:2022 Annex A.8.30 (Outsourced Development) requires that you supervise and monitor outsourced system development. Every npm package is outsourced development. You need controls that verify package contents match expected behavior before they run in your environment.
Lessons and Action Items
Implement package signature verification: npm supports package signatures through Sigstore. Configure your package manager to reject unsigned packages or packages from unverified publishers. Add this to your .npmrc:
audit=true
audit-level=moderate
This won't catch everything, but it raises the bar.
Lock your dependencies with hash verification: Don't just pin versions in package.json. Use package-lock.json or npm-shrinkwrap.json and commit them to version control. These files include SHA-512 hashes. If someone compromises a package version you've already vetted, the hash mismatch will block installation.
Isolate your build environment: Run builds in ephemeral containers with restricted network access. Your CI runners shouldn't have full internet egress. Whitelist specific registry endpoints. Block everything else. If a malicious package tries to phone home to a blockchain RPC endpoint, the connection fails.
Generate SBOMs automatically: Add SBOM generation to your build pipeline. Tools like CycloneDX or SPDX can parse your lockfiles and produce machine-readable inventories. When Checkmarx publishes indicators of compromise, you can grep your SBOMs and know within minutes whether you're affected.
Monitor build process behavior: Install runtime security tools on your CI infrastructure. Falco, for example, can detect when a build process makes unexpected network connections or spawns suspicious child processes. You'll catch malicious packages even if they pass static analysis.
Audit new dependencies before merge: Require security review for any PR that adds or updates dependencies. This doesn't scale if you're updating fifty packages a week, so prioritize new packages and major version bumps. Minor patches usually don't introduce RATs.
The blockchain C2 problem: You can't take down a smart contract the way you'd seize a C2 server. This changes your response playbook. Focus on detection and containment rather than infrastructure disruption. If you find a blockchain-based C2 in your environment, assume the attacker can maintain access until you rebuild affected systems from clean images.
The ViteVenom campaign shows that supply chain attacks are moving beyond simple typosquatting. Attackers now use decentralized infrastructure that survives traditional takedown procedures. Your controls need to assume that malicious packages will reach your systems and focus on detecting them before they execute.
Start with dependency locking and SBOM generation. You can implement both this week without changing your development workflow. Then work on build isolation and runtime monitoring. Those take longer but close the gaps that ViteVenom exploited.
