Laravel-Lang Supply Chain Attack in 2026: 700 Versions Backdoored & How Git Tag Rewriting Defeats Version PinningAttaque Supply Chain Laravel-Lang en 2026 : 700 Versions Backdoorées & Comment le Git Tag Rewrite Contourne le Version Pinning

At 22:32 UTC on May 22, 2026, an attacker with push access to the Laravel-Lang GitHub organization began rewriting every git tag across four widely used Composer packages. By 00:00 UTC — less than 90 minutes later — more than 700 version tags had been poisoned across laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, and laravel-lang/actions. Any developer or CI/CD pipeline that ran composer install or composer update during that window — or that has run one since on a project using these packages — received a 5,900-line PHP credential stealer that fires the instant vendor/autoload.php is required.

The packages collectively record more than 10.3 million installs on Packagist, with 55 direct dependents. StepSecurity independently confirmed that 5,561 repositories were backdoored. This incident introduces a new attack class: git tag rewriting as a supply chain vector — one that defeats the version-pinning strategies most PHP teams rely on.

This guide covers the technical anatomy of the attack, how to detect whether your composer.lock is compromised, a complete incident response playbook, and concrete hardening steps to protect your Composer supply chain going forward.

The Four Affected Packages

The Laravel-Lang organization maintains a suite of community-maintained localization libraries for Laravel and other PHP frameworks. The four packages targeted on May 22, 2026 are foundational to internationalization in many Laravel projects:

• laravel-lang/lang — The flagship package. Over 502 git tags were rewritten starting at 22:32 UTC. Core translations for Laravel error messages, validation strings, and pagination labels.
• laravel-lang/attributes — Human-readable attribute name translations used by form validation.
• laravel-lang/http-statuses — Localized HTTP status code messages.
• laravel-lang/actions — Localized action names (Create, Update, Delete, etc.) for CRUD UIs.

Together these packages are installed across a wide range of Laravel applications targeting multilingual audiences — agency projects, SaaS platforms, e-commerce stores, and enterprise applications alike.

How Git Tag Rewriting Defeats Version Pinning

Most PHP teams rely on one of three strategies to pin dependencies: semantic version ranges (^3.4, ~2.0), pinned exact versions (3.4.2), or a committed composer.lock that records exact commit SHAs. This attack bypassed all three.

Git allows version tags to be moved — they are simply references that can be force-pushed to point at a different commit. The Laravel-Lang attacker exploited this to rewrite every existing tag across all four repositories to point at a new malicious commit in a fork they controlled. Rather than introducing a new malicious version 3.4.3, which package monitors would flag, the attacker made the existing 3.4.2 tag resolve to malicious code.

The malicious commits are structurally minimal. Each makes exactly two changes to the repository:

1. A new file is added at src/helpers.php containing the credential stealer payload.
2. The composer.json autoload.files array is updated to include src/helpers.php.

Because autoload.files entries are executed unconditionally when vendor/autoload.php is required — which every Laravel and Symfony application does on every request — the payload fires at application startup. No class instantiation, method call, or special trigger is required.

The malicious commits share an identical git author identity: Your Name <you@example.com> — a default git configuration value left unchanged, offering a simple detection signal in your composer.lock.

The Credential Stealer: 15 Modules, Every Secret on Your Machine

The src/helpers.php payload is a sophisticated, cross-platform credential stealer spanning approximately 5,900 lines of PHP, organized into 15 specialist collector modules. On Windows systems, it also drops and executes a binary called DebugElevator downloaded from flipboxstudio[.]info. The collected data is encrypted and exfiltrated to flipboxstudio[.]info/exfil.

The 15 modules target every category of secret likely to exist in a developer environment or CI/CD runner:

Cloud & Infrastructure Credentials

• AWS keys — ~/.aws/credentials, environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
• GCP & Azure tokens — Application default credentials, service account JSON files
• Kubernetes secrets — ~/.kube/config, service account tokens in /var/run/secrets/
• HashiCorp Vault tokens — VAULT_TOKEN env var and ~/.vault-token

Developer & CI/CD Tokens

• GitHub tokens — GITHUB_TOKEN, PATs stored in ~/.config/gh/hosts.yml and Git credential helpers
• Stripe secrets — STRIPE_SECRET_KEY from .env files
• JWT secrets — JWT_SECRET, APP_KEY (Laravel's encryption key)
• SSH private keys — All files in ~/.ssh/ matching private key patterns

Application & Database Credentials

• .env files — The entire contents of every .env, .env.local, .env.production found in the project tree and parent directories
• Database credentials — Parsed from DATABASE_URL and Laravel's DB_* env variables

Browser, Messaging & Financial Data

• Browser data — Cookies, saved passwords, and browsing history from Chrome, Firefox, Edge, and Safari profiles
• Password manager vaults — Accessible vault files from 1Password, Bitwarden, LastPass, and KeePass
• Messaging tokens — Slack workspace tokens, Discord user tokens, Telegram session files
• Cryptocurrency wallets — Wallet files, keystore JSON, and seed phrase hints from Metamask browser extension storage and desktop wallet apps

The breadth of targeting makes this more dangerous than a simple token theft. A compromised developer laptop gives the attacker everything they need to move laterally: cloud infrastructure access, repository access to push further malicious code, database access to exfiltrate user data, and financial assets.

Attack Timeline

The attack was highly automated — the speed of tag rewrites rules out manual operation:

• 22:32 UTC, May 22 — First malicious tag rewrite detected in laravel-lang/lang (502 tags). The tags appear in rapid succession, many only seconds apart.
• ~23:00 UTC, May 22 — Rewrites spread to laravel-lang/attributes and laravel-lang/http-statuses.
• 00:00 UTC, May 23 — Final rewrites in laravel-lang/actions. Total window: under 90 minutes.
• May 23, morning — Aikido Security detects the attack. The incident is reported to Packagist.
• May 23 — Packagist responds immediately: malicious versions are taken down, affected packages temporarily unlisted.
• May 22–23 — 5,561 repositories install the compromised packages, according to StepSecurity analysis.

Am I Affected? How to Detect the Compromise

The detection process relies on two signals: the installation timestamp of affected packages, and the commit SHA recorded in your composer.lock.

Step 1: Check if you use the affected packages

composer show | grep laravel-lang

If you see laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, or laravel-lang/actions in the output, proceed to step 2.

Step 2: Check the install date of your vendor directory

If you have not run composer install or composer update since 2026-05-22 22:32 UTC, and your composer.lock predates that timestamp, you are likely safe. However, verify with step 3.

Step 3: Inspect the commit SHA in composer.lock

Open composer.lock and search for each affected package. Look at the source.reference field:

{
    "name": "laravel-lang/lang",
    "version": "15.x.x",
    "source": {
        "type": "git",
        "url": "https://github.com/Laravel-Lang/lang.git",
        "reference": "<COMMIT_SHA>"
    }
}

Visit https://github.com/Laravel-Lang/lang/commit/<COMMIT_SHA> and check the commit author. If the author is Your Name <you@example.com>, your installation is compromised. If the author is a legitimate Laravel-Lang maintainer and the commit predates 2026-05-22, you are safe.

Step 4: Check for unexpected network calls at application startup

On a non-production machine, you can also monitor outbound traffic during php artisan serve startup. A compromised install will attempt to connect to flipboxstudio[.]info on first boot.

Incident Response: What to Do If You Were Compromised

If you confirm a compromised install, treat every secret accessible from that environment as stolen. Do not try to assess what the stealer might or might not have collected — assume the worst and rotate everything.

Priority 1: Rotate all credentials immediately

For developer machines that ran a compromised install:

• GitHub — Revoke all Personal Access Tokens. Generate new ones with the minimum required scopes. Invalidate any OAuth app authorizations from that machine.
• AWS — In IAM, deactivate and delete the compromised access key pair. Generate a new key. Audit CloudTrail for any API calls made with the old key in the past 8 days.
• Stripe — Roll your secret key from the Stripe Dashboard. Check payment logs for any unexpected API activity.
• Database — Rotate database passwords for all environments accessible from the machine. Review query logs for unusual SELECT/INSERT patterns.
• Laravel APP_KEY — Regenerate with php artisan key:generate. Existing encrypted cookies and sessions will be invalidated — acceptable cost.
• SSH keys — Generate new key pairs. Remove the compromised public keys from all authorized_keys files on your servers.
• Kubernetes / Vault — Revoke all tokens issued to that workstation. Rotate service account keys.

For CI/CD pipelines that installed a compromised package:

• Rotate all secrets stored as CI/CD environment variables or secrets (GitHub Actions secrets, GitLab CI variables, CircleCI context variables).
• Revoke the GITHUB_TOKEN permissions for affected repository workflows (this token auto-expires, but verify no PAT is being used).
• Audit repository webhook configurations for any new entries added in the past 8 days.

Priority 2: Clean and rebuild

# Remove the entire vendor directory
rm -rf vendor

# Pin affected packages to a safe commit SHA that predates 2026-05-22 22:32 UTC
# Update composer.json temporarily if needed, then reinstall
composer install --no-dev

# Verify the new SHAs in composer.lock are authored by legitimate maintainers
git show $(cat composer.lock | python3 -c "
import json,sys
lock=json.load(sys.stdin)
for p in lock['packages']:
    if 'laravel-lang' in p['name']:
        print(p['name'], p['source']['reference'])
")

Priority 3: Audit your git history

If any of your repositories were cloned or had code pushed from a compromised machine, audit your git log for unexpected commits or force-pushes made in the 8-day window since May 22, 2026.

Hardening Your Composer Supply Chain

The Laravel-Lang attack exposes the fundamental weakness of version pinning via git tags: tags are mutable by design. Here is how to build a more resilient Composer supply chain.

1. Commit and verify your composer.lock

Always commit composer.lock to version control. Never add it to .gitignore. The lock file records the exact commit SHA of every dependency — it is your audit trail. Require lock file changes to go through pull request review before merge.

2. Pin to commit SHAs instead of tags in critical packages

For high-value packages where tag immutability is critical, you can pin directly to a commit SHA in composer.json:

{
    "require": {
        "laravel-lang/lang": "dev-main#a3f8c12d..."
    }
}

This is verbose, but it makes git tag rewriting completely ineffective — the SHA you specified is what Composer will fetch, regardless of where tags point.

3. Add composer audit to your CI/CD pipeline

# In your CI pipeline (GitHub Actions example)
- name: Audit Composer dependencies
  run: composer audit --no-dev

Composer's built-in audit command checks your composer.lock against the Packagist security advisories database. While it would not have caught the Laravel-Lang tag rewrite in real time (the advisory was not yet published during the poisoning window), it will catch known vulnerabilities in your dependency tree and should run on every CI build.

4. Monitor Packagist security advisories

Subscribe to the Friends of PHP Security Advisories feed and configure alerts for packages in your dependency graph. Automated monitoring — rather than periodic manual audits — is what catches incidents like this within hours rather than days.

5. Implement network egress filtering in CI/CD

The Laravel-Lang credential stealer exfiltrated data to flipboxstudio[.]info. A CI/CD runner with strict network egress policies — allowing only connections to known-good package registries and your own infrastructure — would have prevented the exfiltration even if the payload ran. Consider tools like GitHub Actions' native egress firewall (on the 2026 roadmap) or self-hosted runner network policies.

6. Restrict Composer installs from source in production

The attack vector requires a composer install that downloads from source (git). Using --prefer-dist in production installations fetches pre-built distribution archives from Packagist's mirror, which are content-addressed and would not have been affected by the git tag rewrite in the same window.

composer install --prefer-dist --no-dev --no-interaction --optimize-autoloader

Why This Attack Pattern Is Different

Previous PHP supply chain attacks — such as the Composer command injection flaws (CVE-2026-40261, CVE-2026-40176) patched in April 2026 — required attackers to publish new malicious packages. Security tooling and package monitors are reasonably good at detecting new packages with suspicious patterns.

The Laravel-Lang attack introduced a different threat model: compromising the release infrastructure of a legitimate, trusted package organization. No new packages were published. No new versions appeared in dependency trees. The same trusted packages developers had used for years became the attack vector overnight. This places a premium on:

• Monitoring the integrity of existing dependencies, not just screening new ones
• Cryptographic verification of package contents beyond just git tag resolution
• Organizational access control — the attacker required push access to the laravel-lang GitHub organization

The npm ecosystem faced a similar attack pattern with Axios (March 2026) and TanStack (May 2026). The PHP/Composer ecosystem now has its own prominent case study.

Frequently Asked Questions

Le 22 mai 2026 à 22h32 UTC, un attaquant disposant d’un accès en écriture à l’organisation GitHub Laravel-Lang a commencé à réécrire tous les tags git de quatre packages Composer très utilisés. Avant 00h00 UTC — moins de 90 minutes plus tard — plus de 700 tags de versions avaient été empoisonnés dans laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses et laravel-lang/actions. Tout développeur ou pipeline CI/CD ayant exécuté composer install ou composer update pendant cette fenêtre a reçu un credential stealer PHP de 5 900 lignes, exécuté dès le chargement de vendor/autoload.php.

Les packages cumulent plus de 10,3 millions d’installations sur Packagist. StepSecurity a confirmé que 5 561 dépôts avaient été backdoorés. Cet incident introduit une nouvelle classe d’attaque : la réécriture de tags git comme vecteur supply chain — une technique qui contourne les stratégies de version pinning sur lesquelles la plupart des équipes PHP s’appuient.

Ce guide couvre l’anatomie technique de l’attaque, comment détecter si votre composer.lock est compromis, un playbook complet de réponse à l’incident, et les mesures de durcissement pour protéger votre supply chain Composer à l’avenir.

Les Quatre Packages Touchés

L’organisation Laravel-Lang maintient une suite de bibliothèques de localisation pour Laravel et d’autres frameworks PHP. Les quatre packages ciblés le 22 mai 2026 sont fondamentaux pour l’internationalisation dans de nombreux projets Laravel :

• laravel-lang/lang — Le package phare. Plus de 502 tags git réécrits à partir de 22h32 UTC. Traductions des messages d’erreur, chaînes de validation et libellés de pagination Laravel.
• laravel-lang/attributes — Traductions lisibles des noms d’attributs utilisés par la validation de formulaires.
• laravel-lang/http-statuses — Messages de codes de statut HTTP localisés.
• laravel-lang/actions — Noms d’actions localisés (Créer, Modifier, Supprimer, etc.) pour les interfaces CRUD.

Comment le Git Tag Rewriting Contourne le Version Pinning

La plupart des équipes PHP s’appuient sur trois stratégies pour figer leurs dépendances : plages de versions sémantiques (^3.4, ~2.0), versions exactes pinned (3.4.2), ou un composer.lock commité enregistrant les SHA de commits exacts. Cette attaque a contouné les trois.

Git autorise le déplacement des tags de version — ce sont de simples références qui peuvent être force-pushées vers un autre commit. L’attaquant Laravel-Lang a exploité ceci pour réécrire chaque tag existant dans les quatre dépôts afin de pointer vers un nouveau commit malveillant dans un fork qu’il contrôlait. Plutôt que d’introduire une nouvelle version malveillante 3.4.3 qui aurait été signalée, l’attaquant a fait en sorte que le tag 3.4.2 existant résolve vers du code malveillant.

Chaque commit malveillant apporte exactement deux changements : l’ajout de src/helpers.php contenant le payload, et la mise à jour de autoload.files dans composer.json pour inclure ce fichier. Puisque les entrées autoload.files s’exécutent inconditionnellement lors du chargement de vendor/autoload.php — ce que fait chaque application Laravel à chaque requête — le payload se déclenche au démarrage. Aucune instanciation de classe, appel de méthode ou déclencheur spécial n’est nécessaire.

Les commits malveillants partagent une identité git identique : Your Name <you@example.com> — une valeur de configuration git par défaut laissée inchangée, offrant un signal de détection simple dans votre composer.lock.

Le Credential Stealer : 15 Modules, Tous vos Secrets

Le payload src/helpers.php est un credential stealer cross-platform sophistiqué de près de 5 900 lignes de PHP, organisé en 15 modules spécialisés. Sur Windows, il télécharge et exécute également un binaire appelé DebugElevator depuis flipboxstudio[.]info. Les données collectées sont chiffrées et exfiltrées vers flipboxstudio[.]info/exfil.

Les 15 modules ciblent toutes les catégories de secrets susceptibles d’exister dans un environnement de développeur ou un runner CI/CD : clés AWS, tokens GCP et Azure, secrets Kubernetes, tokens Vault, tokens GitHub (y compris les PAT), clés Stripe, secrets JWT, clés SSH privées, fichiers .env, credentials base de données, données de navigateurs, coffres-forts de gestionnaires de mots de passe, tokens Slack/Discord/Telegram, et wallets de cryptomonnaies.

L’ampleur du ciblage rend cette attaque plus dangereuse qu’un simple vol de token. Une machine de développeur compromise donne à l’attaquant tout ce qu’il faut pour se déplacer latéralement : accès à l’infrastructure cloud, accès aux dépôts pour pousser du code malveillant supplémentaire, accès aux bases de données, et assets financiers.

Suis-je Touché ? Détection de la Compromission

La détection repose sur deux signaux : l’horodatage d’installation des packages concernés, et le SHA de commit enregistré dans votre composer.lock.

Étape 1 : Vérifier si vous utilisez les packages affectés

composer show | grep laravel-lang

Si vous voyez laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses ou laravel-lang/actions, passez à l’étape 2.

Étape 2 : Vérifier la date d’installation

Si vous n’avez pas exécuté composer install ou composer update depuis le 22 mai 2026 à 22h32 UTC, et que votre composer.lock est antérieur à cet horodatage, vous êtes probablement en sécurité. Vérifiez néanmoins avec l’étape 3.

Étape 3 : Inspecter le SHA dans composer.lock

Ouvrez composer.lock et cherchez chaque package affecté. Consultez le champ source.reference, puis visitez l’URL du commit sur GitHub. Si l’auteur est Your Name <you@example.com>, votre installation est compromisée. Si l’auteur est un mainteneur légitime Laravel-Lang et que le commit est antérieur au 22 mai 2026, vous êtes en sécurité.

Réponse à l’Incident : Rotation Complète des Secrets

Si vous confirmez une installation compromisée, traitez chaque secret accessible depuis cet environnement comme volé. N’essayez pas d’évaluer ce que le stealer aurait pu collecter ou non — partez du pire et faites tourner tout.

Priorités pour les machines de développement : révoquer tous les Personal Access Tokens GitHub, désactiver les clés AWS compromises et auditer CloudTrail, changer les mots de passe des bases de données, regénérer la clé Laravel (php artisan key:generate), renouveler toutes les clés SSH, révoquer les tokens Stripe et auditer les logs de paiement.

Pour les pipelines CI/CD : révoquer tous les secrets stockés comme variables d’environnement CI, vérifier les configurations de webhooks pour tout nouvel entrée, et auditer l’historique git des dépôts affectés.

Durcissement de votre Supply Chain Composer

L’attaque Laravel-Lang expose la faiblesse fondamentale du version pinning via tags git : les tags sont mutables par conception. Voici comment construire une supply chain Composer plus résiliente :

• Committez et vérifiez votre composer.lock — Toujours committer ce fichier. N’utilisez jamais --no-lock ni .gitignore sur le lockfile. Toute modification doit passer par une pull request avec revue.
• Utilisez --prefer-dist en production — Cette option télécharge les archives de distribution pré-buildées de Packagist, qui étaient content-addressed et non impactées par la réécriture de tags git pendant la même fenêtre.
• Ajoutez composer audit à votre CI/CD — La commande audit native de Composer vérifie votre lockfile contre la base d’advisories de sécurité de Packagist. Faites-la tourner à chaque build.
• Filtrez les égrès réseau en CI/CD — Un runner avec des politiques d’égrès strictes, autorisant uniquement les connexions aux registres connus, aurait bloqué l’exfiltration vers flipboxstudio[.]info.
• Surveillez l’intégrité des dépendances existantes — Ce n’est pas seulement les nouveaux packages qu’il faut filtrer : les packages de confiance installés depuis des années peuvent devenir des vecteurs du jour au lendemain si l’infrastructure de release est compromise.

Pourquoi ce Pattern d’Attaque Est Différent

Les précédentes attaques supply chain PHP — comme les failles d’injection de commandes Composer (CVE-2026-40261, CVE-2026-40176) patchées en avril 2026 — nécessitaient que les attaquants publient de nouveaux packages malveillants. Les outils de sécurité et les moniteurs de packages sont raisonnablement efficaces pour détecter les nouveaux packages avec des patterns suspects.

L’attaque Laravel-Lang introduit un modèle de menace différent : compromettre l’infrastructure de release d’une organisation de packages légitime et de confiance. Aucun nouveau package n’a été publié. Les mêmes packages de confiance utilisés depuis des années sont devenus le vecteur d’attaque du jour au lendemain. Cela renforce l’importance de la surveillance continue de l’intégrité des dépendances existantes, pas seulement du filtrage des nouvelles.

Questions Fréquentes