GitHub Binaries in Composer: Analyzing the Packagist Supply Chain Campaign
Did anyone catch the details on the new Packagist supply chain campaign impacting eight packages? It’s a textbook example of why "polyglot" repositories are a nightmare for security hygiene.
While the packages were technically Composer (PHP) packages, the threat actors didn't touch composer.. Instead, they injected a malicious package. into the root. The goal is to execute a Linux binary hosted on a GitHub Releases URL. This is clever because it exploits the common workflow where PHP projects build frontend assets using Node.js tools.
If your CI/CD pipeline runs npm install inside a vendor directory, you're potentially executing arbitrary code as part of your dependency installation. The payload isn't just a script; it's a compiled binary, which makes static analysis harder and detection more urgent.
I strongly recommend scanning your vendor directories for JSON files that shouldn't be there or contain unusual script hooks. You can use this bash snippet to hunt for postinstall hooks in unexpected places:
grep -r "\"postinstall\"" ./vendor --include="*."
Furthermore, you should verify the integrity of any binary downloads. If your build environment is pulling binaries directly from GitHub Releases without checksum verification, you are trusting the network implicitly.
Are we seeing more of this cross-ecosystem poisoning lately, or is this just a one-off because Packagist allows arbitrary file uploads? How are teams handling this? Are we moving towards strictly air-gapped dependency proxies?
This specific TTP is becoming more common. Using postinstall scripts in package. is the path of least resistance because build pipelines often run npm install automatically without flagging it.
You can also use Semgrep to find this pattern across your repos:
rules:
- id: detect-github-binary-fetch
pattern: |
require('child_process').exec('curl ... github.com ...');
message: Potential binary fetch from GitHub
From a detection standpoint, we're looking for unusual process execution chains. If php or composer spawns a node process that immediately reaches out to the internet, that's a massive red flag.
We've added this KQL rule to our SIEM to catch the lateral movement phase on developer workstations:
DeviceProcessEvents
| where ProcessCommandLine contains "node" and ProcessCommandLine contains "postinstall"
| where InitiatingProcessFileName in ("php.exe", "composer.phar")
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access