Hijacked npm and Go Packages Are Stealing Developer Credentials — What Your Team Needs to Know

What was discovered

Security researchers at JFrog and Nextron Systems uncovered a supply chain attack hiding inside everyday open-source packages. Two npm packages (html-to-gutenberg and fetch-page-assets) and a cluster of 16 Go packages were modified to silently deploy a Python-based infostealer on any developer machine that installed them. The malicious code was uploaded to the npm registry on May 25, 2026, and has since been pulled, but the Go packages remained live on GitHub at the time of disclosure.

What makes this campaign dangerous is how it was hidden. Instead of using the obvious route, an npm "postinstall" lifecycle script, the attackers buried a hidden Visual Studio Code task named eslint-check inside the package, configured to run automatically the moment a developer opens the project folder in VS Code or a similar editor. The payload itself was disguised as a font file (fa-solid-400.woff2) that actually contained JavaScript. This is the same technique researchers have tied to North Korea-linked actors running the long-running "Contagious Interview" campaign, which targets developers through fake job interviews and trojanized coding assignments.

Once triggered, the JavaScript stage reached out to blockchain networks (TronGrid and Aptos) to fetch its next instructions, a technique that makes the command-and-control infrastructure extremely hard to take down. From there it installed a Socket.io backdoor giving the attacker remote shell access, clipboard monitoring, file uploads, and process control, then deployed a Python-based credential stealer as the final payload.

Which systems are affected

This attack does not target your production servers. It targets the laptops and workstations of your software developers — the people who hold the keys to your entire codebase, your cloud infrastructure, and often your customers' data. Any developer who:

• Installed html-to-gutenberg or fetch-page-assets from npm after May 25, 2026
• Pulled in any of the 16 affected Go modules as a dependency
• Opened a project containing the malicious .vscode/tasks.json file in VS Code, Cursor, or a similar IDE with auto-run tasks enabled

...is at risk of having their machine fully compromised, regardless of operating system. The malware runs on Windows, Linux, and macOS alike, which means it does not matter whether your team codes on company-issued MacBooks or personal Linux rigs.

For small and medium businesses, this is a particularly painful exposure point. Most SMB engineering teams do not have a dedicated AppSec function reviewing every dependency that gets pulled into a project. A junior developer adding what looks like a useful utility package, or a contractor cloning a "starter template" repo, is often all it takes.

How attackers are exploiting it

The infection chain is built for stealth and resilience:

1. Bait: A package with a plausible-sounding name (a WordPress content converter, a page asset fetcher) gets published or hijacked on npm, or injected into otherwise-legitimate Go repositories.
2. Trigger: A hidden VS Code task fires automatically the moment the project folder is opened and trusted, no manual command execution required.
3. Disguise: The actual malicious code is hidden inside what looks like a web font file, evading casual code review and many static scanners that don't inspect binary-looking assets.
4. Resilient C2: Blockchain transaction data is used as a "dead drop" to resolve the attacker's real command-and-control server, so even if researchers take down one server, the attacker can simply publish a new address to the blockchain.
5. Full credential harvest: Once active, the Python stealer pulls credentials from Chromium and Firefox browsers, password managers, authenticator apps, cryptocurrency wallets, Git credentials, the GitHub CLI config, GitHub Desktop logs, Windows Credential Manager, macOS Keychain, and cloud storage tokens for Dropbox, Google Drive, OneDrive, iCloud, Box, and Mega.
6. Exfiltration: Stolen data is zipped and sent to the attacker's server, with a Telegram bot used as a backup exfiltration channel.

This is not a smash-and-grab. It is a methodical attempt to walk away with every credential a developer has ever typed into their machine, including the tokens that let an attacker push code, access your cloud accounts, or pivot deeper into your company's infrastructure.

What is the real business impact

When a developer's machine is compromised this thoroughly, the blast radius extends far beyond that one laptop. Stolen Git and GitHub credentials can let an attacker push malicious commits to your private repositories, insert backdoors into your production code, or pivot to your CI/CD pipeline. Stolen cloud storage tokens can expose customer files stored in Dropbox or Google Drive. Stolen browser-saved passwords can unlock your AWS console, your payment processor dashboard, or your customer database directly.

According to IBM's Cost of a Data Breach Report, breaches involving a compromised supply chain or third-party software take an average of 26% longer to identify and contain than other breach types, and cost organizations an average of $4.45 million globally. For an SMB, even a fraction of that cost, combined with the reputational damage of a leaked codebase or a breached customer database traced back to a "trusted" open-source package, can be existential. Verizon's Data Breach Investigations Report has also repeatedly flagged supply chain compromise as one of the fastest-growing breach vectors, precisely because most companies have zero visibility into what their own dependency trees are actually pulling in.

The crypto-wallet and authenticator targeting also means this campaign is not purely about corporate espionage. Individual developers can lose personal funds, and any 2FA/authenticator data stolen can be reused to bypass account protections elsewhere.

What you should do right now

• Audit your dependencies immediately. Check whether html-to-gutenberg or fetch-page-assets appear anywhere in your package.json, lockfiles, or node_modules. Cross-reference the list of 16 flagged Go module paths against your go.mod files.
• Disable VS Code auto-run tasks by default. Set task.allowAutomaticTasks to off in your editor settings unless you explicitly trust the workspace, and never click "Yes" to "trust this folder" prompts for repositories or packages you have not personally vetted.
• Rotate credentials for any developer machine that may have run an affected package, including Git/GitHub tokens, cloud storage sessions, password manager master credentials, and any cryptocurrency wallet that was unlocked on that machine.
• Treat unfamiliar binary-looking assets with suspicion. A font file, image, or media asset bundled inside an npm or Go package that you didn't expect should be reviewed before the project is opened in an IDE.
• Establish a dependency review process. Even a lightweight policy, requiring a second pair of eyes before adding a new third-party package to a production project, would have caught this kind of injection before it reached a developer's machine.

How Volturion helps

Volturion's code analysis continuously scans every repository your company connects, checking all dependency manifests, including package.json and go.mod, against known vulnerability and malicious-package databases. If a flagged or compromised package like the ones in this campaign appears anywhere in your codebase's dependency tree, Volturion surfaces it immediately, tied to the exact file and line where it was introduced, instead of waiting for your team to stumble across a security advisory days or weeks later.

Volturion also detects secrets and credentials accidentally committed to your repositories, which matters directly here: if a compromised developer machine ever pushes leaked tokens, API keys, or configuration files back into your codebase, Volturion's secret-scanning catches it before it becomes a second, compounding incident. Combined with AI-generated remediation guidance tailored to your stack, your team gets a clear, actionable path to removing the affected dependency and locking down exposure, without needing an in-house AppSec specialist to interpret the threat.