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
chmodto 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:
postinstalllifecycle hooks inpackage.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.jsonlifecycle 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.

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.
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. 🛡️