What Happened
Eight packages on Packagist, the primary PHP package repository, contained malicious code that downloaded and executed a Linux binary from GitHub. The attack bypassed PHP files by inserting the payload into package.json, a Node.js configuration file typically ignored by PHP dependency scanners.
When developers installed these packages, the malicious code activated during the build process, downloading a Linux executable from a GitHub repository. Socket's analysis found 777 files across GitHub referencing the same payload, indicating a broader campaign targeting multiple repositories and ecosystems.
Timeline
Discovery Phase: Socket identified the compromised packages during routine supply chain monitoring.
Attack Window: The exact installation window remains unclear, but the technique exploits a gap in how most teams scan dependencies—they focus on what their primary language manager installs, not what build scripts might execute.
Payload Distribution: The malicious binary was hosted on GitHub, exploiting the platform's infrastructure and implicit trust as a distribution mechanism.
Scale Indicator: The 777 GitHub files referencing the same payload suggest this attack pattern was deployed across multiple targets, not limited to these eight Packagist packages.
Which Controls Failed or Were Missing
Ecosystem-Specific Scanning: Your PHP dependency scanner focused on Composer files and PHP source, ignoring package.json. Attackers exploited this oversight.
Build Process Isolation: The malicious code executed during package installation. If your build environment can access the network to pull dependencies, it can also pull malware.
Cross-Repository Correlation: Each compromised package seemed isolated. Connecting all eight packages and the 777 GitHub references required cross-repository analysis, which most teams don't perform.
GitHub-Hosted Payload Trust: Developers and security tools often treat GitHub as a trusted source. Attackers exploited this by hosting their payload there instead of a suspicious domain.
Dependency Integrity Verification: Even if you're checking checksums for PHP packages, you're not verifying the integrity of executables those packages download at runtime.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates identifying and addressing vulnerabilities in bespoke and custom software, including your build process. If your payment application's build pipeline can execute arbitrary code from compromised dependencies, you've failed this requirement.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires supply chain protection measures throughout the system development life cycle, including reviewing supply chain elements. A review that only examines PHP files when your build process executes JavaScript is incomplete.
ISO/IEC 27001:2022 Control 8.31 (Separation of Development, Test and Production Environments) requires isolation between environments. Your build environment needs the same scrutiny as production. If compromised dependencies can execute code during builds, your separation controls have a gap.
SOC 2 Type II CC6.6 (Logical and Physical Access Controls) examines whether you restrict access to sensitive resources. When your build process can download and execute arbitrary binaries from the internet, you've granted network-level access that bypasses your other controls.
Lessons and Action Items for Your Team
Expand Your Scanning Scope
Don't limit dependency scanning to your primary language. Audit every file that executes during your build:
- package.json and package-lock.json (Node.js)
- requirements.txt and setup.py (Python)
- Gemfile and gemspec (Ruby)
- Any shell scripts, Makefiles, or CI configuration files
Add a scanning tool that parses all these formats, not just your primary package manager's files. Tools like Socket, Snyk, or GitHub's Dependency Review can detect cross-ecosystem threats.
Network-Isolate Your Build Environment
Your build process should not have unrestricted internet access. Implement:
- An approved package mirror or proxy that you control
- Network egress rules that block GitHub downloads during builds (packages should come from your mirror)
- Separate build networks with different firewall rules than your development workstations
If a dependency needs to download something at install time, that's a red flag requiring manual review.
Verify Dependency Integrity End-to-End
Checksum verification only works if you verify the right files. For each dependency:
- Record the expected files and their hashes
- Flag any dependency that downloads additional files post-installation
- Implement software bill of materials (SBOM) generation that captures all files, not just declared dependencies
Correlate Threat Intelligence Across Repositories
The 777 GitHub references to the same payload were the smoking gun. Build or subscribe to threat intelligence that:
- Tracks malicious payloads across hosting platforms
- Correlates indicators across language ecosystems
- Alerts when multiple packages reference the same suspicious external resource
Audit Your CI/CD Pipeline Permissions
Review what your CI/CD runners can access:
- Can they write to production systems?
- Do they have credentials that would be valuable if exfiltrated?
- Are build logs and artifacts stored where you can audit them?
A compromised build that exfiltrates AWS credentials is worse than one that just installs malware.
Test Your Detection
Create a test package that mimics this attack pattern (without actual malware):
- Add a package.json to a non-Node.js project
- Include a postinstall script that downloads a test file
- Run your CI/CD pipeline and verify your tools detect it
If your security stack doesn't flag this test, it won't catch the real attack.
The attackers chose package.json specifically because they knew PHP teams wouldn't scan it. Your security posture needs to assume attackers understand your tooling gaps better than you do.
