Topic starter
20/08/2026 6:06 pm
TL;DR: A rewritten-tag supply chain attack against Laravel-Lang turned trusted Composer version strings into poisoned artifacts, and the malicious package used autoload.files to execute code on every vendor/autoload.php load, according to Corgea. The incident shows that lockfiles, tag pinning, and dependency trust assumptions fail when package references can be moved after publication.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Laravel-Lang tag rewrites turned Composer autoload into credential theft”.
Key questions
Q: What breaks when a Composer package tag is rewritten after release?
A: A rewritten tag breaks the assumption that a version string always resolves to the same code.
Q: Why does autoload.files create higher risk than normal Composer class loading?
A: autoload.files executes during application bootstrap, so any code in that path runs as soon as vendor/autoload.php is loaded.
Q: What should teams do after a malicious dependency is discovered?
A: Contain the affected endpoints, revoke any credentials that were reachable from those systems, and rebuild trust from known-clean environments.
Practitioner guidance
- Verify dependency source immutability Compare composer.lock resolved references against independently verified commit SHAs for the four Laravel-Lang packages before allowing any rebuild or update path.
- Treat autoload.files as executable code Review third-party packages for autoload.files entries and require the same approval and inspection you would apply to startup scripts or entrypoints.
- Quarantine affected build and runtime credentials Rotate cloud keys, CI tokens, SSH keys, Vault tokens, registry credentials, and Kubernetes secrets that were reachable from any affected install or bootstrap path.
Bottom line: Rewritten package tags can defeat Composer pinning by changing what a trusted version string resolves to after publication.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:41 pm
Immutable reference trust is the real control gap here: Composer version pinning assumes that a tag continues to mean the same commit, and this incident breaks that assumption. The security failure is not only malicious code, but mutable provenance in a place teams often treat as stable. Practitioners should regard dependency references as governance objects, not just build inputs.
A question worth separating out:
Q: Should teams rely on version pinning alone for supply chain safety?
A: No. Version pinning reduces drift only if the upstream reference remains immutable. When tags can be moved, teams need commit-level verification, lockfile provenance checks, and controls that separate trusted package naming from trusted artifact content.
👉 Read our full editorial: Laravel-Lang tag rewrite attack exposes composer autoload risk