Cybersecurity researchers have uncovered a new software supply chain attack targeting developers who use the Vite frontend development ecosystem, identifying seven malicious npm packages designed to infect systems with advanced malware. The campaign, dubbed ViteVenom by security firm Checkmarx, represents an evolution of the previously identified ChainVeil operation and demonstrates how attackers are increasingly using blockchain technology to make their infrastructure more resilient.
According to Checkmarx, the latest campaign has been linked to a threat actor tracked as SuccessKey. Investigators found evidence indicating that the operation had been active since at least February 27, 2026, when cryptocurrency wallets associated with the campaign were first activated. The researchers also concluded that the infrastructure and techniques used in ViteVenom strongly overlapped with those observed in the earlier ChainVeil attacks.
Unlike the previous campaign, which relied on typo-squatted packages masquerading as tools related to Tailwind, Sass, object-relational mapping libraries, and rate-limiting utilities, ViteVenom specifically targets developers building applications with the Vite JavaScript frontend build tool. The attackers also adopted a different naming strategy by publishing scoped npm packages that closely resembled the legitimate @vitejs namespace, increasing the likelihood that developers would mistake the malicious packages for authentic ones.
The seven identified packages were uploaded to npm between June 29 and July 3, 2026. Collectively, they recorded hundreds of downloads before being identified, highlighting the continued risk posed by malicious packages within widely used open-source software repositories.
Blockchain Infrastructure Hides Malware Delivery
Researchers found that the campaign relies on a four-layer blockchain-based command-and-control architecture spanning Tron, Aptos, and Binance Smart Chain, making the malicious infrastructure significantly harder to disable than traditional servers. Instead of depending on conventional domain names or centralized servers that can be seized or blocked, the attackers embedded payload references within blockchain transactions.
The malware does not activate when the package is installed. Instead, execution occurs only when the compromised package is imported into a project, reducing the likelihood of detection by endpoint security products during installation.
Once triggered, the malicious loader queries the Tron blockchain for the attacker’s latest transaction, decodes the transaction data to retrieve a Binance Smart Chain transaction hash, and extracts an encrypted payload from that transaction. The payload is then decrypted using a hard-coded key before the malware proceeds to its next stage.
Researchers explained that storing payload references on public blockchains instead of conventional domains makes the infrastructure exceptionally difficult to disrupt because blockchain records cannot be easily removed. If communication through Tron fails, the malware automatically switches to the Aptos blockchain as a backup retrieval channel.
The retrieved payload subsequently obtains the command-and-control configuration and launches another loader responsible for deploying a remote access trojan. The malware is capable of establishing reverse shell access, harvesting credentials, stealing files, and creating persistent backdoors on compromised systems. Investigators also found that the malware includes an additional fallback mechanism that can retrieve the remote access trojan directly over HTTP, bypassing blockchain retrieval if necessary.
Security experts urged organizations and developers who installed any of the affected packages to remove them immediately, audit project dependencies, rotate all credentials, and inspect .bashrc, .zshrc, and .profile files for unauthorized modifications that could indicate persistence mechanisms.
Researchers further assessed that although the campaigns used different package names, maintainer accounts, cryptocurrency wallets, and malicious file locations, those differences appeared consistent with a single threat actor compartmentalizing multiple distribution channels to reduce operational exposure while maintaining a shared malware delivery infrastructure.