The eslint-config-prettier Supply Chain Attack

The eslint-config-prettier Supply Chain Attack

23 July 2025

.

04:00 PM

Introduction

The widely used open-source NPM package eslint-config-prettier has been affected by a significant supply chain attack, the package along with several others including eslint-plugin-prettier, @pkgr/core, snyckit and napi-postinstall were used to send malware to users. This blog will dissect this supply-chain hack, exploring how it happened.

What are these packages used for?
eslint-config-prettier

This is a crucial configuration tool that allows two popular JavaScript utilities, ESLint (for code analysis) and Prettier (for code formatting), to work together without fighting over conflicting rules. It essentially tells ESLint to ignore formatting rules and let Prettier handle them.

eslint-plugin-prettier

Unlike the config, this package runs Prettier's formatting rules as ESLint rules. This allows developers to see formatting issues as linting errors directly in their code editor.

@pkgr/core

A toolkit designed to simplify building, testing, and publishing code within a 'monorepo' (a single repository containing multiple distinct packages).

napi-postinstall

A utility for packages that use native code (like C++). It automatically downloads the correct pre-compiled binary for a user's specific operating system after installation.

How it Happened: The domino effect
  • GitHub user Dasa opened an issue on 18th July, 2025 on the package's GitHub repo saying the code diff 'looks odd'.
  • From seeing the code diff, we can see that there are two files added, these 2 files are infected with malware and the node-gyp.dll is a windows-executable file which is executed when the user runs the install.js script.
  • It was designed to first check if the user's operating system was Windows. If it was, the script would then use a native Windows process, rundll32.exe, to execute the node-gyp.dll file.
  • A .dll (Dynamic Link Library) is a type of executable file on Windows that can contain malicious code. By using a legitimate Windows process to run the malware, the attacker increases the chances of evading detection by basic security software.
  • This technique effectively turned a routine package installation into a malware execution event on developers' machines.
  • This attack happened due to the NPM account compromise of the package's maintainer JounQin, the threat actor sent a phishing mail mimicking support@npmjs.org

The affected versions are then disclosed by JounQin from an X post

This attack has been assigned CVE-2025-54313. (https://nvd.nist.gov/vuln/detail/CVE-2025-54313)

Package and affected versions
eslint-config-prettier

8.10.1

9.1.1

10.1.6

10.1.7

eslint-plugin-prettier

4.2.2

4.2.3

snyckit

0.11.9

@pkgr/core

0.2.8

napi-postinstall

0.3.1

Here is how you can check this on Flyingduck portal
Identify if your code is vulnerable

Using Flyingduck Global SBOM feature, identify quickly if a specific package is being used across your environment, repositories and branches.

See a Package's Security History Before You install

Thinking of adding a new dependency? Use the Flyingduck's Security Advisor to see its entire vulnerability history. You can check which previous versions had critical CVEs, helping you avoid packages with a poor security track record before they ever get into your codebase.

Finding the Safe Version

Guess work does not work - Stop guessing if you should use eslint-config-prettier@10.1.8 or 10.1.7. Flyingduck tells you the exact, safest version for every package in your package.json.

Get Relevant CVE Alerts

Flyingduck scans your repos and shows you a list of CVEs that actually affect your code base. No more digging through vague alerts.

Go from Alert to Pull Request in Minutes

Flyingduck helps you manage the fix from end to end. You can create a Jira ticket, generate a branch, and open a PR with the recommended version. Remediate vulnerabilities and track their status, ensuring a secure workflow.

Conclusion

The eslint-config-prettier incident is a powerful case in supply chain attacks. It demonstrates that the most critical vulnerabilities aren't always in the code itself, but in the human element that secures the software supply chain. This attack, originating from a single phishing email, shows how easily OSS can be exploited to turn essential development tools into malware distributors, highlighting the urgent need for better security hygiene across the entire open-source community.