Posted in

New Packagist Supply Chain Attack Targets PHP and JavaScript Ecosystems

A newly discovered coordinated supply chain attack has compromised several packages on Packagist, exposing developers to malicious code capable of downloading and executing a Linux binary from a GitHub Releases URL.

According to cybersecurity researchers at Socket, the attack targeted Composer-based PHP packages in an unusual way. Instead of injecting malicious code into the traditional composer.json file, attackers hid the payload inside the package.json file — a tactic designed to evade detection by developers and security teams focused only on PHP dependencies.

Cross-Ecosystem Attack Strategy Raises Concerns

The campaign stands out because it combines PHP and JavaScript ecosystem abuse in a single attack chain. Many modern PHP projects bundle JavaScript tooling for frontend assets, making package.json files common even in backend-focused repositories.

Security experts warn that this “cross-ecosystem placement” increases the likelihood of the malware going unnoticed during routine dependency audits.

The malicious package versions have since been removed from Packagist, but the incident highlights growing risks in open-source software supply chains.

How the Malware Worked

Researchers discovered that compromised upstream repositories were modified to include a malicious postinstall script. Once triggered, the script attempted to:

  • Download a Linux binary from a GitHub Releases URL
  • Save the payload to /tmp/.sshd
  • Change file permissions using chmod to make it executable
  • Execute the binary silently in the background

The malware was hosted in a GitHub repository associated with the URL:

github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f

However, the GitHub account linked to the repository has since been removed, making deeper analysis of the second-stage payload difficult.

Affected Packages

The following packages and versions were identified as compromised:

  • 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)

Developers using any of these packages are strongly advised to audit their systems, rotate credentials, and remove compromised dependencies immediately.

Signs of a Larger Campaign

Socket’s investigation uncovered references to the same malicious payload in over 777 files across GitHub, suggesting the activity may be part of a much broader campaign.

In some cases, the payload was inserted directly into GitHub Actions workflow files, enabling attackers to execute malicious code during CI/CD pipelines.

Researchers noted that the attackers were not relying on a single execution technique. Instead, they used multiple persistence and execution paths, including:

  • postinstall lifecycle hooks in package.json
  • Malicious GitHub Actions workflows
  • Background execution with suppressed errors
  • TLS verification bypass techniques

Malware Masquerading as a Legitimate System Process

One notable detail is the malware’s use of the name gvfsd-network, which resembles a legitimate GNOME Virtual File System daemon used on Linux systems for managing network shares.

This naming tactic may have been intended to help the malware blend into normal system activity and avoid detection by administrators.

Why This Attack Matters

Even without access to the final payload, security researchers say the installer itself poses a serious threat because it enables remote code execution during software installation and build processes.

The incident serves as another reminder that supply chain attacks are becoming increasingly sophisticated, often targeting trusted developer ecosystems and automated build environments.

Organizations are encouraged to:

  • Audit third-party dependencies regularly
  • Monitor package.json lifecycle scripts
  • Restrict execution permissions in CI/CD environments
  • Implement software supply chain security scanning tools
  • Verify upstream repository integrity before deployment

As open-source ecosystems continue to grow, attacks like this demonstrate how a single compromised dependency can potentially impact thousands of downstream applications.

2 thoughts on “New Packagist Supply Chain Attack Targets PHP and JavaScript Ecosystems

  1. What makes this attack especially concerning is the decision to hide the payload in package.json instead of composer.json, since many PHP-focused teams may not review frontend dependencies as closely. The cross-ecosystem approach really highlights how supply chain attacks are evolving beyond a single language stack, and why dependency audits need to include every build and install script in a project.

    1. This is one of the sharpest observations on this attack we have seen. The package.json choice was not accidental – it was a deliberate exploitation of the review gap that exists in cross-functional teams.

      A backend PHP developer reviewing dependencies may never look at frontend build scripts, and that assumption is exactly what the attacker relied on. You are absolutely right that dependency audits now need to cover every build, install and postinstall script across the entire project stack regardless of language.

      At the Windows endpoint level, the defence shifts to catching what the audit missed – monitoring the actual execution behaviour of any process that runs after installation, which is where Actipace’s real-time detection operates. A great angle for a follow-up discussion. 🛡️

Leave a Reply

Your email address will not be published. Required fields are marked *