Compromised npm Packages Highlight Risk Around Trusted Dependencies in Developer Environments

Overview

Researchers reported compromised beta versions of two npm packages in the @joyfill namespace: @joyfill/layouts and @joyfill/components. The published versions include malicious JavaScript code that runs when the package is loaded in Node.js.

The topic matters because the attack does not rely on a standard install script. The code runs on import, meaning it can execute when the package is used by an application, test environment, build process or server-side runtime. This makes the risk harder to spot, especially in developer and CI/CD (Continuous Integration/Continuous Delivery) environments.

What Happened

According to Socket, the affected versions contain an import-time implant embedded in the package JavaScript bundle. It uses a multi-stage mechanism to retrieve and execute additional code.

The analysis states that the infrastructure uses public blockchain transactions across Tron, Aptos and BNB Smart Chain to resolve the next stage of the attack. This approach allows attackers to change the payload without publishing a new npm package version.

The related malicious code is associated with the DEV#POPPER malware family and broader activity targeting developers and open-source ecosystems.

Why This Matters

npm packages are often treated as trusted dependencies. Developers add them, build processes load them, and CI/CD environments execute them automatically.

When such a dependency is compromised, the risk may affect:

• developer workstations;
• CI/CD runners;
• test environments;
• server-side rendering processes;
• build artifacts;
• Git credentials;
• GitHub tokens;
• npm tokens;
• .env files;
• cloud credentials;
• internal systems accessible from the build environment.

This is not only a package issue. It is a software supply chain risk affecting how code is built, tested and delivered.

Where the Risk Is for Organizations

The highest risk is in environments where the affected versions were installed and actually loaded by a Node.js process. This may happen during local development, automated testing, a build pipeline or a production process if the package is used server-side.

Importantly, npm install --ignore-scripts does not stop this type of attack. Because the malicious code is embedded in the package and runs on import, protection needs to include lockfile review, package version control, build log analysis and monitoring for unusual outbound traffic from Node.js processes.

What Should Be Checked

Teams should check whether affected 2773 beta versions of @joyfill/layouts or @joyfill/components appear in projects, lockfiles, caches, internal mirrors, build images or deployment artifacts.

Practical focus:

• remove compromised versions;
• pin to a verified clean version;
• delete node_modules and reinstall from a clean lockfile;
• review CI/CD jobs and developer machines that loaded the packages;
• rotate credentials, tokens and keys available in affected environments;
• check for unusual outbound connections from Node.js processes.

The main takeaway is simple: if a compromised dependency was loaded by a Node.js process, the environment should be treated as potentially exposed.

DIAMATIX Perspective

This case shows why developer and CI/CD environments must be part of the security model, not only the development process.

DIAMATIX treats attacks like this as software supply chain risk. One dependency can expose a developer device, build environment, tokens, source code or internal systems.

Visibility into dependencies, build processes, credentials and unusual network activity should therefore be part of SOC (Security Operations Center) and MDR (Managed Detection and Response) processes.

CISO Analysis

For CISOs, the key question is whether the organization knows which dependencies are used and what permissions the environments executing them have.

Key questions to review:

• Do we use the affected @joyfill beta versions?
• Where do npm dependencies run — locally, in CI/CD or in production?
• Which credentials are available to those processes?
• Can we quickly rotate tokens and keys after compromise?
• Do we monitor outbound connections from build and developer environments?
• Do we control new beta, prerelease or unverified versions?

The practical takeaway: software supply chain risk does not start only in source code. It also starts with every dependency that a build or developer environment loads with trust.

Review risk around trusted dependencies and CI/CD environments

DIAMATIX can help review npm dependencies, build processes, stored credentials and visibility across developer and CI/CD environments.

Request a software supply chain risk review with DIAMATIX.
Trusted · Innovative · Vigilant

Sources

• Socket. Two Joyfill npm Beta Releases Compromised to Deliver DEV#POPPER Remote Access Trojan.
• StepSecurity. Compromised npm Packages: @joyfill/components and @joyfill/layouts Ship an Obfuscated Remote Access Trojan.
• The Hacker News. Two Compromised joyfill npm Packages Run RAT When Imported Into Node.js.

This article is based on publicly available information as of July 2026.