Laravel-Lang tag rewrite attack exposes composer autoload risk

At a glance

What this is: This is a supply chain attack on Laravel-Lang packages where rewritten Git tags and Composer autoloading combined to deliver a backdoor through trusted dependency updates.

Why it matters: It matters because build systems and CI runners often treat dependency resolution as safe, yet a single poisoned tag can turn routine updates into code execution across developer and runtime environments.

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.
• 17 minutes.

👉 Read Corgea's analysis of the Laravel-Lang tag rewrite supply chain attack

Context

Composer supply chain risk is not limited to direct package compromise. When a build system resolves a trusted version string from a tag that can later be moved, the dependency boundary becomes mutable and the release process no longer guarantees code integrity. This article is about that governance gap, with a clear identity-security intersection because the attack turns secrets, service accounts, and CI credentials into the real downstream target.

The Laravel-Lang projects were not Laravel core, but they were widely consumed localization dependencies in Laravel applications and build pipelines. That makes the incident typical of modern dependency risk: the entry point is a package reference, but the operational damage lands in developer workstations, CI runners, and runtime environments where non-human identities and secrets already exist.

Key questions

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. If tags are mutable, a trusted dependency can become a different artifact after the fact, which means ordinary updates can deliver unreviewed code. Teams should verify immutable commit SHAs and artifact hashes, not rely on tag names alone.

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. Those secrets often have broader access than the package itself, so the attacker gains identity reach, not just code execution.

Q: What do teams get wrong about Composer autoloading risk?

A: They often treat autoload metadata as packaging detail rather than executable trust boundary. Files listed in autoload.files run during bootstrap, which means dependency loading can trigger network access, payload fetches, and secret discovery before normal application controls fully engage.

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.

Technical breakdown

How rewritten Git tags bypass Composer trust assumptions

Composer resolves constraints to tags, not just to package names. If a tag is moved after publication, a later install or update can resolve the same version string to different code. That means a lockfile generated before the rewrite may remain safe, while a regenerated lockfile after the rewrite can preserve the malicious commit. The risk is not branch membership. A poisoned tag can point at a commit GitHub shows as detached from the default branch, yet Packagist still exposes it as a valid version.

Practical implication: verify resolved source commit SHAs in composer.lock, not only package names or version strings.

Why autoload.files turns a dependency into an execution primitive

Composer autoloading has two broad patterns: PSR-4 loads classes on demand, while autoload.files includes files immediately when vendor/autoload.php is loaded. That makes autoload.files an execution primitive, because any code in the referenced file runs during application bootstrap. In this case the malicious helpers file fetched a second stage, wrote it to a temporary path, and executed it in the background. The load path is the payload path, which is why application startup became the trigger.

Practical implication: review autoload.files entries as code execution surfaces, not as harmless packaging metadata.

Why the second stage targeted secrets and non-human identities

The reported payload went well beyond a narrow application compromise. It searched for cloud credentials, Kubernetes service account tokens, Vault tokens, CI/CD secrets, SSH keys, browser stores, and auth files that often belong to non-human identities. That breadth matters because once the dropper runs in a developer or CI context, the valuable asset is not the package itself but the credential estate attached to the environment. This is a classic secrets-to-access chain, now delivered through a package update path.

Practical implication: treat build and runner secrets as high-risk NHI assets and rotate them after any suspicious dependency execution.

Threat narrative

Attacker objective: The attacker’s objective was to turn a trusted dependency update into broad secret theft and downstream access to cloud, CI, and developer environments.

1. Entry occurred when attackers rewrote trusted Laravel-Lang Git tags so Composer could resolve poisoned artifacts through ordinary dependency updates.
2. Credential harvesting followed when the malicious payload executed via autoload.files and searched the host for cloud keys, CI tokens, SSH keys, and other secrets.
3. Impact came from using those secrets to expand access across developer, CI, cloud, and container environments while deleting local traces from disk.

Breaches seen in the wild

• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

autoload.files creates a hidden execution boundary inside the build chain. Many teams inspect application code but not package bootstrap paths, which leaves a blind spot for code that runs before business logic ever starts. The important question is not whether the package looks benign, but whether it can execute at bootstrap time. Practitioners should audit every dependency that can run before the first request, job, or pipeline step completes.

Secrets exposed in CI and developer tooling are non-human identities with blast radius. The payload’s target list shows that attackers are not hunting only for one environment variable. They are harvesting the credential fabric of the delivery pipeline, including service accounts, tokens, keys, and cloud CLI caches. That is a direct NHI governance issue because those credentials often lack lifecycle controls, ownership clarity, and rapid revocation paths. Practitioners should inventory secrets as identities, not just as configuration.

Package compromise now sits inside the same risk envelope as agentic code execution. Any system that can fetch and execute remote code during bootstrap behaves like a delegated runtime, which means the trust model must account for what the code can decide to load next. This aligns with OWASP NHI Top 10 thinking around credential exposure and execution trust, and with MITRE ATT&CK techniques for initial access, credential access, and exfiltration. Practitioners should align dependency policy with runtime trust decisions.

Immutable release verification is the named concept teams should adopt. This attack worked because teams implicitly assumed that a released tag stayed bound to the same code forever. Once that assumption collapses, the only stable control is verification of the exact commit, artifact hash, and provenance chain before execution. Practitioners should build release gates around immutable verification, not around semantic version labels.

From our research:

• 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.
• From our research: The Ultimate Guide to NHIs , Static vs Dynamic Secrets shows why long-lived credentials fail under runtime abuse, which is exactly the pattern this incident exposes.

What this signals

Dependency compromise is now a secrets governance event as much as a software integrity event. For teams running CI, container builds, and developer tooling, the practical signal is that any package capable of bootstrap execution can become an access broker for non-human identities, so secret inventories and revocation paths need to sit beside dependency controls.

Immutable release verification: package security programmes should treat commit pinning, provenance checks, and bootstrapped file review as one control family, not three separate tasks. The control objective is to make runtime execution dependent on an independently verified artifact, not on a mutable version label. For identity teams, that means aligning NHI lifecycle controls with software delivery trust boundaries.

The attack also shows why secret exposure monitoring needs to start earlier in the delivery chain. If a dependency can reach CI tokens, cloud keys, or SSH material during bootstrap, then the highest-value detection point is not only the production workload, but the build and runner estate where those identities first appear.

For practitioners

• 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.

Key takeaways

• This incident turned mutable package tags and eager autoloading into a practical code execution path, which makes dependency trust a runtime security issue.
• The scale of the compromise mattered because the payload targeted cloud keys, CI secrets, Kubernetes tokens, and other non-human identities rather than one application secret.
• The control that changes the outcome is immutable verification of source references, plus rapid secret rotation for every identity reachable from the compromised execution context.

Key terms

• Mutable Tag Risk: A weakness that appears when a version tag can be moved to a different commit after consumers have already trusted it. In supply chain terms, the tag is treated like a fixed reference even though the underlying code can change, which undermines reproducibility and provenance.
• 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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Poisoned Artifact: A software package, build output, or dependency reference that has been altered so consumers receive malicious or untrusted code while believing they are installing a legitimate release. The danger is highest when the artifact is fetched automatically through normal update flows.

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

👉 Corgea's full report includes the compromise window, execution artefacts, and remediation steps for affected Composer environments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle control for practitioners managing modern access estates. It helps security teams translate identity risk into operational controls across human and non-human environments.