Strapi Supply Chain Attack: 36 Malicious npm Packages Targeting Redis & PostgreSQL
Just caught wind of a concerning supply chain attack hitting the npm registry. Researchers identified 36 malicious packages masquerading as Strapi CMS plugins. The payloads here are aggressive—they aren't just crypto miners; they actively exploit local Redis and PostgreSQL instances to establish persistence and drop reverse shells.
The IOCs are distinct but easy to overlook in a noisy environment. Every malicious package contains exactly three files (package., index.js, postinstall.js) and intentionally lacks a description or repository field. The execution chain relies entirely on the postinstall script running automatically after installation.
I whipped up a quick bash script to scan your local node_modules for these structural indicators since static analysis might miss the custom DB exploitation logic:
#!/bin/bash
# Scan for packages missing metadata with specific file structure
find node_modules -maxdepth 2 -name "package." -exec sh -c '
pkg_dir=$(dirname "$1")
pkg_name=$(jq -r ".name" "$1")
desc=$(jq -r ".description" "$1")
repo=$(jq -r ".repository" "$1")
# Check for null description/repo and existence of postinstall.js
if [[ "$desc" == "null" && "$repo" == "null" ]]; then
if [[ -f "$pkg_dir/postinstall.js" && -f "$pkg_dir/index.js" ]]; then
echo "[ALERT] Suspicious package structure: $pkg_name"
fi
fi
' _ {} \;
If you run Strapi or have exposed internal DB ports, you need to audit dependencies immediately. The persistence mechanism involves database triggers, which is a nightmare to clean up.
Anyone else seeing traffic resembling this in their env? I'm curious if anyone has captured the specific Redis commands used for the initial exploitation phase.
This is exactly why we enforce --ignore-scripts in our production CI/CD pipelines. It breaks some legitimate packages, but the security trade-off is worth it. If you can't do that, at least pin your dependencies and use npm audit religiously. The use of internal DB exploitation is a nasty pivot—most people firewall their DBs from the internet, but they trust localhost implicitly.
From a SOC perspective, we started seeing anomalies where node.exe (or node) was spawning child processes like redis-cli or psql. That is a huge red flag. You can hunt for this in Sysmon or Elastic:
ProcessCreate
| where ProcessName in ("node.exe", "node")
| where ParentProcessName in ("npm.exe", "npm")
| where FileName in ("redis-cli", "psql", "sh", "bash")
The persistence mechanism is likely abusing PostgreSQL's COPY ... FROM PROGRAM feature or Redis modules. If you suspect you were hit, check your Postgres event triggers immediately:
SELECT * FROM pg_event_trigger;
Also, verify if any unknown modules are loaded in Redis using MODULE LIST. These implants are designed to survive package removal.
To catch the mining activity or C2 callbacks early, I recommend scanning your node_modules for the specific file structure mentioned. Looking for base64 strings or known wallet addresses in those scripts works wonders.
find ./node_modules -name "postinstall.js" -exec grep -iE "stratum+tcp|miner|0x[a-f0-9]{40}" {} +
This simple one-liner often flags the payload before the execution phase completes.
Great insights everyone. For teams using Sentinel or similar SIEM platforms, I've found this KQL query helpful for hunting the postinstall script execution patterns associated with this attack:
DeviceProcessEvents
| where ProcessVersionInfoOriginalFileName == "npm.exe" or ProcessVersionInfoOriginalFileName == "node.exe"
| where ProcessCommandLine contains "postinstall" and InitiatingProcessCommandLine contains "npm install"
| extend PackageName = extract(@"package[\.]", 0, ProcessCommandLine)
| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine, PackageName
This catches the exact execution chain where npm runs postinstall scripts after package installation. Have anyone observed lateral movement capabilities in these payloads beyond the Redis and PostgreSQL exploitation?
Solid thread. For those needing immediate triage across client environments, since the payload relies heavily on postinstall.js, a quick scan for this file within node_modules is efficient. We're using this one-liner to flag packages utilizing install scripts for manual review:
find . -path "*/node_modules/*/postinstall.js" -type f
Combine this with checking package-lock. for recent additions. If you find any suspicious postinstall.js files, inspect them for base64 blobs or network calls.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access