Laravel-Lang Composer Packages Hijacked to Drop Credential Stealer

Laravel-Lang Composer packages were hijacked in a supply-chain attack that replaced trusted GitHub version tags with malicious commits and loaded a credential stealer through Composer autoloading. The campaign is especially risky for Laravel development and CI environments because the affected packages are commonly pulled during dependency updates, and the malware looked for secrets in developer machines, cloud variables, SSH material, and project configuration files.^[1]^[2]

Cartoon showing Laravel-Lang package tags being rewritten to load a credential-stealing helpers.php file — The package version looked familiar; the tag had been swapped under it.

The compromised ecosystem is not the Laravel framework itself, but the third-party Laravel-Lang translation packages distributed through Packagist and GitHub. Researchers reported that attackers did not simply publish a suspicious new version. Instead, they rewrote existing version tags, so a version that previously resolved to clean code could later resolve to a different commit containing malware.^[2] That makes ordinary “we already pinned the version” reasoning weaker unless teams also validate lockfile commit references and package contents.

StepSecurity said the injected change added a malicious src/helpers.php file and registered it through Composer’s autoload.files mechanism, which causes the file to run automatically when the package is loaded.^[2] The malware staged and executed a payload from flipboxstudio.info, then searched for secrets such as environment variables, credentials, cloud tokens, SSH keys, and configuration files.^[1]^[3] Socket also described the compromise as a credential-theft campaign against the Laravel-Lang package set.^[3]

What Laravel teams should check now

Start by freezing non-essential Composer updates in CI until the package set is reviewed. Check whether projects reference Laravel-Lang packages such as laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, or related packages mentioned in the research. Then inspect composer.lock for install or update activity during the reported compromise window, especially updates that resolved Laravel-Lang packages after the malicious tags were rewritten.^[2]

On affected systems, look for an unexpected src/helpers.php inside Laravel-Lang vendor directories, unexpected autoload.files entries in package metadata, outbound traffic to flipboxstudio.info, and suspicious temporary files or long-lived background processes spawned by PHP or Composer jobs. Because the attack targeted secrets rather than only source code, a clean reinstall is not enough if the payload may have executed. Treat exposed CI variables, deployment tokens, package registry credentials, cloud keys, SSH keys, and application .env values as potentially compromised.

The safest response is to remove compromised package versions, clear Composer caches, reinstall dependencies from trusted references, and rotate secrets used by affected developer machines or CI runners. Review recent deployment activity, newly created cloud access keys, repository webhooks, GitHub tokens, and package publishing tokens. If the package was installed in a build environment, check whether the runner had access to production secrets; supply-chain malware often wins because CI has quiet access to exactly the credentials attackers want.

This incident follows the same pattern seen in other developer-targeted attacks: trusted package workflows become the delivery channel, and the real payload is credential theft. howtofix.guide recently covered the Mini Shai-Hulud npm and PyPI package worm, a fake Hugging Face project dropping a Windows infostealer, and an older Packagist supply-chain vulnerability. The practical lesson is the same: dependency updates should be logged, lockfiles should be reviewed when tags move, and secrets should be scoped so a build job cannot become a master key.

References