Laravel Lang Composer packages backdoored via GitHub tag rewrite, dropping infostealer on developer machines
Attackers reused legitimate version tags on the laravel-lang GitHub repository to push malicious Composer payloads to downstream installs, harvesting credentials from build environments.
Maintainers of the popular laravel-lang/lang Composer package confirmed this week that attackers compromised the project's GitHub release pipeline and republished tagged versions with a credential-stealing payload appended to the install script. The hijack affected releases pulled between roughly 10 November and the package's emergency rollback, and any composer install or composer update against the poisoned tags during that window executed the payload with the privileges of the developer or CI runner. No CVE has been assigned at time of writing.
The package ships translations for the Laravel framework and is pulled in as a transitive dependency by a long list of Laravel starter kits and admin panels. Packagist download counts put it well into the tens of millions of historical installs, which is the bit that matters: this is a deep dependency, not a top-level one. Most affected developers will not have typed its name.
How the bug works
This was not a typosquat and not a maintainer-account phish in the usual sense. The attackers obtained write access to the GitHub repository and then re-pointed existing semver tags at new commits containing a modified composer.json with a post-install-cmd script hook. Composer, by design, executes scripts declared in the installed package's manifest unless the user passes --no-scripts, which almost nobody does in CI. Because the tags carried version numbers that already existed in Packagist's cache, downstream lockfiles resolving against ^x.y constraints happily fetched the rewritten archive on the next update.
The payload itself is a Node-based stealer staged via a shell one-liner that pulls a second-stage script from an attacker-controlled host. It enumerates the usual targets: browser credential stores, SSH keys under ~/.ssh, npm and Composer auth tokens, AWS and GCP credential files, and the .env files sitting in the working directory of whatever project triggered the install. Exfil goes out over HTTPS to a domain registered days before the campaign.
GitHub's tag-immutability behaviour is the weak link here. Tags are mutable references by default, and Packagist trusts the tag-to-commit mapping at fetch time rather than pinning by commit hash. A signed-commit or signed-tag requirement would have blocked the rewrite. Almost no PHP ecosystem packages enforce either.
The maintainers have rotated credentials, force-pushed clean tags, and asked Packagist to invalidate the poisoned versions. Developers who ran an install against the bad window should treat any secret reachable from that host as burned and rotate accordingly. And audit your CI logs for outbound connections from the install step.
The rewrite is reversed. The trust model that allowed it is not.
