Malicious Strapi plugin packages deliver Redis/Postgres exploitation payloads

TL;DR — 36 npm packages posing as strapi-plugin-* execute malware at install time via postinstall, targeting CI runners and containers to steal secrets and establish remote access.

What happened

Strapi is a Node.js headless CMS commonly extended via plugins and third-party npm dependencies.

The Hacker News reports SafeDep uncovered 36 malicious packages on npm that masquerade as Strapi community plugins (names prefixed with strapi-plugin-*) but ship multi-stage payloads. Per the report, these packages embed their primary malicious logic in a postinstall hook, meaning the code runs automatically during npm install with the privileges of the installing user — a worst-case scenario for CI runners and build containers.

SafeDep’s analysis (as summarized by The Hacker News) describes payload behaviors that include Redis-based RCE, attempts at Docker/container escape, writing a PHP web shell and Node.js reverse shell into Strapi’s public uploads path, scanning disks for secrets, harvesting environment variables and database connection strings, and PostgreSQL targeting (including querying Strapi-specific tables for secrets).

This is a supply-chain pattern platform teams should treat as “assume compromise”: attackers are not exploiting Strapi itself — they’re exploiting the trust boundary around dependency installation, where build systems often have broad credential access by design.

Who is impacted

• Any team that installed one of the malicious npm packages listed in the report (packages are presented as Strapi plugins and use version 3.6.8 to appear “mature”).
• CI/CD environments and Docker/container builds that run npm install with access to sensitive environment variables (cloud credentials, database credentials, SSH keys, registry tokens).
• Strapi deployments that rely on plugin discovery via unscoped package names (The Hacker News notes official Strapi plugins are scoped under @strapi/).

What to do now

• Follow the incident guidance as stated in the report and treat installs as potentially compromised.

  • "Users who have installed any of the aforementioned packages are advised to assume compromise and rotate all credentials."

• Inventory builds and repos for the package names listed in the article:
  • Audit package.json, lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock), and CI logs for strapi-plugin-* dependencies matching the identified set.
  • Remove the dependency, rebuild from a known-good commit, and re-run CI from a clean environment.
• Reduce blast radius in CI/CD:
  • Treat install-time execution (postinstall) as hostile: tighten egress, run builds with least-privilege credentials, and isolate high-value secrets from build steps that install third-party dependencies.
• Hunt for compromise signals aligned with the described behaviors:
  • Review for unexpected cron entries / scheduled tasks, suspicious outbound connections, and unexpected files in Strapi’s public uploads directory (the report describes web shell / reverse shell placement in uploads paths).
• Add preventive controls:
  • Prefer vetted plugin sources and scoped packages (per the report’s note that official plugins are under @strapi/), and consider allowlisting dependencies for production pipelines.