Read SafeDep's write-up, not mine
SafeDep's analysis is thorough and I am not going to rewrite it. The short version: four sock-puppet accounts, thirty-six packages, versioned from 3.6.8 so they would pass as mature Strapi v3 community plugins. Three files each. A package.json, an empty index.js, and a postinstall.js doing the work.
The payloads changed through the day across eight variants: environment and .env harvesting, Redis abuse to write crontabs and a webshell, reverse shells, a direct PostgreSQL connection with hardcoded credentials. All of it reporting to one hardcoded address over plain HTTP.
It was not aimed at Strapi users in general. The indicators point at a single crypto payment platform, down to a path containing that target's own typo. Everyone else was collateral.
This is not a Strapi vulnerability
strapi-plugin- is a convention, not a namespace. It is unscoped, anyone can publish under it, and npm runs postinstall on install with whatever privileges the install has. In CI that is often root.
None of that is fixable from the Strapi side. There is no version to upgrade to and no advisory to action, because nothing in the CMS was touched. The same attack works against any ecosystem with an open plugin convention and enough people copying install commands out of search results.
What is new is that somebody thought it was worth a day of work. Ecosystems get this attention once they are large enough that a plausible plugin name is a reasonable route to production machines. That is the actual news, and it is not the kind of milestone anyone would ask for.
There is no patch for a naming convention.
Assume compromise, then fix the install hygiene
SafeDep lists the indicators and the remediation. If any of those names are in a lockfile you have shipped, follow their list rather than mine. The headline is the obvious one: assume full compromise of the host and rotate everything reachable from it, including database passwords, API tokens, JWT secrets and any keys sitting on the filesystem.
The general hygiene is duller and worth doing anyway. Install with --ignore-scripts where a package does not need them. Commit lockfiles and read the diff when they change. Before adding a plugin, check it has a repository, a history and a human behind it, because all thirty-six of these had none of the three.
That is not a defence against a determined supply-chain attack. It is the difference between being an easy target and a slightly harder one.