Supply-Chain Attackers Hide Python Stealer in npm and Go Packages, Sidestep Lifecycle Scripts

Key points

• Two legitimate npm packages were hijacked via account takeover and pushed malicious versions carrying a Python infostealer.
• Execution routes through VS Code workspace task definitions, not lifecycle hooks, making install-time scanners blind to the campaign.
• A separate cluster of attacker-controlled Go modules pulls the same Python stager.
• The payload targets browser credentials, crypto wallet files, and developer secrets, running on Windows and Linux as well as macOS.
• Both npm packages have been removed from the registry; cached copies in corporate proxies or local node_modules remain active.

Two hijacked npm packages and a cluster of malicious Go modules are quietly dropping a Python-based information stealer on developer machines across platforms, researchers at JFrog said this week.

Is the payload the problem?

Not primarily. The delivery is. Rather than triggering through preinstall or postinstall hooks, the places most scanners actually watch, the operators wired execution to Visual Studio Code workspace task definitions. Open the project in VS Code and run a task, and the loader fires. Use any other editor and nothing obvious happens.

JFrog framed the design as an attempt to stay "compatible" with npm v12's hardening around install-time script execution. The more useful reading: the attackers watched the ecosystem tighten one door and walked through another.

The two npm packages were not typosquats. They were legitimate, previously-trusted packages whose maintainer accounts were compromised and used to push malicious versions, the credential or token takeover pattern that has driven most high-profile npm incidents over the past two years. We covered a parallel case on 5 June 2026 in "npm Hit by Dual Supply-Chain Campaigns", where poisoned packages reached more than fifty repositories through the same initial access route. The Go side of this operation uses a separate cluster of attacker-controlled modules pulling the same Python stager.

Once executed, the loader fetches a Python infostealer targeting browser credential stores, crypto wallet files, and developer secrets in environment files and shell histories. Python handles cross-platform coverage rather than separate native droppers, which keeps the attacker's maintenance burden low.

Should you worry about VS Code specifically?

tasks.json is now a credible execution sink. It joins .vscode/settings.json and devcontainer definitions as files that deserve the same scrutiny you'd give a package's scripts block. Any task that shells out to python or curl on workspace open is suspicious until proven otherwise. This campaign makes that a concrete operational concern, not a theoretical one: the malicious code lives in task definitions and source files that execute in developer context, on developer machines, exactly where credentials and signing keys live.

Our earlier story on GitHub's browser VS Code OAuth flaw from 4 June 2026 showed how the editor's integration surface compounds risk when trust assumptions go unexamined. This campaign is a different vector but the same lesson.

What should defenders do?

Install-time scanning alone is no longer sufficient. If your supply-chain controls only inspect what runs during npm install, this campaign is invisible to you.

Account takeover remains the dominant initial access vector for registry attacks. Enforce two-factor authentication and scoped publish tokens for maintainers you depend on, and pin versions rather than tracking latest.

JFrog has not, at time of writing, tied this cluster to a previously tracked actor. Package names and version strings are in their advisory. Lockfile audits are cheap. Run them.

The real watch item here isn't the infostealer itself, infostealers are commodity. It's how quickly attackers adapted when npm v12 closed the lifecycle-script door. Defenders who haven't extended their scanning to cover workspace configuration files are already behind.