Laravel Lang tag hijack turned old versions into malware

What happened#

Attackers hijacked release tags for Laravel Lang packages and used them to distribute credential-stealing malware through Composer installs.

The affected packages are third-party localization packages maintained by the Laravel Lang organization. They are not part of the official Laravel framework. The packages named in the reporting include laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and possibly laravel-lang/actions.

The key detail is how the attack was carried out. Researchers said the attackers did not simply publish a new malicious release. Instead, they rewrote existing GitHub version tags across Laravel Lang repositories so those tags pointed to malicious commits.

That matters because many dependency workflows treat a known version tag as a stable object. In this case, the apparent version could still look like a legitimate historical release, while the tag resolved to attacker-controlled code.

BleepingComputer cites analysis from Aikido, Socket, and StepSecurity. Aikido said 233 versions across three repositories were compromised. Socket said roughly 700 historical versions may have been affected. Those numbers differ, so the safest reading is that the compromise touched a large number of versions, with exact scope depending on how each researcher counted affected tags and packages.

According to StepSecurity, the rewrites started at 22:32 UTC against laravel-lang/lang and finished by 00:00 UTC against laravel-lang/actions. StepSecurity also said all four repositories shared the same fake author identity, modified files, and payload behavior, making it likely that one actor used one compromised credential with organization-wide push access.

Why this tag abuse is different#

Most developer supply chain incidents are described as malicious package releases. This one is sharper because it targeted the release pointer itself.

Git tags are often treated as release anchors. A package manager, CI job, or developer may pull a version because the version number looks familiar. If that tag is moved, the trust assumption changes. The label stays. The code behind it does not.

The attackers abused a GitHub behavior that allows tags to point to commits in forks of the same repository. That let them make release tags resolve to malicious commits stored in an attacker-controlled fork, while preserving the appearance of normal Laravel Lang package versions.

For teams, the lesson is simple: a version string is not the same thing as an immutable artifact. If the ecosystem allows tags to move, and package installation resolves through those tags, then historical versions can become an attack surface.

This does not mean every tag-based workflow is broken. It does mean organizations should know where they rely on mutable source references and where they pin immutable artifacts, checksums, lockfiles, or verified provenance.

What the malware did#

The malicious change introduced a file named src/helpers.php. Composer automatically loaded it through the package configuration.

That file acted as a dropper. It contacted the attacker-controlled command-and-control domain flipboxstudio[.]info and downloaded a second-stage PHP payload.

Researchers described the second-stage payload as a large cross-platform credential stealer for Linux, macOS, and Windows. Its targets included cloud credentials, Kubernetes secrets, Vault tokens, Git credentials, CI/CD secrets, SSH keys, browser data, cryptocurrency wallets, password manager data, VPN configurations, and local .env files.

The malware also contained regular expressions designed to extract secrets from files and environment variables. Reported targets included AWS keys, GitHub tokens, Slack tokens, Stripe secrets, database credentials, JWTs, SSH private keys, and cryptocurrency recovery phrases.

On Windows systems, the PHP payload also embedded a base64-encoded executable. The malware wrote it to the %TEMP% folder under a random .exe filename and launched it.

BleepingComputer’s analysis found that the Windows infostealer was named DebugElevator. It targeted Chrome, Brave, and Edge, including App-Bound Encryption keys used to decrypt stored browser credentials. An embedded PDB path referenced the Windows account name Mero and included claude, which may suggest AI-assisted development, though that point should not be treated as confirmed attribution.

After collection, researchers said the malware encrypted the stolen data and sent it back to the attacker’s command-and-control server.

Response and current status#

Aikido said it reported the incident to Packagist. Packagist reportedly responded quickly by removing malicious versions and temporarily unlisting affected packages to prevent more installs.

That response reduces ongoing exposure through normal package installation paths. It does not automatically clean systems where the malicious packages already ran.

This is the uncomfortable part of credential-stealing supply chain incidents. The package install is only the first event. If secrets were read and exfiltrated, removing the package does not revoke those secrets. A clean dependency tree does not make exposed tokens safe again.

Developers and security teams should treat possible execution as a credential exposure event, not only as a package integrity issue.

What teams should check now#

Teams that use Laravel Lang packages should first identify whether affected packages were installed or updated during the relevant window. The named packages are:

• laravel-lang/lang
• laravel-lang/http-statuses
• laravel-lang/attributes
• laravel-lang/actions where applicable

Then check build systems, developer workstations, CI runners, and deployment hosts where Composer installs may have executed.

Practical checks include:

• Review Composer lockfiles and install logs for Laravel Lang package versions pulled during the incident period.
• Inspect systems for src/helpers.php in affected package paths where it should not be present.
• Search proxy, DNS, EDR, and firewall logs for outbound connections to flipboxstudio[.]info.
• Rotate credentials that may have been present in .env files, shell environments, CI variables, Git configs, cloud CLIs, Kubernetes configs, Vault sessions, SSH keys, and package manager tokens.
• Review GitHub, cloud, CI/CD, and registry audit logs for suspicious access after possible exposure.
• Rebuild affected environments from trusted sources if malware execution is plausible.

Credential rotation should not be limited to Laravel application secrets. The reported malware looked broadly for developer and infrastructure credentials. That includes tokens that can open a wider path into source repositories, deployment pipelines, cloud accounts, and production systems.

What not to overclaim#

There is no need to turn this into a claim that Laravel itself was compromised. The reporting says these were third-party Laravel Lang localization packages, not official Laravel framework packages.

There is also no public basis in the source material to claim a specific number of victims, confirmed exploitation against named organizations, or a final legal attribution. The available evidence supports a supply chain compromise, tag rewriting, malicious Composer delivery, and credential-stealer behavior.

The exact count of affected versions remains reported differently by researchers. Aikido cited 233 versions across three repositories. Socket said roughly 700 historical versions may have been impacted. Both point in the same direction: the compromise was broad enough that teams should verify exposure instead of assuming they were outside scope.

The larger lesson#

This incident sits in the gap between source trust and artifact trust.

Developers often inspect a repository, trust a project, and install a version. But if the release reference can move, the version label is not enough. The real question is what exact commit, archive, hash, and provenance the build consumed at install time.

For security teams, the useful control is not panic around every open-source dependency. It is better visibility into the path from repository to package manager to build runner. Immutable references, lockfile review, artifact verification, signed releases where available, restricted maintainer permissions, and monitoring for tag rewrites all reduce the blast radius.

The attack worked because the install path could be made to look normal. That is the point worth taking forward.