Laravel Lang Packages Hijacked in Active Supply Chain Attack

Active Supply Chain Attack Hits Laravel Localization Packages

A credential-stealing malware campaign is actively targeting Laravel developers through a supply chain attack on the Laravel Lang family of localization packages. According to BleepingComputer, attackers abused GitHub's version tagging system to inject malicious code into Composer packages — meaning the poison was served without a conventional release or changelog that maintainers or automated pipelines would catch.

The attack vector is precise: Composer resolves package versions from git tags, not just Packagist metadata. By creating malicious tags on the upstream GitHub repositories, attackers could serve compromised code to any composer install or composer update that resolved those tags — including fresh CI builds and production deployments.

Why This Is Worse Than It Sounds

Laravel Lang packages (laravel-lang/lang, laravel-lang/publisher, and relatives) are extremely common — virtually every multi-locale Laravel project pulls one or more of them. The payload is confirmed credential-stealing malware, which means any environment where these packages installed during the attack window should be treated as potentially exfiltrated: .env files, database credentials, API keys, and any other secrets accessible at install time.

Three compounding factors make this especially dangerous:

• Malicious tags bypass code review — the poisoned code never appears in your pull requests or diffs
• composer.lock gives false confidence — a lock file pinning a tag hash is no protection if the tag itself was retroactively pointed at a malicious commit
• CI runners are high-value targets — they often have access to deployment keys, cloud credentials, and production secrets

What to Do Right Now

If any laravel-lang/* package appears in your composer.json or composer.lock, work through this checklist immediately:

1. Audit composer.lock — find laravel-lang/* entries and check the source.reference commit hash against the official commit history on GitHub. Look for commits you don't recognize.

1. Rotate all secrets on any server or CI environment that ran composer install or composer update involving these packages. Assume everything accessible during that process — .env values, cloud credentials, database passwords, API keys — is compromised until proven otherwise.

1. Review outbound network logs from CI/CD steps that ran Composer operations. Look for unexpected connections during the install phase.

1. Pin to verified commits using Composer's #commit-hash syntax in composer.json until official clean releases are confirmed by maintainers.

1. Watch the Laravel Lang GitHub organization for maintainer-issued remediation notices and replacement release tags.

Do not simply run composer update to a new version and move on. Secret rotation and access log review are mandatory steps for any environment in the exposure window. This attack is a reminder that composer audit and lockfile integrity verification belong in every team's CI baseline — not as optional extras.