Three npm Packages Squat PostCSS Names to Drop a Windows RAT
Typosquatted utilities pulled roughly a thousand combined downloads before researchers flagged them. The payload targets Windows developer machines, which is exactly where the credentials live.

Another week, another batch of malicious npm packages aimed squarely at the developer workstation.
Three packages — aes-decode-runner-pro, postcss-minify-selector, and postcss-minify-selector-parser — were published to the npm registry over the past month and pull a Windows remote access trojan onto any machine that installs them. Combined downloads sit around 1,016. Small numbers, but that's not really the point.
The failure mode here is familiar. Two of the three names ride on PostCSS, a CSS toolchain dependency that ships in basically every modern frontend build. A tired engineer running npm install against a copy-pasted command from a Stack Overflow answer is the exact target profile. The third package, aes-decode-runner-pro, leans on the same instinct — it sounds like a legit utility, so it gets typed in.
In practice, npm typosquats like this rarely need viral adoption to succeed. One install on one CI runner with cached AWS credentials, a GitHub PAT, or a long-lived npm publish token in ~/.npmrc is enough to start the lateral movement. The blast radius on a dev box is wildly disproportionate to the download count.
The payload here is a Windows RAT, which narrows the attack surface but also tells you something about the targeting. Linux containers and macOS laptops won't detonate, so the actor is either opportunistic about Windows-heavy shops or specifically hunting enterprise environments where developers still run Windows with WSL on top. Plenty of fintech and gov contractor shops fit that bill.
npm's security advisory tooling will catch up — it always does, eventually. The packages will get yanked, the user account nuked, and the advisory will land a few days late. One thing the post-mortem will say: nobody had outbound egress controls on the build agents, and nobody had npm install --ignore-scripts set as default policy.
A few things worth doing before Monday:
- Audit your lockfiles for the three names above and any close variants.
- Pin dependencies and require approval for new transitive additions via something like Renovate or Dependabot with a review gate.
- Disable lifecycle scripts by default in CI (
npm config set ignore-scripts true) and only enable them per-project where genuinely required. - Rotate any npm, GitHub, and cloud tokens that lived on a machine where one of these packages was installed.
For the broader supply-chain question: registry-side malware detection is still mostly reactive, and the economics favor the attacker. Publishing is free. Detection costs money.
Operational takeaway: treat your developer laptops and build runners like production. Because to an attacker, they already are.



