Laravel-Lang Packages Hijacked to Push a Cross-Platform Credential Stealer

If your PHP build pipeline pulls anything from the Laravel-Lang organization on Packagist, stop and check your lockfiles. Attackers slipped malicious tags into four widely-used packages — laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions — and used them to deliver a cross-platform credential stealer. The compromise was disclosed this week by researchers tracking suspicious tag activity on the org's GitHub repositories, and the pattern lines up with a maintainer-account or token compromise rather than a typosquat.

Your team is probably exposed somewhere. laravel-lang/lang alone has more than 75 million installs on Packagist, which makes it one of the most-pulled localization packages in the Laravel ecosystem. The malicious tags reused existing release names but pointed at altered commits, so a composer update inside the affected version window was enough to pull the payload.

The stealer itself is the interesting part. It's not a quick clipper. The loader fingerprints the host, branches by OS, and drops a Python or PowerShell stage that hunts for browser credential stores, SSH keys, cloud CLI tokens (AWS, GCP, Azure), and .env files in common project directories. On macOS it goes after Keychain prompts via osascript; on Linux it shells out for ~/.aws/credentials, ~/.config/gcloud, and Docker config. Exfil is over HTTPS to a hardcoded staging host. So this is not a smash-and-grab — it's tailored for developer machines and CI runners, which is where the real keys live.

Laravel-Lang's maintainers have pulled the bad tags and rotated tokens, and Packagist has invalidated the affected versions. But if a CI job already resolved one of those tags, the credentials that job had access to should be considered burned. (Yes, even the ones you swore were short-lived.) Treat this the way you'd treat any post-compromise cleanup: rotate first, investigate second.

A quick word on detection. Composer's composer.lock will tell you exactly which commit hash you pulled, not just the tag — compare it against the current clean tag on GitHub. Any drift is your indicator.

Defender checklist for the next hour:

1. Grep your repos and CI configs for the four package names above, then check composer.lock for commit hashes that don't match the current upstream tags.
2. Rotate every secret that any affected build job or developer workstation could read: cloud keys, deploy tokens, SSH keys, .env contents.
3. Pin Composer dependencies by commit hash (not just version) for high-blast-radius packages, and turn on Packagist's 2FA enforcement for your org.
4. Hunt outbound traffic from build agents to non-package-registry hosts over the last 14 days — your CI shouldn't be calling random IPs.
5. Subscribe to GitHub security advisories for your top 20 PHP dependencies. It's free and it's the fastest signal you'll get.

Check your lockfiles before lunch.