On a quiet Tuesday, the Laravel-Lang organization's PHP localization packages became a delivery mechanism for credential theft across Windows, Linux, and macOS systems. More than 700 compromised package versions appeared on Packagist, each embedding a ~5,900 line PHP credential stealer that executed automatically on package installation.
This wasn't a targeted attack. It was an automated mass deployment against one of PHP's most widely used localization libraries.
What Happened
An attacker gained control of the Laravel-Lang release pipeline and used it to republish hundreds of package versions with malicious code. The embedded payload activated on package startup—no additional user action required. The stealer harvested credentials from browsers, FTP clients, database tools, SSH configurations, and environment variables across all major operating systems.
The credential stealer itself was sophisticated: fifteen specialized collector modules targeting specific applications and credential stores. It was production malware designed for mass harvesting.
Timeline
The attack details documented by Socket and Aikido Security show a compressed timeline:
Mass republishing event: Over 700 package versions released in rapid succession, indicating automated tagging or republishing rather than manual uploads.
Automatic execution: The malicious file ran immediately upon package installation through Composer's autoload mechanism.
Cross-platform payload fetch: The embedded code pulled down the full credential stealer, which then executed collection modules based on the host operating system.
The speed and scale point to compromised automation credentials, not a manual breach of individual package versions.
Which Controls Failed
Package signing and verification: The compromised packages passed through Packagist without cryptographic verification of the publisher's identity. PHP's package ecosystem lacks the mandatory signing requirements that would flag unauthorized releases.
Release pipeline access controls: The attacker obtained credentials sufficient to trigger mass republishing. This suggests either:
- Compromised maintainer credentials without MFA
- Leaked API tokens with release permissions
- Compromised CI/CD pipeline with publish access
Dependency pinning and lock files: Organizations using composer.json with loose version constraints (^1.0 or *) automatically pulled malicious versions. Those who committed composer.lock files with specific version hashes had protection—but only if they weren't running composer update.
Automated security scanning: The malicious code executed before most vulnerability scanners could flag it. Pre-installation scanning would have caught the suspicious autoload entry and external payload fetch, but post-installation scanning happened too late.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed securely based on industry standards. For organizations processing payment data, this extends to dependency management: you must verify the integrity of third-party code before it enters your environment.
ISO/IEC 27001:2022 Control 8.31 requires protecting information during processing, including verification of software integrity. Pulling unverified packages into production violates this control.
NIST 800-53 Rev 5 Control SI-7 explicitly requires integrity verification mechanisms for software. Installing packages without hash verification or signature checking fails this requirement.
SOC 2 Type II CC6.8 requires that changes to system components be authorized, tested, and documented. Automatic dependency updates without review violate change control requirements.
The gap: These standards require integrity verification, but most PHP development workflows don't implement it by default.
Lessons and Action Items
1. Pin dependencies and commit lock files
Add this to your development standards today:
// composer.json - specify exact versions
"require": {
"vendor/package": "1.2.3"
}
Commit composer.lock to version control. This file contains SHA-256 hashes of package contents. When a team member runs composer install, Composer verifies the hash before installation.
Make composer update a reviewed action, not an automated one.
2. Implement pre-installation scanning
Add a security gate before packages enter your environment:
# In your CI/CD pipeline, before composer install
composer audit
Better: Use tools like Socket or Snyk that analyze package behavior before installation, not just known CVEs. These tools flag suspicious patterns: external payload fetches, obfuscated code, unexpected network connections.
3. Require MFA on package registry accounts
If your team publishes packages, enforce MFA on Packagist, npm, PyPI, and RubyGems accounts. The Laravel-Lang compromise likely started with stolen credentials.
For internal package registries (Artifactory, Nexus, CloudSmith), require:
- MFA for all accounts with publish permissions
- API tokens scoped to specific packages, not registry-wide access
- Token rotation every 90 days
4. Monitor for unexpected package updates
Set up alerts for dependency changes in production:
# Daily check in your monitoring system
diff composer.lock.yesterday composer.lock.today
If packages update without a corresponding pull request, investigate immediately.
5. Separate development and production dependencies
The credential stealer harvested from development tools (database clients, SSH configs, AWS credentials). Your production containers shouldn't include these tools.
Use multi-stage Docker builds:
# Build stage - includes dev dependencies
FROM php:8.2 AS builder
RUN composer install
# Production stage - only runtime dependencies
FROM php:8.2
COPY --from=builder /app/vendor /app/vendor
6. Implement least-privilege package installation
Create a dedicated service account for package installation with:
- No access to production credentials or secrets
- Read-only access to internal repositories
- Logging of all package installations
When the credential stealer executes, it finds nothing to steal.
7. Document your supply chain in compliance artifacts
For your next SOC 2 or ISO 27001 audit, document:
- How you verify package integrity (lock files, hashes)
- Your process for evaluating new dependencies
- Access controls on package registry accounts
- Monitoring for unauthorized package changes
Auditors are asking about supply chain security now. Have the documentation ready.
The Laravel-Lang attack succeeded because it exploited the gap between what security standards require (integrity verification) and what development workflows implement (trust by default). Your compliance framework already requires the controls that would have prevented this. The question is whether your development process implements them.
Start with lock files and pre-installation scanning. Those two changes catch automated supply chain attacks before they execute.
