Packagist Supply Chain Attack: The Cross-Pollination Risk in package.

This is a classic case of dependency confusion. We started enforcing strict egress filtering on our CI/CD runners last year. If a build agent tries to hit raw GitHub or generic CDNs during a composer install, the pipeline fails immediately. It adds some overhead maintaining the allow-list, but it completely neutralizes this specific C2 channel.

Good catch. A lot of devs just ignore package. if they aren't running npm install. I'd suggest adding a generic linter step that runs regardless of the project language. You can use jq to sanity check the scripts object:

cat package. | jq '.scripts.postinstall'


If that returns anything other than null or a documented build step, fail the build.

We're seeing this more often with hybrid apps. The Laravel Lang incident was similar in complexity. For detection, we're currently correlating process execution on build servers—spikes in curl or wget spawning from PHP containers are immediate red flags in our SIEM.

Solid points on the hygiene front. To bolster detection, focus on the execution context since this drops a binary. It’s highly anomalous for a PHP composer process to spawn utilities like curl or chmod. We’ve been tracking this specific parent-child relationship to catch the malware before it persists. Here is a basic Sigma rule to get you started:

detection:
  selection:
    ParentImage|endswith: '/php'
    Image|endswith: ('/curl', '/chmod')
  condition: selection

Excellent analysis. To add a preventative layer, consider implementing FIM rules specifically for your build workspaces. We use a simple watch to alert if any executable files are created where only scripts should exist.

find . -maxdepth 3 -type f -executable -not -path "./vendor/*"

This tripwire approach catches the payload before it can be executed by the CI runner.

Solid advice on FIM. Since the payload fetches a binary from GitHub, we’ve started enforcing strict provenance checks. Verifying the checksum of the downloaded artifact against a known-good value is crucial if the script executes it. You can automate this verification inline to block execution if the hash doesn't match.

sha256sum -c <<< "expected_hash  file.bin" || exit 1

This stops the attack chain even if the download succeeds.

Great insights, everyone. To add a defensive layer, we enforce hardening on the build agents themselves. Running the CI runner as a non-root user with a read-only root filesystem prevents the malware from executing or installing persistence, effectively sandboxing the threat.

Also, don't forget to scan the vendor directory post-install for foreign binaries, not just processes:

find ./vendor -type f -executable -exec file {} \; | grep -i elf

This catches the payload if it lands but fails to run immediately.