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

At a glance

What this is: A supply chain attack on Laravel-Lang used malicious version tags and autoloaded PHP code to steal secrets from developer, cloud, and browser environments.

Why it matters: It matters because identity and secrets governance now spans repositories, build pipelines, endpoints, and cloud accounts, so package trust failures can become credential compromise very quickly.

By the numbers:

• 233 versions are currently compromised across laravel-lang/lang, laravel-lang/attributes, and laravel-lang/http-statuses.

👉 Read Aikido's analysis of the Laravel-Lang supply chain attack and secret theft

Context

Supply chain attacks against package ecosystems bypass traditional application security assumptions because the code that enters the build is trusted before it is inspected. In this case, the primary problem is not a single vulnerable endpoint, but the abuse of repository trust and package execution paths that let attacker code run automatically during install.

For IAM and NHI teams, the identity question is which credentials are reachable from developer workstations, build runners, and package installs. When a malicious dependency can read cloud tokens, SSH keys, and secret files, secrets governance and software supply chain security become the same control problem rather than separate programmes.

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 cloud and NHI secrets make supply chain attacks more dangerous?

A: Because a single stolen token can open access to multiple environments, including cloud consoles, CI systems, and infrastructure tools. NHI secrets often have broader reach than a human session and may remain valid long after the initial compromise. That turns one infected workstation into a pivot point for wider account abuse.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: What should teams do in the first 24 to 72 hours after suspected package compromise?

A: Teams should isolate affected hosts, preserve forensic evidence, rotate exposed credentials, and inspect repositories for unauthorized workflow or package changes. They should also review internal mirrors and caches, because malicious versions may persist there after public removal. The goal is to stop reuse of stolen identities before the attacker expands access.

Technical breakdown

How malicious package tags bypass normal repository trust

The attacker exploited a GitHub behaviour where version tags can point to commits from a fork of the same repository. That means a package can appear to be a legitimate release even when the code never landed in the maintainer’s official repo. Composer then loads package code through its autoloader, so a malicious helper file can execute without any explicit import in the application code. This is a classic trust-chain failure: release metadata, not source history, becomes the attack surface. Practical implication: validate tag provenance and package origin before install, not after execution.

Practical implication: enforce provenance checks for package tags and block installs that do not match trusted release lineage.

Why the dropper was designed to evade static detection

The first-stage dropper used a normal-looking helper file, runtime-decoded C2 infrastructure, host fingerprinting, and SSL verification disabled on fetches. Those choices reduce the chance that scanners catch the package on name, string, or behaviour alone. The marker file also limits repeated execution, which helps the malware avoid noisy repeat activity that would trigger defenders. This is not sophisticated in the abstract, but it is effective because it blends into common PHP application patterns. Practical implication: inspect package behaviour in sandboxed execution, not just source diff review.

Practical implication: add behavioural scanning and sandbox execution to dependency review, not only code diff inspection.

How credential stealers turn developer access into enterprise exposure

The payload collected cloud access keys, session tokens, kubeconfig files, Vault tokens, browser credentials, password manager files, and shell history. That breadth matters because modern development environments concentrate identities, secrets, and administrative pathways in one place. Once the stealer can read local auth stores, it can move from a single infected workstation into cloud accounts, CI systems, and downstream services. This is where NHI governance becomes critical: exposed machine credentials often outlive the developer session that used them. Practical implication: reduce the value of any one stolen secret by tightening scope, TTL, and revocation pathways.

Practical implication: reduce the blast radius of stolen secrets with short-lived credentials, tight scopes, and fast revocation.

Threat narrative

Attacker objective: The attacker’s objective was to harvest reusable credentials and secrets at scale so they could pivot from package compromise into developer, cloud, and infrastructure environments.

1. Entry occurred through malicious version tags that pointed to attacker-controlled commits in a forked repository, allowing compromised package versions to be installed as if they were legitimate releases.
2. Credential access began when the autoloaded PHP dropper executed and fetched a second-stage stealer that harvested cloud tokens, SSH keys, browser credentials, vault files, and secret material from local files and caches.
3. Impact followed when stolen secrets were encrypted and exfiltrated to attacker infrastructure, creating a path from one compromised package to cloud, developer, and infrastructure account compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

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

NHI Mgmt Group analysis

Secrets sprawl has become the real supply chain surface. The Laravel-Lang incident shows that package compromise is no longer only about code integrity. When repositories, build tools, local auth stores, and cloud credentials all intersect, a malicious dependency can become an identity event as much as a malware event. Practitioners should treat secret-bearing environments as part of the trusted software supply chain, not as a separate endpoint problem.

Package provenance is now an access-control question. The attacker did not need to break the maintainer’s official repository when tag-to-fork mechanics were enough to create a believable release path. That means release trust depends on provenance validation, not just repository permissions. For identity teams, this is a reminder that non-human identities used in build and release pipelines need the same scrutiny as privileged human admin paths.

NHI secret exposure windows are the decisive failure mode. Once the stealer can read cloud keys, kubeconfigs, and service tokens, the issue is not just theft but how long those credentials remain usable. That is the governance gap this breach exposes. Organisations that cannot revoke, scope, and rotate machine credentials quickly will keep treating compromise as an endpoint incident when it is really an identity control failure.

Malware in dependencies is an operational resilience issue, not just a detection problem. The compromised versions touched widely used repositories, which means the blast radius extends into development velocity, release confidence, and downstream dependency hygiene. Security teams need a shared control plane for package intake, secrets scanning, and runtime validation. The practitioner conclusion is clear: dependency governance and identity governance now fail together.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• Forward-looking teams should use the Ultimate Guide to NHIs , Key Challenges and Risks to map where secret sprawl, over-privilege, and weak rotation intersect.

What this signals

Secrets governance now has to cover the software delivery path as well as the runtime estate. The practical signal from this attack is that dependency intake, build runners, and developer workstations are identity-bearing environments, not just engineering tools. Teams that cannot inventory which machine credentials are reachable in each stage will struggle to contain the next compromise. The relevant control conversation aligns with the OWASP Non-Human Identity Top 10 and the 52 NHI Breaches Analysis.

Secret exposure windows are the new response metric. If a stolen token remains valid for days, the attacker has time to pivot even when the original package is removed. Programmes should measure how quickly secrets can be invalidated across cloud, CI, and developer tools, because revocation speed is now a business-continuity issue as much as a security one.

Credential-bearing build systems need tighter governance than most organisations currently apply. The strongest predictor of downstream blast radius is not the malware sample itself but how many reusable identities the environment exposes to it. That is why NHI and IAM teams should be involved in software supply chain controls, especially where package installs can reach cloud metadata, secret stores, and release credentials.

For practitioners

• Validate package provenance before install Require provenance checks for package tags, forks, and release lineage in Composer workflows so malicious tags cannot masquerade as trusted versions. Block installs that do not match expected repository history and maintainer ownership.
• Restrict local credential exposure on developer hosts Move cloud tokens, SSH keys, and CI credentials out of long-lived local files where possible, and reduce the number of secrets reachable from developer workstations. Use short-lived credentials and tightly scoped access for build and release tasks.
• Scan for secrets in installed dependencies and runtime behaviour Run dependency and malware analysis in a sandbox that checks for autoload execution, hidden fetches, and access to auth stores, not just source code changes. Add alerts for packages that read .env files, kubeconfig paths, browser stores, or cloud metadata.
• Accelerate revocation for exposed machine credentials Create a response playbook that revokes cloud keys, Vault tokens, and package manager credentials as soon as malicious dependency activity is detected. Tie that playbook to ownership records so the right team can act without delay.

Key takeaways

• This attack turned a trusted package ecosystem into a secrets theft channel by abusing release provenance and autoloaded code.
• The breach matters because it reached cloud tokens, SSH keys, vault material, browser credentials, and other reusable identities at the same time.
• Containment depends on provenance validation, short-lived credentials, and fast revocation across developer and build environments.

Key terms

• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.
• Credential Stealer: A credential stealer is malware designed to collect reusable authentication material such as API keys, tokens, certificates, passwords, and session data. In modern environments it often targets developer workstations, build agents, browsers, and local configuration files because those systems concentrate secrets.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.
• Dependency Autoloading: Dependency autoloading is the mechanism that runs package code automatically when an application starts or installs components. It is convenient for developers, but it also creates a hidden execution path that malware can abuse if package trust is not tightly controlled.

What's in the full article

Aikido's full article covers the operational detail this post intentionally leaves for the source:

• The exact malicious package tags, repository paths, and indicators of compromise used in the Laravel-Lang campaign.
• The full 5,900-line credential stealer behaviour, including the collector modules and exfiltration workflow.
• The platform-specific detection guidance and rescan advice that apply to affected repositories and endpoints.
• The malicious domain and file-path markers that help teams hunt for infection in their own environments.

👉 Aikido's full post covers the attack chain, credential targets, and indicators of compromise.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to reduce credential exposure. It helps security teams connect identity control design to the operational realities of modern development and cloud environments.