- What: Eight Packagist (PHP) packages were backdoored via malicious
postinstallhooks in bundledpackage.jsonfiles, downloading a Linux binary that persists asgvfsd-networkin/tmp/.sshd. - Impact: Remote code execution at install-time across PHP dev/staging environments; payload references found in 777 GitHub repos including GitHub Actions workflow files.
- Fix / mitigation: Remove the eight affected packages, scan all Linux systems for
/tmp/.sshdandgvfsd-networkprocesses, rebuild any container images built during the compromise window, and extend dependency scanning topackage.jsonfiles in PHP projects. - Who's at risk: PHP developers using dev-branch versions of the listed packages (e.g.,
devdojo/wave,katanaui/katana,r2luna/brain) and any CI/CD pipelines that referenced the malicious GitHub payload URL.
A coordinated supply chain attack targeted eight packages on Packagist, the primary Composer package repository for PHP, using an unconventional cross-ecosystem technique to evade detection. Instead of inserting malicious code into composer.json files where security teams typically focus their attention, attackers embedded the payload in package.json files—exploiting projects that bundle JavaScript build tooling alongside PHP code. The compromised packages downloaded and executed a Linux binary from a GitHub Releases URL, establishing persistence in the /tmp/.sshd folder.
Attack Mechanism: Cross-Ecosystem Blind Spot
The attack exploited a critical blind spot in how development teams scan PHP dependencies. Security researchers at Socket identified that while organizations rigorously audit Composer-related metadata, they frequently overlook package.json lifecycle hooks bundled within the same package. The malicious postinstall script executed automatically during package installation, downloading a binary from github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f. The script saved the payload to /tmp/.sshd, modified permissions using chmod to grant execute access to all users, and ran it in the background—all while suppressing errors and disabling TLS verification to avoid detection.
Compromised Packages and Version Scope
The affected packages span multiple popular PHP frameworks and tools. Packagist has since removed the malicious versions, but organizations that installed these packages during the compromise window remain at risk:
- 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 compromised versions targeted development branches (dev-master, dev-main, 3.x-dev), suggesting attackers focused on packages commonly used in development and staging environments where security controls may be less stringent than production systems.
Campaign Scale: 777 GitHub References Suggest Broader Impact
Socket's investigation uncovered references to the same payload across 777 files in GitHub repositories, indicating this attack extends far beyond the eight known Packagist packages. In at least two documented instances, the malicious payload was inserted directly into GitHub workflow files, positioned to execute during GitHub Actions jobs. This multi-vector approach demonstrates attackers were not relying on a single execution mechanism—they targeted both package installation workflows and continuous integration pipelines.
The GitHub account hosting the malicious binary (parikhpreyash4/systemd-network-helper-aa5c751f) has been taken down, making it impossible to analyze the second-stage payload. However, the installer script itself provides remote code execution capabilities during installation and build workflows, warranting immediate defensive action regardless of the payload's exact functionality.
The exact number of distinct compromises remains unclear, as the 777 GitHub references may include forks, duplicate package artifacts, and cached references alongside genuine compromises. Security teams should assume broader exposure until comprehensive audits complete.
Malware Naming: Mimicking Legitimate System Processes
Attackers named the malware 'gvfsd-network,' mimicking a legitimate GNOME Virtual File System (GVfs) daemon responsible for managing and browsing network shares. This naming convention represents a deliberate attempt to blend malicious processes with normal system activity, complicating incident response and forensic analysis. System administrators monitoring process lists might overlook the malicious binary, assuming it represents standard GNOME desktop functionality. This technique is particularly effective in development environments running Linux desktops where GVfs daemons commonly appear in process lists.
Immediate Response Actions
Organizations should immediately audit all PHP projects for the presence of compromised packages, checking both installed dependencies and build logs. Focus on development and staging environments where dev-branch packages are more commonly used. Search for the /tmp/.sshd file path and gvfsd-network process names across all Linux systems.
Security teams must expand their dependency scanning to include package.json files in PHP projects, not just composer.json. Implement controls that flag or block postinstall scripts that download executables from external sources, particularly those that modify file permissions and background execution. Review GitHub Actions workflows for unauthorized modifications, searching for references to the known malicious GitHub account and payload URL. Container images built during the compromise window should be rebuilt from clean sources, as the malware may persist in cached layers.
Strategic Implications for Supply Chain Security
This attack demonstrates the vulnerability created by cross-ecosystem development patterns. Modern applications increasingly combine multiple language ecosystems—PHP with JavaScript tooling, Python with Node.js utilities, Go with npm packages. Security tools and processes designed for single-ecosystem analysis create blind spots that sophisticated attackers exploit. Organizations must implement dependency scanning that analyzes all package manifests present in a repository, regardless of the project's primary language. The coordination required to compromise eight packages simultaneously suggests a well-resourced threat actor conducting reconnaissance to identify packages with weak repository security controls.
The use of GitHub Releases as malware distribution infrastructure highlights the trust attackers exploit in legitimate platforms. Organizations should implement network controls that log and potentially restrict automated downloads from code hosting platforms during build processes, particularly for executables. The attack's focus on development branches rather than stable releases indicates threat actors understand that development environments often lack the security rigor applied to production systems, yet provide equivalent access to source code, credentials, and internal infrastructure. This reality demands security teams extend production-grade controls to development workflows, treating CI/CD pipelines and build systems as critical infrastructure warranting enhanced monitoring and access controls.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us