Laravel-Lang packages hit by supply chain attack that stole developer secrets

A supply chain attack against Laravel-Lang packages exposed developers to credential-stealing malware after attackers abused GitHub tags and Composer’s autoload system. Security researchers say the incident affected hundreds of historical package versions and created a risk for Laravel projects that installed or updated the affected dependencies during the compromise window.

The attack was detected on May 22, 2026, when malicious tags appeared across Laravel-Lang repositories. According to Snyk, the affected packages were community-maintained Laravel localization libraries published under the laravel-lang namespace on Packagist, not official Laravel framework packages.

Researchers initially counted 233 compromised versions, but later findings put the total at about 700 historical versions across four packages. Socket said the compromised packages included laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions.

How the Laravel-Lang attack worked

The attackers did not need to place new malicious commits directly into the normal repository history. Instead, they abused release tags, which Composer uses when resolving package versions through Packagist.

Aikido said the malicious code loaded automatically through Composer’s autoloader feature. The attacker added a src/helpers.php file and wired it into composer.json under autoload.files, which causes Composer to load that file during normal application runtime.

This made the attack especially dangerous because a developer or server could trigger the malware by installing or updating an affected package. A normal Laravel request, CLI command, queue worker, or background process could run the injected file after vendor/autoload.php loaded.

Detail	What researchers found
Attack window	Malicious activity was observed on May 22 and May 23, 2026
Package ecosystem	Composer and Packagist
Main technique	Historical Git tag manipulation
Malicious file	src/helpers.php
Execution method	Composer autoload.files
Command-and-control domain	flipboxstudio[.]info

The malware targeted cloud keys, app secrets, and developer data

The first-stage dropper disguised itself as a localization helper, then fingerprinted the host and created a temporary marker so it would not run repeatedly on the same machine. It then contacted the attacker-controlled domain and downloaded a second-stage payload.

Aikido described the second stage as a large PHP credential stealer with multiple collection modules. It searched for cloud credentials, application secrets, SSH material, database credentials, environment files, browser data, password manager vaults, and cryptocurrency wallet files.

Socket also reported that the backdoor exposed cloud, CI/CD, and developer secrets. That combination increases the risk because stolen credentials can let attackers move from a developer machine into cloud infrastructure, source code platforms, production databases, or deployment pipelines.

• AWS, GCP, Azure, and DigitalOcean credentials
• Kubernetes, Docker, Vault, and CI/CD secrets
• SSH keys and Git credentials
• Laravel .env files and database passwords
• Browser cookies, saved logins, and local password vaults
• Cryptocurrency wallet files and related secrets

Why this attack is hard to assess

The incident creates a difficult investigation problem because version numbers alone may not prove whether a system was exposed. After remediation, the same package version may no longer point to the malicious code.

Snyk warned that organizations should review install timing, composer.lock data, build artifacts, and indicators of compromise. Teams should not rely only on the current package version shown in a project after the malicious tags were removed or replaced.

StepSecurity said the attacker rewrote existing Git tags across multiple Composer packages rather than publishing only one obvious malicious release. That technique makes traditional dependency checks less reliable because the affected version names may look familiar and legitimate.

Check	What to look for
composer.lock	References to laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, or laravel-lang/actions
Installed package files	Unexpected src/helpers.php under vendor/laravel-lang directories
Temporary folders	.laravel_locale directories on Linux, macOS, or Windows hosts
Network logs	DNS or HTTP requests to flipboxstudio[.]info
Windows systems	Suspicious .vbs launchers or DebugChromium.exe

Developers should rotate secrets, not just update packages

Teams that installed affected Laravel-Lang packages during the compromise window should treat those environments as potentially compromised. Updating the dependency may remove the malicious package code, but it cannot undo credential theft if the payload already ran.

Security teams should rotate every credential that the PHP process could access. That includes Laravel app keys, database passwords, API tokens, cloud keys, SSH keys, CI/CD secrets, OAuth credentials, queue credentials, cache passwords, and tokens stored in local developer environments.

Rebuilding affected hosts from clean images gives teams more confidence than trying to remove files manually. The malware attempted to delete artifacts after exfiltration, so the absence of obvious payload files does not prove the system stayed clean.

• Quarantine affected developer machines, CI runners, and servers.
• Preserve disk and log evidence before rebuilding systems.
• Rotate application, database, cloud, Git, and CI/CD secrets.
• Invalidate active sessions tied to exposed accounts.
• Review repository access, GitHub tokens, and Packagist publishing rights.
• Enable stronger controls around tag creation and package releases.

The incident highlights a weak point in open source trust

Laravel-Lang packages help developers localize Laravel applications across many languages. Their popularity made them a useful target because a package update could reach many projects through normal development workflows.

StepSecurity confirmed the attack path in an isolated runner and said the payload could execute when a project required Composer’s autoloader. For Laravel teams, this means dependency installation and build pipelines need the same level of monitoring as production servers.

The attack also shows why maintainers and organizations need tighter controls around package publishing. Scoped tokens, hardware-backed MFA, release approvals, tag protection, and dependency monitoring can reduce the chance that one exposed credential turns into a broader ecosystem compromise.

FAQ