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.
At a glance
What this is: Corgea reports a Laravel-Lang supply chain attack in which rewritten Git tags made trusted Composer versions resolve to malicious code that executed via autoload.files.
Why it matters: It matters because Composer version pinning does not protect teams if tag references move after release, and the execution path can turn dependency resolution into runtime compromise across apps, CI, and developer environments.
Context
Composer treats version strings as a trust signal, but that trust depends on the underlying tag remaining immutable. When tags are rewritten after publication, package managers can resolve the same version to different code, which turns dependency management into a governance problem as much as a build problem.
This incident sits squarely at the intersection of software supply chain security and non-human identity governance because the poisoned package harvested cloud tokens, CI credentials, SSH keys, and other machine secrets from the runtime context. The failure mode is not just malicious code in a package, but code execution through a dependency channel that many teams assume is already controlled.
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. That means lockfiles, update pipelines, and audit trails can all point to a trusted name while the underlying commit has changed, so provenance checks must validate the resolved source, not just the package version.
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. That gives malicious package code early access to environment variables, local files, and bootstrap credentials before the application has a chance to constrain execution.
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. Then review where secrets are stored, not just which package was compromised. If the same workstation holds cloud, SSH, and SaaS credentials, the incident response plan must cover all three identity domains.
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.
Technical breakdown
How rewritten tags defeat Composer pinning
Composer resolves constraints to tags and then fetches the code behind the tag reference. If a tag moves after publication, the same version string can point to different source without the package name changing. That is why a lockfile created before the rewrite is materially different from one regenerated after the rewrite. In this case, the trust boundary is the source reference itself, not just the package version. Practical implication: treat immutable source references and lockfile provenance as separate controls, because version pinning alone does not prove code integrity.
Practical implication: Validate resolved commit SHAs for dependency updates, not just version strings.
Why autoload.files turns a dependency into an execution primitive
Composer's autoload.files mechanism loads listed files as soon as vendor/autoload.php is included. That makes it fundamentally different from lazy class loading, because the file runs during bootstrap rather than when a specific class is called. In a Laravel or Symfony stack, that means the code can execute on web requests, worker startup, and CI jobs before application logic ever begins. The malicious helper file used this property to fetch a second stage and launch it in the background. Practical implication: any dependency that can place code in autoload.files deserves the same scrutiny as startup scripts or init containers.
Practical implication: Inspect autoload.files entries in third-party packages as executable startup paths.
Why the second stage mattered more than the first dropper
The first-stage helper function was only a loader. Its job was to retrieve a second-stage payload, write it to a temporary path, and execute it with minimal traceability. Public reporting says the second stage targeted cloud credentials, CI/CD secrets, SSH material, container tokens, and other secrets from the local environment. That is the real governance risk: a single package execution context can expose many non-human identities at once because build and runtime systems often co-reside with privileged credentials. Practical implication: assume package-executed code can enumerate the entire local secret estate unless isolation is explicit.
Practical implication: Segment build, test, and runtime credentials so package code cannot reach the full secret estate.
Threat narrative
Attacker objective: The objective was to harvest high-value machine and developer secrets from environments that trusted a rewritten dependency reference.
- Entry occurred when attackers rewrote trusted Laravel-Lang Git tags so Composer would resolve the same version strings to poisoned artifacts.
- Credential access began when the injected autoloaded helper fetched and executed a second-stage payload from an external host.
- Exfiltration followed as the payload targeted cloud credentials, CI secrets, SSH keys, Vault tokens, kubeconfig material, and developer-side secret stores.
- Impact was broad runtime compromise because the malicious code executed whenever vendor/autoload.php was loaded in application, CI, and developer workflows.
Breaches seen in the wild
- Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.
- Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Autoload execution turns package risk into identity risk: once a package can run during vendor/autoload.php, it can reach the credentials attached to the local bootstrap context. That makes CI tokens, cloud keys, SSH material, and Vault access part of the same exposure surface. The right mental model is machine identity concentration, not simply dependency compromise.
Secret sprawl becomes immediately exploitable when execution is early: the payload targeted many secret stores because modern build and developer systems accumulate credentials faster than they segment them. This is a classic non-human identity problem: many secrets, many paths, weak blast-radius controls. The practical conclusion is that provenance and runtime secret scoping have to be designed together.
Rewritten-tag attacks are a supply chain pattern, not a one-off package event: the same failure mode can recur anywhere registries trust mutable references more than immutable content. That means teams need to assume package ecosystems can be manipulated after publication and design controls around verified source state, not nominal version numbers. Security teams should elevate immutable artifact trust to a first-class policy.
Composer autoload misuse creates a named concept worth tracking: dependency bootstrap execution. This is the point where a package stops being passive code and becomes part of the application's startup path. Once that boundary is crossed, secret exposure and code execution risk rise together, and practitioners need runtime controls that assume bootstrap can be hostile.
What this signals
Dependency bootstrap execution is a useful lens for this incident: once a package can run during application startup, it effectively sits inside the same trust boundary as the application runtime. That means supply chain controls have to cover both artifact provenance and the secret exposure created by bootstrap timing.
The broader lesson for IAM and NHI teams is that credential governance cannot stop at the identity provider. Any environment that lets package code touch cloud keys, CI tokens, SSH material, or Vault access has already collapsed the separation between software delivery and secret custody, so blast-radius controls need to exist before the build starts.
For practitioners
- 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.
- Rebuild from trusted images and clean dependencies Recreate affected hosts, containers, and runners from known-good images after removing the compromised packages and confirming clean tag state.
- Add egress controls for package-executed code Block the reported malicious domain at DNS, proxy, and runner egress layers so any future package-level bootstrap execution cannot reach external payloads.
Key takeaways
- Rewritten package tags can defeat Composer pinning by changing what a trusted version string resolves to after publication.
- Composer autoload.files is a runtime execution path, so malicious package code can run at bootstrap across apps, workers, and CI jobs.
- The practical control gap is not only supply chain provenance but also the exposure of cloud, CI, and SSH secrets inside build and developer environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The payload was designed to harvest secrets from affected environments. |
| NHI-07 — Long-Lived Secrets | The attack monetised long-lived cloud, CI, and SSH secrets present in local environments. | |
| NHI-04 — Insecure Authentication | The incident abused trust in package resolution and bootstrap authentication paths. | |
| Recommendation — Scan build and runtime environments for exposed NHI secrets and revoke any that were reachable during execution. Reduce the lifetime of machine secrets so package-executed code cannot reuse them broadly. Verify identity and provenance for package sources before allowing them to execute in bootstrap contexts. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack chain centered on secret harvesting and outbound collection of stolen data. |
| Recommendation — Map dependency execution to credential access and exfiltration tactics in detection and response workflows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are directly implicated by the secret-stealing payload. |
| Recommendation — Apply authenticator lifecycle controls to rotate any credentials exposed to package-executed code. | ||
Key terms
- autoload.files: A Composer manifest field that loads specified files immediately when vendor/autoload.php is executed. Because the files run during bootstrap rather than on demand, any malicious code placed there can act before normal application logic or user-facing controls begin.
- Tag rewrite attack: A supply chain attack in which an attacker moves a repository tag after publication so the same version label resolves to different code. The version name appears familiar, but the underlying commit has changed, which breaks provenance assumptions and can redirect trusted updates to malicious artifacts.
- Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
- Bootstrap execution: Code that runs during application startup rather than after the application is fully initialised. Bootstrap execution is high risk because it can access environment variables, local files, and injected credentials before normal application logic or user interaction begins.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect machine identity control to the broader security programme.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org