CVE-2025-54313

What it actually does

This is a software supply-chain compromise in the npm package eslint-config-prettier. Specific published versions contain malicious install-time code: 8.10.1, 9.1.1, 10.1.6, and 10.1.7. When one of these versions is installed, the package executes an install.js lifecycle script. On Windows systems, that script launches a malicious DLL named node-gyp.dll, resulting in code execution in the context of the user, developer workstation, build runner, or CI process performing the install. The primary technical risk is arbitrary malware execution during dependency installation rather than exploitation of a running network service.

Why it matters to the business

Organizations that build, test, or deploy software using affected dependency versions may have exposed developer workstations, CI/CD runners, build artifacts, source repositories, credentials, signing keys, package-publishing tokens, and deployment secrets. Because this issue is listed in CISA KEV, is marked as actively exploited in the wild, and has a remediation due date of 2026-02-12, it should be treated as an urgent supply-chain incident rather than a routine dependency update. Even if production applications are not directly vulnerable at runtime, compromised build systems can lead to credential theft, malicious releases, tampered artifacts, and downstream customer impact.

How an attack unfolds

An attacker compromises or publishes malicious versions of eslint-config-prettier to the package ecosystem. A developer workstation, automated build job, dependency update bot, container build, or CI pipeline resolves and installs one of the malicious versions. During installation, npm executes the package lifecycle script install.js. On Windows hosts, the script launches the embedded node-gyp.dll malware. The malware then runs with the privileges and environment access of the install process, which may include source code access, npm tokens, Git credentials, cloud credentials, CI secrets, signing materials, or deployment permissions. The attacker can use that access to steal secrets, persist on the host, tamper with builds, publish further malicious packages, or move laterally into adjacent development and delivery infrastructure.

How to fix it

Immediately remove affected eslint-config-prettier versions 8.10.1, 9.1.1, 10.1.6, and 10.1.7 from all dependency manifests, lockfiles, caches, build images, developer workstations, and artifact repositories. Upgrade to a known-good version outside the malicious version set and regenerate lockfiles from trusted sources. Where applicable, apply the fixed downstream package versions provided: intel-ucode (Alpaquita:23) fixed in 20241112-r0; intel-ucode (Alpaquita:stream) fixed in 20241112-r0; homarr-labs/homarr fixed in commit fd62524db309429db1f233b1d0feb8e6ab4efd2d. Purge local and centralized npm caches that may contain the malicious tarballs. Rebuild affected containers and CI images from clean bases. Rotate credentials that may have been exposed on systems that installed the affected package, especially npm tokens, Git credentials, CI/CD secrets, cloud keys, signing keys, and deployment tokens. For additional risk reduction, disable or tightly control package install lifecycle scripts where feasible, use lockfile review, enforce dependency provenance controls, and restrict outbound network access from build systems.

How to confirm the fix worked

Confirm that package manifests and lockfiles do not reference eslint-config-prettier versions 8.10.1, 9.1.1, 10.1.6, or 10.1.7. Search package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, vendored node_modules directories, container layers, CI caches, and internal package mirrors. Run dependency inventory tooling such as npm ls eslint-config-prettier, yarn why eslint-config-prettier, or pnpm why eslint-config-prettier across repositories and build images. Verify that affected downstream products have been upgraded to the listed fixed versions or commits. On Windows systems that performed installs, confirm that no suspicious node-gyp.dll file remains under project node_modules paths, npm cache directories, temporary directories, or build workspaces. Validate that CI runners and build hosts have been rebuilt or cleaned and that exposed credentials have been rotated. Review recent builds to identify any installation events during the exposure window and confirm they used non-malicious package versions.

Typical attack path

1. Attacker introduces malicious code into published eslint-config-prettier package versions 8.10.1, 9.1.1, 10.1.6, or 10.1.7.
2. A developer workstation, CI runner, or build container installs dependencies using npm, yarn, pnpm, or another tool that resolves to an affected package version.
3. The package manager executes the package install lifecycle script, including install.js.
4. On Windows, install.js launches the malicious node-gyp.dll payload.
5. The payload executes with the privileges and environment variables of the install process.
6. The attacker harvests accessible credentials, source code, package tokens, cloud credentials, or CI/CD secrets.
7. The attacker may tamper with build outputs, publish additional malicious packages, pivot to source-control or deployment systems, or maintain persistence on compromised build hosts.

How to detect it

Investigate whether affected versions were installed, not only whether production applications are currently running them. Review source-control history, dependency manifests, lockfiles, SBOMs, package-manager logs, CI job logs, container build logs, internal npm proxy logs, artifact repository access logs, EDR telemetry, Windows event logs, Sysmon logs, and file-system artifacts. Search for installs of eslint-config-prettier versions 8.10.1, 9.1.1, 10.1.6, and 10.1.7. On Windows hosts, look for creation or execution of node-gyp.dll from project directories, node_modules directories, npm cache paths, temporary build directories, or CI workspaces. Review process trees where npm, yarn, pnpm, npx, node.exe, or install.js spawned suspicious child processes or loaded a DLL. Examine outbound network activity from build hosts around the time of dependency installation, particularly unusual connections shortly after package installation. Check whether secrets present in affected environments were accessed, exported, or used unexpectedly after installation. Because this is a known exploited supply-chain issue, absence of a network-facing exploit attempt does not rule out compromise; the key evidence is dependency installation plus local execution artifacts.

• eslint-config-prettier@8.10.1
• eslint-config-prettier@9.1.1
• eslint-config-prettier@10.1.6
• eslint-config-prettier@10.1.7
• node_modules/eslint-config-prettier/install.js
• node_modules\\eslint-config-prettier\\install.js
• node_modules/eslint-config-prettier/node-gyp.dll
• node_modules\\eslint-config-prettier\\node-gyp.dll
• node-gyp.dll
• "eslint-config-prettier": "8.10.1"
• "eslint-config-prettier": "9.1.1"
• "eslint-config-prettier": "10.1.6"
• "eslint-config-prettier": "10.1.7"
• eslint-config-prettier@8.10.1 postinstall
• eslint-config-prettier@9.1.1 postinstall
• eslint-config-prettier@10.1.6 postinstall
• eslint-config-prettier@10.1.7 postinstall
• install.js node-gyp.dll
• npm install eslint-config-prettier@8.10.1
• npm install eslint-config-prettier@9.1.1
• npm install eslint-config-prettier@10.1.6
• npm install eslint-config-prettier@10.1.7

What your security team should do

• Treat any Windows developer workstation, build host, or CI runner that installed eslint-config-prettier 8.10.1, 9.1.1, 10.1.6, or 10.1.7 as potentially compromised until investigated.
• Immediately block the affected package versions in dependency management, artifact repository, and software composition analysis policies.
• Search all source repositories, lockfiles, SBOMs, container images, package caches, and build logs for the affected versions and the node-gyp.dll payload.
• Purge dependency caches and rebuild CI runners, build containers, and golden images that may have installed the malicious package.
• Rotate credentials available to affected install environments, prioritizing npm publishing tokens, Git credentials, CI/CD secrets, cloud credentials, deployment keys, and code-signing materials.
• Review EDR, process execution, PowerShell, Sysmon, package-manager, and CI logs for install.js spawning node.exe, rundll32.exe, regsvr32.exe, or loading node-gyp.dll.
• Apply the listed fixed downstream versions where applicable: Alpaquita intel-ucode 20241112-r0 and homarr-labs/homarr commit fd62524db309429db1f233b1d0feb8e6ab4efd2d.
• Prioritize remediation ahead of the CISA KEV deadline of 2026-02-12 because exploitation is active in the wild.
• Implement package provenance controls, dependency pinning, lockfile review, and restricted install scripts for high-risk build environments.