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.
NHIMG editorial — based on content published by Corgea: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Between 22:32 UTC on 22 May 2026 and roughly midnight UTC on 23 May, attackers rewrote version tags across the community-maintained Laravel-Lang GitHub organization.
- Phoenix reports 502 rewritten tags in laravel-lang/lang, 86 in laravel-lang/attributes, and 46 in laravel-lang/actions.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when a dependency tag can be rewritten after publication?
A: The assumption that a version string always resolves to the same code breaks immediately.
Q: Why do CI and developer secrets become the main target after package execution?
A: Because malicious code running in build or bootstrap contexts can reach cloud keys, service account tokens, SSH keys, and API credentials faster than most application controls can detect.
Q: What do teams get wrong about Composer autoloading risk?
A: They often treat autoload metadata as packaging detail rather than executable trust boundary.
Practitioner guidance
- Verify resolved commit SHAs before install Check composer.lock for the four affected Laravel-Lang package names, then compare source and dist references against a known-good commit history before any update or rebuild.
- Audit autoload.files for executable bootstrap paths Search dependency manifests for autoload.files entries such as src/helpers.php, because any file listed there can execute during vendor/autoload.php loading.
- Rotate secrets reachable from CI and developer environments Prioritise cloud keys, GitHub tokens, deploy keys, registry credentials, Kubernetes service account tokens, Vault tokens, SSH keys, and database secrets that may have been exposed during package execution.
What's in the full report
Corgea's full research covers the operational detail this post intentionally leaves for the source:
- Specific package names, rewritten tag counts, and the exact compromise window for triage prioritisation
- Process-tree evidence, network indicators, and file-system artefacts that help validate execution on affected hosts
- The precise remediation workflow for composer.lock, cache preservation, and environment rebuild decisions
- The full indicator set for DNS, proxy, and host-based detection across developer and CI estates
👉 Read Corgea's analysis of the Laravel-Lang tag rewrite supply chain attack →
Laravel-Lang tag rewrites: what they mean for Composer security?
Explore further
Git tag mutability is a governance failure, not a packaging detail. When a dependency manager trusts a version string that can later be repointed, the control plane for software integrity is weaker than most teams assume. Supply chain validation has to extend from package names to immutable source references and verified provenance. Practitioners should treat mutable tags as an identity and integrity problem, not just a dependency hygiene issue.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: How should organisations respond after a poisoned dependency update?
A: Containment should start by rebuilding affected hosts and runners from trusted images, then revoking and rotating any secret that the compromised execution context could reach. If the dependency resolved after the compromise window, treat the environment as exposed until provenance and lockfiles are independently verified.
👉 Read our full editorial: Laravel-Lang tag rewrite attack exposes composer autoload risk