Hijacked npm and Go Packages Deploy Python Infostealer via VS Code Tasks

Cybersecurity researchers have discovered a supply chain attack targeting developers through hijacked npm and Go packages. As reported by The Hacker News on June 29, 2026, the campaign uses an unusual delivery mechanism: VS Code task configuration files that silently execute a Python-based information stealer on Windows, Linux, and macOS systems.

What happened

Attackers compromised at least two npm packages and a cluster of Go modules. Once a developer installs one of these packages, malicious code is introduced into the project environment. Instead of relying on npm lifecycle scripts (such as preinstall or postinstall), the attack plants or modifies VS Code task files to trigger the payload. This approach is deliberate. According to JFrog, who analyzed the campaign, it appears designed to sidestep the security hardening introduced in npm v12, which added stricter controls around lifecycle script execution.

The final payload is a Python-based infostealer capable of running on all three major operating systems. Infostealers typically harvest credentials, browser session tokens, API keys, SSH keys, and environment variables from the infected machine. Because this attack targets the development environment directly, it has access to everything a developer has stored locally, including cloud credentials, private repositories, and production secrets.

Why this matters to small teams

For solo developers and small startup teams, the dependency supply chain is often trusted implicitly. You install a package, it works, you move on. Few developers inspect every file added to their project directory, let alone VS Code configuration folders. Attackers know this. By targeting tooling configuration rather than build scripts, this campaign exploits a blind spot that even security-aware developers are likely to miss.

The cross-platform nature of the infostealer raises the stakes further. This is not a Windows-only threat. If you develop on macOS or Linux, you are equally at risk. A single infected machine in a small team can expose shared credentials, internal API keys, cloud provider access tokens, and any secrets stored in .env files or local config directories.

Small teams also tend to have fewer compensating controls. There is no security operations center reviewing endpoint telemetry. There is no automated secret rotation policy. If an infostealer quietly exfiltrates your AWS credentials over a weekend, you may not notice until an unexpected bill arrives, or worse, until customer data is already gone.

How to stay protected

1. Audit your dependencies before installing. Check the package's publication history, maintainer account age, and download trends. A sudden ownership change or a spike in recent updates on a previously quiet package is a red flag.

2. Pin dependency versions and use lockfiles. Use package-lock.json or go.sum to lock exact versions. Review diffs carefully when updating, especially for transitive dependencies.

3. Inspect VS Code task and settings files in your projects. Periodically review .vscode/tasks.json and .vscode/settings.json for unexpected entries, especially anything that runs shell commands or scripts.

4. Use a tool to scan your project for known malicious packages. JFrog Xray, Socket, and similar tools can flag packages with known supply chain issues before they reach your machine.

5. Store secrets outside your project directory and use a secrets manager. Avoid .env files committed to repos or sitting in project folders. Use tools like 1Password Secrets Automation, Doppler, or your cloud provider's secrets manager.

6. Rotate credentials after any suspected exposure. If you installed a package that was later flagged as malicious, treat all credentials on that machine as compromised. Revoke and rotate API keys, cloud credentials, and SSH keys immediately.

How UNPWNED helps

UNPWNED focuses on web-facing security posture, scanning for exposed configuration files, missing security headers, and other controls that reduce your attack surface. While UNPWNED does not scan your local development environment or npm dependency tree, its checks for exposed sensitive files and misconfigured server responses can catch cases where stolen credentials or leaked config files result in publicly accessible data. If an infostealer exfiltrates credentials that later enable a web-layer compromise, a regular UNPWNED scan gives you a baseline to detect resulting misconfigurations early.

---

This post was drafted with AI assistance based on authoritative security sources, then published under editorial review.