Summary
- JFrog found hijacked npm packages that hid execution inside VS Code tasks configured to run when a folder is opened.
- The malware used blockchain transaction data as a dead drop mechanism before deploying a Python infostealer.
- Developer workstations, IDE trust settings, and package ecosystems can become enterprise credential exposure.
JFrog says two hijacked npm packages used hidden Visual Studio Code tasks and blockchain dead drops to deploy a credential and cryptocurrency stealer, creating another route from developer tooling into enterprise exposure.
The compromised packages were html-to-gutenberg version 4.2.11 and fetch-page-assets version 1.2.9. JFrog said both malicious versions have since been removed from npm, but its researchers recovered and analysed the full payload chain. The versions were uploaded to npm on 25 May 2026.
The attack avoided common npm execution paths such as lifecycle scripts. Instead, it hid execution in a VS Code task configured to run automatically when the project folder was opened. The malicious logic was disguised under a fake font asset path, with a file named like a web font but containing JavaScript. JFrog said VS Code and forks such as Cursor can auto-run tasks that define runOn: folderOpen, although the trigger depends on the folder being opened as a trusted workspace or the developer allowing automatic tasks.
That execution path shifts attention from package installation into the developer workspace itself. Security controls often focus on install scripts, dependency scanning, package reputation, and CI/CD pipeline behaviour. In this case, a package did not need to execute during installation if it could execute when a developer opened a folder inside a trusted editor environment.
The payload chain then used public blockchain infrastructure as a dead drop mechanism. JFrog said the loader tried to resolve transaction data through services associated with Tron, Aptos, and BSC, extracted embedded data, decoded it, and executed later stage payloads. That separates the malicious package from the full payload and makes static inspection harder because the executable code is not stored directly in the npm package.
The later stages established command and control, backdoor capabilities, runtime bootstrapping, and a Python infostealer. JFrog said the final stage targeted browsers, password managers, authenticator extensions, cryptocurrency wallets, developer tools, Git credentials, GitHub CLI material, VS Code storage, OS credential stores, and cloud storage metadata across Windows, macOS, and Linux.
The campaign adds a distinct control problem to recent software supply chain activity. Developer workstations now hold credentials, tokens, cloud access, package publishing rights, AI coding tools, source code, local secrets, and access to production-adjacent systems. If editor trust settings and workspace tasks become execution paths, the boundary between opening code and running code becomes less reliable.
The pattern also fits modern AI assisted development. Developers increasingly move between VS Code, Cursor, GitHub Desktop, npm, AI coding assistants, package repositories, and local automation. Attackers do not need to compromise a central build system first if they can compromise a trusted package and then harvest secrets from the developer’s machine.
Enterprise response should include package removal, workstation triage, credential rotation, review of VS Code task trust, inspection for hidden .vscode/tasks.json files, and controls around which projects are marked as trusted. Where developer machines may have been exposed, token rotation should cover npm tokens, GitHub tokens, SSH keys, cloud credentials, browser stored passwords, and credentials used by AI or developer automation tools.
JFrog’s research post includes affected package versions, indicators, artefacts, and remediation steps. Trusted developer tooling is now part of the attack surface, and workspace trust decisions need the same governance discipline as dependency installation.
