Laravel-Lang package compromise shows how supply chain malware steals secrets

At a glance

What this is: Aikido says a Laravel-Lang supply chain attack turned trusted package updates into malware delivery and secret theft across cloud, developer, and browser credential stores.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat package trust, token exposure, and secrets governance as one attack surface rather than separate problems.

By the numbers:

• The attack compromised 233 package versions across the Laravel-Lang ecosystem.
• The stealer targeted credentials from 17 Chromium-based browsers.

Context

Laravel package trust depends on provenance, not just repository visibility. In this case the attacker used tags pointing to commits in a malicious fork, so a normal install path became a delivery channel for credential-stealing code. For identity and secrets governance, the important point is that build and dependency systems can become an entry point for NHI compromise even when the official source tree looks unchanged.

The broader governance gap is secrets sprawl. The payload went after cloud tokens, SSH keys, vault tokens, browser logins, and local auth material because those credentials are often scattered across developer devices, build runners, and configuration files. That makes the incident a cross-domain problem, but the identity angle is real: machine credentials were the prize, and package trust was the route in.

Key questions

Q: What breaks when a malicious package runs during dependency installation?

A: The main failure is that installation becomes code execution inside a trusted environment. If that environment can see tokens, keys, or cloud credentials, the attacker does not need a separate exploit. The package can steal secrets, modify local state, and create a path into connected systems before defenders notice. Package trust must therefore be treated as an access-control issue, not just a software integrity issue.

Q: Why do stolen developer secrets create such broad compromise risk?

A: Because those secrets often unlock both human-admin and machine-automation paths. A single token or key can be enough to move from one workstation into code repositories, cloud resources, or deployment pipelines. The risk is amplified when secrets are reused across environments or granted more privilege than the original task requires.

Q: What do security teams get wrong about developer and CI secrets?

A: They often treat these secrets as operational conveniences instead of high-value identities. In practice, developer laptops and CI runners are rich credential stores, and tokens that remain valid for long periods are ideal for republishing, impersonation, and downstream access. Secrets should be governed like privileged access, not cache data.

Q: How should organisations respond when supply-chain malware reaches machine identities?

A: Treat it as an identity incident, not only a malware event. Revoke exposed tokens, rotate any shared or long-lived secrets, check cloud and CI/CD logs for follow-on access, and review whether package trust controls allowed code to execute too early. The goal is to close the credential path before it becomes broader compromise.

Technical breakdown

How malicious package tags bypass repository trust

The attacker did not need to alter the official Laravel-Lang repositories. Instead, version tags were pointed at commits in a malicious fork, which meant package consumers pulled code that looked legitimate from the outside but was controlled elsewhere. Composer then loaded the malicious helper automatically through its autoloader, so code execution occurred as part of normal dependency resolution. This is a provenance failure, not just a malware delivery trick: the trust decision happened at install time, while the payload was embedded in a package update path that many teams assume is routine and safe.

Practical implication: verify package provenance and tag integrity before install, not after execution.

Why the dropper was built to evade static detection

The dropper used a harmless-looking helper file, self-executing logic, host fingerprinting, runtime-decoded infrastructure, and SSL-verification-disabled fetches to hide its behaviour. Those techniques reduce the chance that static scanning or simple string matching will catch the malicious path. The code also wrote a marker file so it would only execute once on a given host, which limits noise and can delay detection. In identity terms, that means the first meaningful control point is not the endpoint after theft begins, but the supply chain and install workflow before code is trusted.

Practical implication: inspect dependency behaviour and install-time execution paths, not just file signatures.

How the stealer turns developer endpoints into credential reservoirs

The payload was a multi-module PHP stealer that harvested cloud credentials, infrastructure secrets, browser passwords, SSH keys, package manager tokens, and local wallet files before encrypting and exfiltrating the results. That breadth matters because modern development endpoints are densely packed with reusable identity material, including machine tokens and service credentials that can outlive a single session. Once captured, those secrets can unlock cloud control planes, source repositories, and CI/CD systems. The result is not just local compromise but identity expansion across the environment through reused and long-lived credentials.

Practical implication: shrink the credential reservoir on developer machines and build hosts before a stealer can enumerate it.

Threat narrative

Attacker objective: The attacker wanted reusable credentials and tokens that could be converted into broader access across cloud, development, and collaboration environments.

1. Entry began with malicious package tags that pointed Composer installs to code in a forked repository controlled by the attacker.
2. Credential access followed when the dropper executed automatically and fetched a larger stealer designed to harvest cloud, SSH, browser, and vault secrets.
3. Impact came from exfiltration of reusable credentials that could be used to access cloud services, developer platforms, and internal systems beyond the infected host.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• 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.

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

Package provenance has become an identity control, not just a software integrity issue. When installers trust tags, forks, and dependency metadata too easily, they also trust the identity material those packages can reach at runtime. That means secrets governance now depends on verifying what code is allowed to execute during install and what credentials that code can touch. Practitioners should treat provenance checks as part of machine-identity governance, not a separate supply-chain checklist.

Secrets sprawl is the real blast-radius multiplier. The malware succeeded because cloud tokens, SSH keys, browser passwords, and vault files were already distributed across endpoints and workflows. This is the same failure mode that OWASP-NHI calls out in secret leakage and long-lived secrets: compromise one place, inherit many others. Teams should assume that any stolen developer secret may become a lateral-movement credential unless its scope and lifetime are tightly constrained.

Composer-style dependency execution collapses delivery and execution into one trust decision. That is why package compromise can outpace endpoint detection, especially when payloads run at install time and then self-delete. The specific governance gap here is the assumption that installation is a passive activity. It is not, and practitioners should treat dependency resolution as an execution boundary that deserves policy, telemetry, and approval.

Credential theft from developer workstations now maps directly to cloud risk. The article shows how a local stealer can harvest tokens that authenticate to cloud services, CI/CD platforms, and third-party SaaS. Once those identities are exposed, the problem shifts from endpoint containment to access governance across the wider estate. The practical conclusion is simple: if your software supply chain can reach secrets, your identity controls have already been drawn into the incident.

Supply-chain malware and NHI governance are converging on the same control gap. The decisive weakness is not just malicious code, but the lack of strong separation between package trust and credential authority. That makes the case for tighter workload identity, shorter token lifetimes, and stricter offboarding of machine secrets. Teams that still treat package installs, browser logins, and cloud tokens as unrelated controls will keep missing the combined attack path.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secrets sprawl is now a supply-chain problem, not just a hygiene problem. When package installs can deliver code that enumerates cloud tokens, SSH keys, and browser logins, the control boundary shifts from endpoint hardening to identity containment. The practical lesson is that reusable credentials sitting on developer systems create a single failure domain for both malware and account takeover.

Provenance checks need to sit in front of execution, not behind it. This incident shows why tag integrity, fork awareness, and install-time inspection matter for build pipelines that touch production secrets. If the dependency can run before policy sees it, the policy is too late.

Supply-chain attacks continue to target the credential layer because it offers the highest downstream leverage. Aikido's analysis shows how one compromised package can reach cloud, CI/CD, and browser-based identity stores through ordinary development workflows. Teams should expect that package compromise will keep converging with NHI governance gaps unless secret scope and lifetime are reduced.

For practitioners

• Audit dependency install-time execution Review package managers, build scripts, and autoloaders for code that executes during installation, and block packages that fetch or run external payloads before approval.
• Reduce secrets on developer endpoints Remove reusable cloud tokens, vault files, and static credentials from laptops and build runners wherever possible, and keep only short-lived credentials in scoped workflows.
• Verify package provenance and tag integrity Require provenance checks for dependency sources, including tag-to-commit validation and fork awareness, before packages are accepted into build pipelines.
• Harden browser and CLI credential storage Treat browser password stores, CLI auth caches, and local config files as high-value secret stores, and monitor for unauthorised access or bulk enumeration.
• Segment cloud and developer identity authority Separate day-to-day developer access from cloud administration and service credentials so that a stolen workstation secret cannot immediately reach production control planes.

Key takeaways

• The Laravel-Lang compromise shows that package trust and secrets governance can fail as one combined attack path.
• The malware focused on high-value identity material such as cloud tokens, SSH keys, browser passwords, and vault files.
• Defensive value comes from provenance checks, shorter-lived credentials, and removing reusable secrets from developer endpoints.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.

Deepen your knowledge

NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through structured practitioner training, including the industry's only accredited NHI security programme. It helps security and identity teams build a common control model for machine credentials and their lifecycle.