Composer Packages Hiding Malware in package.? The New Cross-Language Supply Chain Trick

This is exactly why we started treating package. as a first-class citizen in our SBOM generation, even for Java and PHP repos. If you're using GitHub Actions or similar, consider pinning the exact commit hash for dependencies rather than a version tag, though that doesn't stop a compromised maintainer. We're currently testing a policy that denies any outbound traffic to raw.githubusercontent.com from our build runners unless it's explicitly whitelisted.

From a pentester's perspective, this is a nightmare for blue teams because the process is running under a legitimate user context (the build runner). To detect this, you might want to correlate process creation events with network connections to GitHub's ASN during your build windows. This KQL query for Defender ATP helps spot the anomaly:

DeviceProcessEvents
| where FileName in ("wget", "curl", "node")
| join (DeviceNetworkEvents | where RemoteUrl contains "github.com") on DeviceId

We actually stopped running npm install inside vendor directories entirely. We moved all JS dependencies to the root of the project. It makes the node_modules folder huge, but it isolates the risk. If a PHP package tries to pull in a package. now, our CI pipeline fails because we explicitly composer install --no-scripts. It's aggressive, but it stops this specific vector cold.

Great point on the vector. Beyond just package., I've found that auditing composer. for post-install-cmd hooks is critical. Attackers often abuse these to trigger the malicious build process. You can run a quick grep in your CI pipeline to flag packages trying to execute arbitrary shell commands during installation:

grep -r "post-install-cmd" vendor/ | head


It’s a simple sanity check that stops the execution chain before it starts.

For incident containment, finding these hidden files is priority number one. Since our CI pipelines often skip deep scans inside vendor/, I recommend running a quick discovery command across your repos to flag any unexpected build scripts. You can hunt for these rogue artifacts using:

find ./vendor -name "package." -type f -exec grep -l "\"scripts\"" {} \;

This helps identify exactly which packages are executing unexpected JavaScript code during the build.

To add a mitigation layer, we started stripping executable permissions from the vendor directory immediately after composer install. Since PHP libraries shouldn't need executable files, this effectively neutralizes any backdoors or droppers attempting to run via those package. scripts.

You can enforce this easily in CI:

find vendor/ -type f -executable -exec chmod -x {} \;

Solid analysis. From a backup integrity perspective, don't assume your cached artifacts are clean. We compare current hashes against a known-good "golden" snapshot of our vendor/ directories to detect drift. If you need to establish a baseline quickly:

find ./vendor -name "package." -exec sha256sum {} + > baseline_hashes.txt

This makes spotting injected code during a restore verification pass significantly easier.

While auditing hooks is vital, don't overlook content analysis. Attackers often hide C2 beacons inside seemingly innocuous JSON or JS files. A quick grep for known malicious JS patterns within vendor/ can surface these payloads without needing heavy tooling:

grep -rn "child_process" vendor/ --include="*.js" --include="*."

This acts as a lightweight tripwire for cross-language injection.