Supply Chain · Open-Source Security

Malicious npm Packages Pose as PostCSS Tools to Deliver Windows RAT

June 23, 2026 · 7 min read

Three npm packages with names nearly identical to a PostCSS utility that receives more than 127 million weekly downloads were quietly delivering a full-featured Windows remote-access trojan, complete with Chrome credential theft, to any developer who typed one wrong character at install time. JFrog Security Research disclosed the campaign on June 22, 2026, and the packages were still live on the registry at the time of reporting.

What actually happened

On June 22, 2026, JFrog Security Research published an analysis of three malicious npm packages all attributed to a single publisher account named abdrizak: aes-decode-runner-pro (145 downloads), postcss-minify-selector (256 downloads), and postcss-minify-selector-parser (615 downloads). The primary target of the typosquatting campaign is the legitimate postcss-selector-parser, a foundational PostCSS dependency with more than 127 million weekly downloads according to The Hacker News, other outlets reported figures above 150 million, making name confusion almost inevitable in a fast-moving CI pipeline.

The attack chain is deliberately layered to evade casual inspection. postcss-minify-selector presents itself as a PostCSS selector minifier and lists postcss-minify-selector-parser as a dependency; postcss-minify-selector-parser and aes-decode-runner-pro masquerade as AES/custom-codec libraries and each depend on the legitimate postcss-selector-parser, lending them an air of credibility. Regardless of which of the three packages a developer installs, the execution path converges on the same Windows payload.

The multi-stage chain JFrog documented goes: embedded JavaScript dropper → PowerShell downloader → ZIP archive fetched from a lookalike domain → VBS bootstrapper → RAT execution. The VBS script extracts dll.zip and launches chost.exe loader.py, which imports a Nuitka-compiled Python extension named audiodriver to begin RAT logic.

Once running, the RAT establishes persistence by writing a value named csshost to the Windows registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run and drops working files to %TEMP%\winPatch, %TEMP%\.store, and %TEMP%\.host. Its command-and-control traffic uses encrypted HTTP POST requests, RC4 (ARC4) encryption with MD5 hashing, internally labelled packet0825make and packet0825decode, and its capability set includes single-instance enforcement, victim UUID storage, VM-aware host profiling, remote shell execution, and bidirectional file transfer. A dedicated Chrome credential-theft module targets the browser's Local State and Login Data databases using Windows DPAPI, AES-GCM, and ChaCha20-Poly1305 decryption, writing stolen credentials to chrome_logins_dump.txt and an in-memory gather.tar.gz archive before exfiltrating them over C2.

Why this should matter to you even if you don't run PostCSS

PostCSS itself is not the story. The story is that the npm ecosystem's install-by-name trust model means any widely-used package, one with tens or hundreds of millions of weekly downloads, creates a proportionally large surface for typosquatting. A single mistyped package name in a package.json, a copy-paste from an LLM suggestion, or a transitive dependency added without review is all it takes. The three packages in this campaign collectively accumulated more than 1,000 downloads before discovery, and they were still available on the registry when JFrog published its findings.

For businesses, the downstream risk is not theoretical. A developer workstation compromised through a malicious dev-dependency is still a compromised workstation, one with access to source code repositories, cloud-provider credentials cached in the browser, CI/CD tokens, and internal APIs. The Chrome credential-theft component in this RAT makes that exposure explicit: credentials stolen from a developer's browser can unlock services and environments far beyond the individual machine. Cyber insurers increasingly ask whether organizations have controls over the third-party code that flows into their build environments precisely because incidents like this one convert a supply-chain miss into a first-party breach.

The control that would have blunted it

The specific control here is third-party and open-source vendor access governance, knowing exactly what external code your build environment is permitted to pull, from where, and under what review process. In practice this means: maintaining an approved-package allowlist or private registry mirror so that typosquatted names fail at resolution rather than at forensics; enforcing lockfile integrity checks (npm ci over npm install) so that dependency changes require an explicit human review step; running software-composition analysis (SCA) on every pull request to flag packages from unfamiliar publishers or with low download histories relative to the name they claim; and isolating developer build environments so that a compromised workstation cannot pivot directly to production secrets.

JFrog's own remediation guidance maps directly to these controls: remove the three packages, inspect dependency trees for transitive exposure, block network indicators from the campaign, scan endpoints for %TEMP%\winPatch, %TEMP%\.store, %TEMP%\.host, and chost.exe/loader.py execution artifacts, check the HKCU\...\Run key for the csshost value, and rotate credentials from any affected developer machines. Each of those remediation steps is easier, and cheaper, when the vendor-access governance process catches the package before it ever executes.

Cyber insurers tie coverage conditions directly to this layer of control. Underwriters commonly require documented third-party risk management programs, evidence of dependency scanning in CI/CD pipelines, and privileged-access controls that limit what a compromised developer endpoint can reach. Organizations that cannot demonstrate these controls at application time frequently face coverage exclusions or higher premiums after a supply-chain incident, which means getting the governance framework in place before the claim is the only sequence that works.

If you want to go deeper on the vendor-access side of this problem, documenting third-party controls and building the evidence trail insurers and auditors expect, the Strondex SOC 2 Checklist gives you a structured framework for third-party risk management and the supporting evidence.