Two npm packages compromised to deliver remote access trojan on import

Beta release versions of two npm packages in the @joyfill namespace have been compromised to deliver a remote access trojan associated with the DEV#POPPER malware family. The affected packages, @joyfill/layouts version 0.1.2-2773.beta.0 and @joyfill/components version 4.0.0-rc24-2773-beta.4, contain an import-time JavaScript implant that resolves encrypted code and executes malicious payloads as soon as the package is imported into a Node.js application. The compromise means that any developer or build system that installed these specific beta versions would have executed the malware automatically, without any further interaction required.

Why this matters for UK organisations

For UK organisations using Node.js and npm in development or production environments, this incident highlights the operational risk of supply chain compromises in open-source ecosystems. The attack demonstrates how easily malicious code can enter an organisation's codebase through compromised dependencies, particularly when beta or pre-release versions are used. The fact that the malware executes on import, rather than requiring a specific function call, means that even security scanning or testing workflows that load the package would trigger the payload. This type of compromise can affect development machines, CI/CD pipelines and production systems if the package reaches deployment. The incident also underscores the challenge of securing software supply chains when dependencies are pulled from public repositories with limited vetting, and when the sheer volume of packages makes manual review impractical.

What to review

Review how dependencies are vetted in your development and build environments, whether pre-release or beta packages are permitted in production, and what controls exist to detect unexpected behaviour during package installation. Consider implementing dependency scanning tools that can identify known malicious packages, integrity checks that verify package contents against known good versions, and isolated build environments that limit the impact of compromised packages. Check whether your organisation has policies on the use of beta or pre-release software in production systems, and whether developers are aware of the risks associated with installing unvetted dependencies. Evaluate whether your CI/CD pipelines include monitoring for unusual network activity, file system changes or process execution during the build process, which could indicate a compromised package. Ensure that ownership of software supply chain security is clearly assigned and that it is treated as an ongoing risk management activity, not a one-time configuration task.

Source: The Hacker News