How Attackers Rewrote 700+ Laravel Git Tags to Steal CI/CD Secrets

1. Attack Overview: Tag Rewrites Instead of New Versions

On 2026-05-22, an attacker who obtained an organization-level push token for the laravel-lang GitHub organization force-pushed every tag of four packages ( laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, laravel-lang/actions) to a malicious fork. The 502, 233, 86 and 46 tags respectively were redirected to commits controlled by the attacker, without creating new releases or changing version numbers.

2. Execution via Composer “files” Autoload

Composer’s files autoload mode loads every listed PHP file as soon as require vendor/autoload.php runs. The attacker added a helpers.php entry to autoload.files in composer.json and placed the malicious payload in that file. When a Laravel or Symfony application (or any PHP project that includes vendor/autoload.php) starts, the payload is executed immediately.

The payload contacts the C2 domain flipboxstudio.info, downloads a second-stage payload, writes it to a hidden file under /tmp/.laravel_locale/, executes it, and self-deletes within three seconds.

3. Stolen Secrets

The loader POSTs all environment variables to the C2 server, capturing AWS keys, GitHub tokens, Kubernetes secrets, Vault tokens, SSH private keys, CI/CD variables, .env files, cloud provider credentials, Slack tokens, Stripe keys, database credentials, JWTs, etc. Linux/macOS payloads target cloud credentials; the Windows payload extracts browser‑stored passwords and includes a base64‑encoded executable.

4. Indicators of Compromise

Network

C2 domain: flipboxstudio.info GET https://flipboxstudio.info/payload (stage 1)

POST https://flipboxstudio.info/exfil (data exfiltration)

Filesystem /tmp/.laravel_locale/ hidden directory /tmp/.laravel_locale/[random6hex].php PHP loader /tmp/.[random12hex] ELF binary

Windows: %TEMP%\[random.exe] Process

Orphaned PHP process with ppid = 1

Orphaned unnamed ELF process with ppid = 1

Git

Commit author set to “Your Name” [email protected] Commit timestamps between 2026-05-22 22:32 UTC and 2026-05-23 00:00 UTC

5. Impact Scope

The four packages are widely used for Laravel localization. Any project that regenerated composer.lock after 2026-05-22 (e.g., via composer update) will resolve to the malicious commits, regardless of the original version constraint.

If a CI/CD runner executes composer update, the runner’s $GITHUB_TOKEN, AWS credentials, and all other environment variables are exposed, allowing the attacker to move laterally, create new PATs, and install backdoors.

6. Remediation Steps (Four‑Phase)

Step 1: Freeze composer update

Do not run composer update on affected projects until the supply chain is verified. Projects that still use a lockfile generated before the attack can safely run composer install.

Step 2: Inspect composer.lock

Open composer.lock and locate the reference field for each affected package. If the SHA matches the known malicious commits (e.g., a5ea2e8fa92ccf29cdb1d2dadbeb27722b2bff37 for laravel-lang/lang v15.29.5), the project is compromised.

Step 3: Rotate All Exposed Credentials

Assume that any GitHub PAT, $GITHUB_TOKEN, cloud provider keys (AWS, GCP, Azure), container registry tokens, SSH keys, and CI/CD provider tokens have been leaked and rotate them immediately.

Step 4: Hunt for Malicious Processes and Files

Run ps auxf on runners or developer machines and look for orphaned PHP or ELF processes (ppid = 1). Check /tmp for the hidden .laravel_locale directory and any random‑named files.

7. Why This Incident Is a Milestone

It demonstrates three critical lessons: (1) the trust model of Git tags can be broken when an attacker controls push rights; (2) developers who only update once can still be compromised because historic tags can be silently redirected; (3) supply-chain detection gaps exist—Packagist removed the malicious versions only after reports, but many CI/CD runners had already executed composer update without outbound‑traffic monitoring.

8. Conclusion

The attack cleverly avoided new version numbers and leveraged Composer’s files autoload to achieve “run-on-startup” execution within three seconds, then self-deleted. Defending requires locking versions, verifying composer.lock SHAs, monitoring outbound traffic from runners, enforcing MFA and credential rotation at the organization level.