Analyzing the 36 Fake Strapi Plugins: Redis/PG Exploits via npm postinstall
Just caught the report regarding 36 malicious npm packages masquerading as Strapi CMS plugins. It’s a classic supply chain attack vector, but the persistence mechanism here is notably aggressive.
These packages aren't just typosquatting; they are actively exploiting database services. The payload structure is consistent across the board:
package.index.jspostinstall.js
The postinstall.js script is the execution trigger, running immediately after installation to facilitate exploitation of Redis and PostgreSQL instances. From there, they drop reverse shells and harvest credentials. Since these packages often lack descriptions or repository links, manual vetting is nearly impossible during a rapid npm install.
For those running Jenkins or CI/CD pipelines, we need to look for the execution of suspicious postinstall scripts or outbound connections to non-corporate IPs from build agents. Here is a quick grep command to identify potentially risky postinstall scripts in your node_modules if you suspect a compromise:
find . -path "*/node_modules/*/postinstall.js" -exec grep -l "redis\|pg\|postgres" {} \;
Beyond detection, how is everyone handling the postinstall risk? Are you strictly using --ignore-scripts in production builds, or do you rely on software composition analysis (SCA) tools to catch these before execution?
We’ve moved to running npm install --ignore-scripts by default in our CI/CD pipelines and only explicitly running scripts for vetted packages. It’s a bit more overhead to manage the lifecycle, but it neutralizes this specific attack vector immediately. SCA tools are great, but they usually only flag known malicious hashes. If these actors change the payload slightly, you're relying on behavior analysis, not signature matching.
Good catch on the Redis/PostgreSQL angle. From a SOC perspective, we're hunting for Node.js processes spawning sh or bash shells, which is often indicative of a reverse shell trigger in these environments.
Also, check your Redis/PG logs for connections coming from localhost on unusual ports if you are running the app server on the same host as the DB.
-- Check PostgreSQL for recent unexpected logins or connections
SELECT datname, usename, client_addr, state, query_start
FROM pg_stat_activity
WHERE state = 'active' AND usename NOT IN ('postgres', 'replicator');
The lack of repository URLs and descriptions in the package. is a huge red flag. We automated a PR check that fails if a dependency has 'description': null or 'repository': undefined. It’s caught a few typosquatting attempts before, though sophisticated attackers will fill those fields with fake data. The postinstall.js presence alone should be a high-severity signal for any non-standard library.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access