700 Package Versions Poisoned Through Git Tag Manipulation

On December 16, 2024, attackers compromised the Laravel Lang localization package ecosystem by rewriting GitHub version tags to point at malicious commits in their own forks. The attack affected 233 versions across three repositories, with roughly 700 historical versions potentially impacted. Developers who installed or updated these packages during the attack window received credential-stealing malware instead of localization tools.

What Happened

The attackers didn't compromise the Laravel Lang maintainer accounts or the primary repository. Instead, they exploited how Composer resolves package versions through Git tags. Here's the sequence:

1. Attackers forked the legitimate Laravel Lang repositories.
2. They added malicious code to their forks that harvests credentials.
3. They manipulated the Git tags in the original repositories to point at commits in their malicious forks.
4. When developers ran composer install or composer update, Composer followed the compromised tags to the attacker-controlled code.
5. The malicious code executed during package installation, stealing cloud credentials, Kubernetes secrets, SSH keys, and other sensitive data.

The malware targeted environment variables, configuration files, and credential stores across multiple platforms. The attackers aimed to build access to downstream targets rather than focusing on a specific platform or service.

Timeline

December 16, 2024: Attack begins. Attackers rewrite tags across Laravel Lang repositories.

Unknown duration: Developers install compromised packages through normal Composer workflows. The malicious code executes silently during installation.

Detection date: Not specified in available information, but the attack was publicly disclosed after security researchers identified the tag manipulation.

Current status: Laravel Lang maintainers have removed the malicious tags and published guidance for affected users.

Which Controls Failed or Were Missing

Dependency verification: Most development teams don't verify package signatures or commit hashes before installation. They trust that the version number in composer.json maps to legitimate code. This attack exploited that trust by keeping version numbers intact while changing what those versions pointed to.

Tag integrity monitoring: The Git tag manipulation went undetected because neither the package maintainers nor consuming organizations monitored for tag rewrites. Git tags are mutable by default—they can be deleted and recreated pointing at different commits. No automated alerting flagged this suspicious activity.

Supply chain visibility: Teams lacked visibility into the actual source of their dependencies. Composer resolved the tags to attacker-controlled repositories, but standard dependency scanning tools showed the packages as coming from the legitimate Laravel Lang project.

Installation-time execution controls: The malicious code ran during package installation with the same privileges as the developer's account. No sandboxing or permission boundaries limited what the installation scripts could access.

Credential exposure: The attack succeeded because credentials were accessible in environment variables, configuration files, and local credential stores. The malware didn't need to escalate privileges—it harvested credentials from locations where they were stored in plaintext or easily decoded formats.

What the Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed securely, including validation of all inputs. While this requirement focuses on application code, the principle extends to supply chain security: you must validate that the code you're incorporating is actually what you intended to install.

OWASP ASVS v4.0.3 Requirement 14.2.1 specifies that all components should come from trusted sources over secure channels. Git tag manipulation breaks this chain of trust by redirecting secure channels to attacker-controlled endpoints.

NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires organizations to employ integrity verification mechanisms for software components. This includes verifying that components haven't been tampered with between source and deployment.

SOC 2 Trust Service Criteria CC6.8 addresses the need for controls over system changes, including changes to software dependencies. Organizations must detect unauthorized modifications to system components.

Lessons and Action Items for Your Team

Implement commit hash pinning immediately: Stop using version tags in your composer.json. Pin to specific commit hashes instead:

{
    "require": {
        "laravel-lang/lang": "dev-main#a1b2c3d4e5f6"
    }
}

This prevents tag manipulation attacks because commit hashes are immutable. If an attacker rewrites a tag, your hash won't match and the installation will fail rather than silently pulling malicious code.

Add Composer audit to your CI pipeline: Run composer audit on every build. This checks for known vulnerabilities in your dependencies, though it wouldn't have caught this specific attack since the malicious versions weren't cataloged in vulnerability databases yet.

Monitor your dependency sources: Use composer show --installed to verify where packages are actually coming from. Compare the repository URLs against your expected sources. Automate this check and alert on any mismatches.

Isolate package installation: Run composer install in a sandboxed environment with limited credential access. Use Docker containers with read-only mounts for your credential stores, or run installations in ephemeral VMs that don't have access to production secrets.

Rotate exposed credentials now: If you installed or updated Laravel Lang packages between December 16 and the disclosure date, assume compromise. Rotate all credentials that were accessible from your development environment: cloud provider keys, SSH keys, API tokens, database passwords, and Kubernetes secrets.

Implement least-privilege credential access: Your development environment shouldn't have production credentials. Use separate credential sets for development, with just enough access to do local testing. Production credentials should only exist in your CI/CD pipeline and production infrastructure.

Add dependency change notifications: Configure alerts when dependencies change unexpectedly. Tools like Dependabot or Renovate can notify you of version updates, but you need additional monitoring for the underlying repository changes that those versions point to.

Review your lock file regularly: Your composer.lock file records the exact commit hash that was installed for each package. Commit this file to version control and review the diff when it changes. Unexpected hash changes for the same version number indicate potential tag manipulation.

The Laravel Lang attack demonstrates that version control systems are part of your attack surface. Git tags are mutable, package managers trust them implicitly, and most teams don't verify that version numbers map to the code they expect. Until you pin to commit hashes and isolate your installation environment, you're one tag rewrite away from installing malware.

Git tag security