Published on gastropod.io - 07-21-2026

ViteVenom and the Trouble With Trusting a Scope Name

Tags: vulnerability intelligence, SBOM, software supply chain security, npm, crypto, credential-theft

Checkmarx published research this week on a campaign called ViteVenom, and it's a good example of how attackers are getting smarter about which trust signals developers actually check. Seven malicious npm packages were published between June 29 and July 3, all using scoped names built to look like they belonged to the real @vitejs/* namespace: things like @vite-tab/tab, @vite-pro/vite-ui, and @vitets/vite-ts. Collectively they picked up a couple thousand downloads before anyone caught them.

This is an expansion of an earlier campaign called ChainVeil, and the attacker behind both, tracked as SuccessKey, has built something genuinely unusual: a four-tier command-and-control setup that runs across the Tron, Aptos, and Binance Smart Chain networks. According to Checkmarx's writeup, the malicious code doesn't fire at install time. It waits until the package is actually imported, then queries the Tron blockchain for the latest transaction from the attacker's wallet, decodes that into a Binance Smart Chain transaction hash, pulls an encrypted payload out of that transaction's input field, and decrypts it with a hardcoded key. If Tron doesn't answer, it falls back to Aptos. If that fails too, there's a plain HTTP fallback that skips the blockchain entirely. The end result is a remote access trojan capable of credential harvesting, file exfiltration, and reverse shell access, and researcher Pavan Gudimalla noted that storing payload pointers on a public blockchain instead of a domain name makes the whole infrastructure nearly impossible to seize or take down.

What strikes me about this one is how the trust signal got faked. Nobody sees a package prefixed @vitejs/ and thinks twice, because that scope belongs to a project almost every frontend team runs. Attackers know this, so instead of typosquatting an unscoped package name (the old ChainVeil playbook), they built scoped names that look adjacent enough to pass a quick glance during a dependency review.

This is where having a way to check SBOM's really pays off. A dependency tree snapshot generated once a quarter won't catch a scoped package that showed up for the first time three weeks ago. But an SBOM built from the actual artifact identity, checked against real provenance data rather than a name that merely looks familiar, flags a brand-new, unverified scope the moment it enters a build. Namespace confusion like this is exactly the kind of intake-time check that should be automatic rather than something a developer has to remember to eyeball.

Gastropod does this at the point of intake, checking PURL identity and provenance against Sigstore and npm's SRI data so a package pretending to belong to a trusted scope gets flagged before it ever reaches a build, not after someone notices the download count climbing. If you want to see what that flagging looks like against a real caught package, the product page has a walkthrough.

If your team builds anything on Vite, it's worth a quick audit of your lockfiles for any of the seven packages named above, and a broader look at whether your dependency review process actually verifies scope ownership or just glances at the name.