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

Two hijacked npm packages and a cluster of malicious Go modules are quietly dropping a Python-based information stealer on Windows, Linux, and macOS hosts, researchers at JFrog said in a writeup this week.

The interesting part isn't the payload. It's the delivery.

Rather than triggering through preinstall, postinstall, or any of the usual npm lifecycle hooks — the places most defenders and most scanning tools actually look — the operators wired execution to Visual Studio Code workspace tasks. Open the project in VS Code, hit build or run a task, and the loader fires. Open it in any other editor and nothing obvious happens.

JFrog's analysts framed the design as an attempt to stay "compatible" with npm v12's hardening around install-time script execution. Read another way: 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 taken over and pushed malicious versions (the standard credential-or-token compromise pattern that has driven most of the high-profile npm incidents over the last two years). The Go side of the operation uses a separate cluster of attacker-controlled modules pulling the same Python stager.

Once executed, the loader fetches a Python infostealer that targets the usual surface area: browser credential stores, cookie jars, crypto wallet files, and developer secrets sitting in environment files and shell histories. Cross-platform coverage is handled by Python itself rather than separate native droppers, which keeps the attacker's maintenance burden low.

A few things working defenders should note.

First, install-time scanning is no longer sufficient. If your supply-chain controls only inspect what runs during npm install, this campaign is invisible to you. The malicious code lives in task definitions and source files that execute later, in developer context, on developer machines — exactly where credentials and signing keys live.

Second, VS Code's 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. Treat any task that shells out to python, curl, wget, or iwr on workspace open as suspicious until proven otherwise.

Third, account takeover remains the dominant initial access vector for these registry attacks. Enforce 2FA and scoped publish tokens for maintainers you depend on, and pin versions rather than tracking latest.

JFrog has not, at time of writing, published indicators tying this cluster to a previously tracked actor. The package names and version strings are in their advisory; both npm packages have since been removed from the registry, though anything cached in a corporate proxy or a developer's node_modules from the affected window is still live.

Lockfile audits are cheap. Run them.