Three malicious npm packages impersonating PostCSS tools have been silently installing a Windows remote access trojan on developer machines over the past month. JFrog researchers published their findings on June 22, 2026, and all three malicious npm packages remain available on the registry. If you run Windows and have installed anything recently that references PostCSS selector parsing, here is what to check.
Which Malicious npm Packages to Look For
The three packages are postcss-minify-selector-parser (615 downloads), postcss-minify-selector (256 downloads), and aes-decode-runner-pro (145 downloads). All were published under a single npm account named “abdrizak.”
They impersonate postcss-selector-parser, a legitimate library with over 150 million weekly downloads. The fake versions share the same keywords as the real one. They also declare the genuine library as a dependency, which makes them look credible during a code review. Name-similarity tools that flag one-character typos will not catch this approach, because the names are legitimately different.
How the Attack Runs on Import
Importing any of these malicious npm packages triggers the infection chain. The package entry point loads an AES-256-GCM encrypted blob from an obfuscated configuration file. After decryption, embedded JavaScript writes a PowerShell script named settings.ps1 to disk and runs it with execution policy bypassed.
That PowerShell script uses curl.exe to fetch a ZIP from nvidiadriver[.]net, a domain built to resemble NVIDIA’s driver site. The archive extracts to %TEMP%\winPatch. A Visual Basic Script named update.vbs then launches a renamed Python 3.10 interpreter, chost.exe. That interpreter loads loader.py and starts the final payload: a set of Nuitka-compiled modules forming a full remote access trojan.
Nothing in the original npm package looks malicious to a static scanner. The dangerous logic is encoded inside a configuration blob and downloaded after installation. Sandbox tests that do not replicate real outbound network connections miss the second-stage payload entirely.
What Gets Installed on Affected Machines
The RAT sets persistence through a Windows registry run key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\csshost. After a reboot, the implant re-executes automatically.
It then connects to a command-and-control server at 95.216.92.207:8080 over encrypted HTTP, using RC4/ARC4 encryption and MD5 checksums. From that connection, the attacker can run shell commands, transfer files, and profile the host. The RAT stores a victim UUID in %TEMP%\.host and configuration data in %TEMP%\.store.
A dedicated module, auto.pyd, targets Chrome saved credentials. It runs the SQL query SELECT origin_url, username_value, password_value, date_created FROM logins against Chrome’s Login Data database and decrypts results via Windows DPAPI. It also handles Chrome’s app-bound encryption. Google added that protection in Chrome 127 specifically to block this class of credential theft. Output files named chrome_logins_dump.txt and gather.tar.gz may appear in %TEMP% if the module ran.
How to Check If You Are Affected
Start with your dependency files. Run npm ls postcss-minify-selector-parser in each project to check whether any package pulled it in transitively. Search package-lock.json files for all three package names: postcss-minify-selector-parser, postcss-minify-selector, and aes-decode-runner-pro.
On the filesystem, look for %TEMP%\winPatch and its subdirectories .store and .host. Also check for settings.ps1 in the directories where you run npm installs, and for chrome_logins_dump.txt under %TEMP%.
In the registry, open HKCU\Software\Microsoft\Windows\CurrentVersion\Run and check for an entry named csshost. On the network, look for outbound connections to 95.216.92.207 on port 8080 or DNS queries for nvidiadriver.net.
Remediation Steps
First, isolate the machine from the network. Remove all three packages from your projects. Delete %TEMP%\winPatch and its contents. Remove the csshost registry entry. Then run a full sweep for any processes spawned by chost.exe.
After cleaning the machine, rotate every Chrome-stored credential. Prioritise accounts with the highest blast radius: source code repositories, cloud consoles, CI/CD systems, and anything with production access. Enable MFA on those accounts if it is not already active.
If the affected machine is a corporate device, notify your security team before removing artefacts, so forensic evidence is preserved. The JFrog report at research.jfrog.com includes module hashes that can help your team confirm what ran and when.
Broader Lesson for Developer Environments
Developer workstations are high-value targets. They hold source repository tokens, cloud credentials, CI/CD API keys, and often direct production access. These malicious npm packages were built with that in mind. The Chrome credential module targets a protection added specifically to block credential theft. Its VM detection module helps it stay quiet in automated analysis environments. That same developer-targeting approach drove the Atomic Arch AUR supply chain attack earlier this month, which backdoored over 400 Arch Linux packages to plant a credential stealer.
Committed lockfiles reduce the attack window. npm provenance attestations, available via Sigstore since 2023, tie packages to a verified source repository. But both only help if teams treat new transitive dependency additions as events worth reviewing. Most do not.
