Rewritten tags beat your pin: what laravel-lang says about Composer trust

The propagation works out to roughly fifteen repositories a minute, sustained across the whole six-hour window ^[20], and the tag rewriting that seeded it took only the first 90 minutes, a quarter of that time ^[18][21]. None of it required publishing a new version. Composer resolves a constraint to a tag name and then fetches whatever commit that tag currently points at, so a rewritten tag arrives with no version mismatch and no warning, according to the dev.to walkthrough ^[5]. A caret range is a lookup key, not an identity.

The same writeup then makes two claims that do not sit together. It says the rewritten tags meant even a fresh `composer install` against an outdated `composer.lock` pulled the backdoored code ^[16]. It also says the lockfile records the resolved commit SHA alongside the dist hash, and that `composer install` refuses a package whose content hash no longer matches ^[17]. If the second holds, the first should not, and the piece does not reconcile them ^[13]. That gap is load-bearing, because the headline advice resting on it, which is to commit the lock and run `composer update` only locally after reading the diff ^[6], is worth exactly as much as the hash check is. Test it against a rewritten tag on a source you control before you file it as a control.

`autoload.files` is the part with no configuration fix. Entries there execute unconditionally when the autoloader boots, unlike PSR-4 classes that load when referenced, and Laravel itself uses the mechanism for `Illuminate/Support/helpers.php` ^[9]. The injected `helpers.php` needed nothing from application code and ran on every request immediately after installation ^[2][3]. That is why the loot list reads like a build environment rather than an application: AWS keys, GitHub tokens, Kubernetes secrets and `.env` contents, posted to flipboxstudio.info ^[4]. The feature cannot be banned. It can be enumerated, and the walkthrough's suggestion is to read any unfamiliar file that appears in one of those declarations ^[12].

`composer audit` is the other gate on offer, and its weakness is timing. It reads the lockfile and compares it against the PHP Security Advisories Database ^[7], which means it blocks a package once somebody has published an advisory for that package. The walkthrough gives no advisory timestamp for the four laravel-lang packages, so nothing in it shows an audit step would have stopped installs during the six hours in question ^[14]. Composer 2.9, released in November 2025, adds `audit.block-insecure` ^[8], which enforces the same database and inherits the same lag.

What remains is detection and cleanup. Grep the lock for the four package names, treat any host that resolved fresh between 22 and 23 May as compromised, and rotate every secret the build could reach ^[10]. Outbound traffic from build machines and containers to flipboxstudio.info is the indicator on offer ^[11]. None of the recommended measures prevents a tag from being rewritten ^[15]. That control belongs to whoever hosts the git source, and it is not in your composer.json.