36 fake Strapi npm packages used in targeted attack on crypto payment infrastructure
4 min. read 
Published on
A newly uncovered npm supply chain attack used 36 malicious packages disguised as Strapi plugins to target a cryptocurrency payment environment with Redis exploitation, credential theft, database probing, and persistent backdoors. SafeDep says the packages were published from four sock-puppet npm accounts and carried eight different payload variants, which suggests an attacker was actively adapting the operation in near real time.
This was not a broad spam campaign. SafeDep’s analysis says the payloads referenced Guardarian infrastructure, specific database names, wallet-related data, and production hostnames, which points to a focused attempt to breach a real financial target rather than random Strapi users.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
The short answer is yes, this was a serious supply chain attack. The malicious packages could run automatically during npm install through postinstall logic, which means a developer or CI system could trigger the attack before anyone noticed something was wrong.
How the attack was staged
SafeDep says the 36 packages were spread across four npm accounts named umarbek1233, kekylf12, tikeqemif26, and umar_bektembiev1. The packages copied common Strapi naming patterns such as strapi-plugin-cron, strapi-plugin-events, strapi-plugin-seed, and strapi-plugin-api, while sharing the same minimal three-file structure.
SecurityWeek’s summary of the research says the payloads covered Redis code execution, Docker escape attempts, credential harvesting, reverse shell deployment, PostgreSQL targeting, and persistent implants. SafeDep further says the attacker shifted tactics over a roughly 13-hour window as earlier approaches appeared not to work.
That progression matters because it shows intent and feedback. This was not one malicious package dropped once. It looked more like an operator iterating through several intrusion paths until something stuck.
What the malware tried to do on victim systems
SafeDep says one payload abused Redis CONFIG SET to write crontab entries, PHP webshells, Node.js reverse shells, and even SSH keys. Another variant tried to escape Docker containers through overlay filesystem discovery and then write payloads into host-accessible locations.
Later variants shifted toward data theft. According to SafeDep, the attacker searched for .env files, Strapi configuration, Redis dumps, Docker and Kubernetes secrets, private keys, and wallet-related material. One package, strapi-plugin-seed, allegedly connected directly to PostgreSQL with hardcoded credentials and probed for databases named guardarian, guardarian_payments, payments, exchange, and custody.
The final stage focused on persistence. SafeDep says one strapi-plugin-api variant activated only when the hostname matched prod-strapi, wrote a hidden agent to /tmp/.node_gc.js, launched it as a detached process, and added a crontab entry. A later version removed the file requirement and switched to a fileless node -e approach.
Attack summary
| Item | Details |
|---|---|
| Ecosystem targeted | npm / Strapi |
| Number of malicious packages | 36 |
| Accounts used | 4 sock-puppet npm accounts |
| Main techniques | Redis RCE, Docker escape attempts, reverse shells, credential theft, PostgreSQL probing, persistence |
| Execution trigger | postinstall during npm install |
| Likely target | Guardarian-linked crypto payment environment |
| Persistence methods | Crontab, detached Node.js agent, fileless node -e execution |
Why Strapi users should pay attention
Strapi itself was not hacked based on the reporting available. The attack abused trust in the npm ecosystem by publishing packages that looked like community plugins. Strapi’s official docs note that plugins can be installed as npm packages, which helps explain why fake plugin names can be effective in the first place.
That distinction matters. The weakness here was package trust and install-time execution, not a confirmed compromise of Strapi’s official codebase or marketplace. SafeDep and SecurityWeek both frame the incident as a malicious npm package campaign targeting the Strapi ecosystem.
For developers, the bigger lesson is simple. If a package can execute code at install time, every install becomes part of your attack surface, especially in CI pipelines and production-adjacent environments. This incident is a sharp example of that risk.
What teams should do now
- Audit dependencies for the malicious package names identified by SafeDep.
- Rotate database passwords, API keys, JWT secrets, private keys, and any credentials stored on affected systems.
- Check for
/tmp/.node_gc.js,/tmp/vps_shell.sh, suspicious crontab entries, PHP webshells in upload paths, and outbound connections to144.31.107.231. - Review Redis, PostgreSQL, Docker, and Kubernetes secrets on any host that may have installed one of the packages.
- Report malicious packages to npm through its official abuse and security reporting flow.
FAQ
Current reporting does not show a compromise of Strapi itself. The attack used malicious npm packages that impersonated Strapi-style plugins.
SafeDep says the payloads referenced Guardarian-related databases, wallet files, production hostnames, and specific secret paths, which strongly suggests the operator had a particular victim in mind.
The packages used postinstall execution, so the payload could run automatically when the package was installed with npm.
The biggest risk is full environment compromise. The reported payloads included credential theft, database access, reverse shells, persistence, and possible escape into host infrastructure.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages