A newly reported software supply-chain campaign shows how attackers are shifting away from the most obvious package-install hooks and into developer workflow features that are easier to overlook. Security researchers found hijacked npm packages and multiple Go packages that used Visual Studio Code task automation to start a multi-stage infection chain, ultimately delivering a Python-based infostealer across Windows, Linux, and macOS systems.

The practical lesson is clear: package risk is no longer limited to install-time scripts. A dependency can sit quietly until a developer opens a project folder in a trusted IDE workspace. If the workspace permits automatic tasks, malicious code can execute under the developer’s user context with access to source code, credentials, browser data, wallets, and cloud tooling artifacts.

What happened

According to the report, two npm packages named html-to-gutenberg and fetch-page-assets were uploaded in late May 2026 and later removed from the npm registry. The second package depended on the first, creating a route for transitive exposure. Researchers also identified a cluster of 16 Go packages that carried the same malware structure, suggesting the operators targeted more than one developer ecosystem.

Instead of relying on npm lifecycle scripts such as postinstall, the malicious npm packages hid execution inside a .vscode/tasks.json configuration. The task was disguised as an eslint-check operation and configured with the runOn: folderOpen behavior. That means execution could occur when the malicious package directory was opened as a VS Code or Cursor workspace and the workspace was trusted or automatic tasks were explicitly allowed.

This distinction matters. VS Code does not simply execute every nested task file inside every dependency by default. The risk becomes most relevant when a developer opens the package directory itself for inspection, debugging, reuse, or contribution, then grants trust to the workspace. Attackers appear to be abusing the normal behavior of modern IDEs rather than exploiting a traditional software vulnerability.

How the infection chain works

The malicious task launched JavaScript that was disguised as a font file, reportedly named public/fonts/fa-solid-400.woff2. The file extension suggested a harmless web asset, but the content was executable JavaScript. This “fake font” technique has previously been associated with campaigns targeting developers, including activity tracked in connection with North Korean threat operations and the broader Contagious Interview-style ecosystem.

Once started, the loader used blockchain services as a dead-drop resolver. In practice, this means the malware retrieved attacker-controlled configuration or next-stage payload details from blockchain transaction data rather than from a single hard-coded domain. The report notes TronGrid as the primary mechanism and Aptos as a fallback. This design can make takedowns harder because defenders cannot simply remove one static command-and-control address embedded in the package.

The next JavaScript stage configured command-and-control communications and started a Socket.io-based backdoor. That backdoor gave operators interactive capabilities, including shell execution, clipboard collection, file system operations, file upload, process management, and arbitrary JavaScript execution. In parallel, the malware launched a Python loader that pulled down the final infostealer and installed required dependencies.

What the infostealer targets

The Python component was built for broad data theft. Reported targets included Chromium-based browsers, Mozilla Firefox, password managers, authenticators, cryptocurrency wallets, and operating system credential stores. On developer machines, the risk extended further: Git credentials, GitHub CLI configuration, GitHub Desktop logs, VS Code data, and global storage were among the artifacts of interest.

The malware also reportedly searched platform-specific stores such as Windows Credential Manager, Linux Secret Service, KDE Wallet, and macOS Keychain. Cloud storage metadata for services such as Dropbox, Google Drive, Microsoft OneDrive, Apple iCloud, Box, Mega, and pCloud was also in scope. Stolen data was compressed into ZIP archives and uploaded to attacker infrastructure, with Telegram exfiltration available if configured by the operator.

For organizations, this is especially serious because developer endpoints frequently contain a concentration of high-value secrets: package registry tokens, cloud keys, deployment credentials, SSH keys, repository access, production configuration snippets, and wallet material. Compromise of one developer workstation can become a path into source repositories, CI/CD systems, and cloud environments.

Immediate actions for developers and security teams

First, check whether any of the named npm packages or suspicious Go packages were installed, cloned, forked, or opened locally. Remove affected packages and preserve evidence if your organization has an incident response process. Because the campaign included both theft and remote-control capabilities, treat confirmed execution as a credential-compromise event rather than a simple malware cleanup.

Second, search developer workstations and repositories for unexpected .vscode/tasks.json files, especially tasks configured to run automatically on folder open. Review commands that reference files with misleading extensions, such as font files that are actually scripts. IDE trust prompts should be treated as security boundaries: developers should avoid trusting unknown package folders, proof-of-concept repositories, or job-interview code without inspection in an isolated environment.

Third, rotate exposed credentials. Prioritize npm tokens, Go module publishing credentials, GitHub and GitLab tokens, cloud provider keys, SSH keys, CI/CD secrets, password manager vault sessions, browser-stored passwords, and cryptocurrency wallet material. Review recent repository activity, package publishing logs, cloud audit trails, and unusual authentication events from developer accounts.

Finally, strengthen controls around developer tooling. Disable or restrict automatic task execution where practical, monitor for suspicious IDE task files in source control, and scan dependencies for unexpected executable content. Sandboxing unfamiliar packages in disposable virtual machines or containers can reduce the chance that a package review becomes an endpoint compromise.

Bottom line

This campaign is a reminder that attackers are adapting to security hardening in package managers by moving into the broader developer experience. IDE automation, workspace trust, transitive dependencies, and open-source package maintenance all form part of the modern attack surface. Teams that secure only install scripts may miss the next execution path.

Source: The Hacker News source