The campaign hides malware in npm and Go inside VS Code that is activated when opening your project

Cybersecurity researchers have unravel a recent campaign that took advantage of malicious packages both in npm and in the Go ecosystem to introduce a Python-based information robber on Windows, Linux and macOS machines. The relevant thing is not just malware itself, but tactic: the attackers hid the execution within an automatic task of Visual Studio Code and disguised JavaScript code as a source file, making a daily workflow of the developer into an infection vector.

The identified npm packages - including html-to-gutenberg and fetch-page-assets, which included compromised dependencies - were uploaded in late May 2026 and are no longer available in the register. In parallel, community analysis noted at least 16 Go repositories that had published versions with the same malicious load. The initial execution is activated when the package directory is opened as working space in VS Code and the malicious task marked with runOn: 'folderOpen' is automatically executed; that option is documented in the VS Code's own task guide and is precisely the mechanism that the attackers abused. https: / / code.visualstudio.com / docs / editor / tasks # _ run.

The attack chain is sophisticated and staggered: the alleged source file contains JavaScript that recovers a next stage encrypted from blockchains transactions (using services such as TronGrid and Aptos) - a "dead drop" technique that makes it difficult to take down the content -, sets up a connection to infrastructure controlled by the attacker, activates a backdoor over Socket.io and finally downloads and installs an infostealer in Python. The final component collects credentials from browsers, managers, wallets, operating system credentials stores and development devices (such as Git credentials and VS Code data), packaging information and exfiltra, even through a Telegram bot if the attacker provided a token.

In addition to the direct impact on the confidentiality of credentials and cryptomoneda funds, this incident highlights two worrying trends: first, the attackers direct their campaigns to the "developer" profile and use legitimate tools (IDEs, popular packages) to camouflage their activity; second, the reuse of resilient infrastructure (blockchain as a stage warehouse) increases the persistence and difficulty of mitigation.

For teams and developers the immediate recommendation is strong: remove any suspicious dependence or versions published on the dates indicated and look for automatic running tracks on the development machines. In particular, inspect .vscode folders in local projects and developer accounts in public repositories; check for tasks.json with options to run commands when opening the folder and review binary files or "sources" containing JavaScript code instead of legitimate source data. If you detect active engagement - unusual outgoing connections, unknown processes, or compressed files with sensitive data - consider the isolation and reinstallation of affected systems and coordinate a forensic response to determine the scope.

From the point of view of risk management, it is essential to rotate credentials after a possible exposure: change passwords and API keys, replace tokens and cloud service keys, invaliate sessions and OAuth customers, and ensure access to crypto (migration of funds to new wallets with secure private keys if there is suspicion of theft). Activate multifactor authentication and prefer dedicated password managers against browser storage. For registration accounts (npm, GitHub, etc.) enable 2FA and package verification policies.

At the organizational level, adopt hygiene controls in the software supply chain: implement blocking of versions and package signatures where possible, use Composition Analysis (SCA) software tools and approval policies for new dependencies, and run build and analysis in controlled CI / CD environments that do not depend on the developer's workspace. GitHub offers guides and features aimed at supply chain security that can help establish these practices https: / / docs.github.com / en / code-security / supply-chain-security. It also sets up "workspace trust" policies and avoids allowing the automatic execution of tasks from unverified directories.

Incidents such as this also require a proactive approach: network monitoring to detect communications to unusual domains or patterns (including traffic to blockchain and proxies APIs), continuous unit audit and SBOMs (Software Bill of Materials) production to be able to quickly identify which software might have been at risk. If you are handling assets with crypto funds, make an automatic warning about fund movements and establish emergency procedures for safe transfer.

Finally, the community should note that the traditional defence of registration of packages and ongoing controls is not enough if the delivery chain can activate the IDE functionalities or rely on decentralized infrastructure to accommodate stages. This case is a reminder that development security is not just the responsibility of operations or a single team: it requires coordination between developers, security officials, repository managers and tool providers.