Laravel-Lang Composer Packages Hijacked via Git Tag Rewrite to Deploy Cross-Platform Credential Stealer

On May 22, 2026, at approximately 22:32 UTC, an attacker with push access to the Laravel-Lang GitHub organization rewrote every git tag across four widely used Composer packages. The packages are laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and laravel-lang/actions. The operation ran until roughly 00:00 UTC on May 23. laravel-lang/lang alone had 502 tags rewritten. Approximately 233 versions were tampered across three repositories. Socket reported up to 700 historical versions may have been affected.

What the Attacker Actually Did

This was not a new malicious version publish. The attacker pointed all existing git tags to commits in an attacker-controlled fork, exploiting a fundamental property of how Packagist resolves Composer dependencies: tags resolve to GitHub commits, and if those commits are rewritten, every install referencing a tag pulls the new code. No version number changed. No registry advisory existed. The package manager showed nothing unusual.

An injected helpers.php file was wired into the package's autoload.files manifest. Composer processes autoload.files entries automatically on every composer install, with no user prompt and no warning. The payload is a cross-platform credential stealer targeting Linux, macOS, and Windows. It harvests cloud provider keys, Kubernetes and Vault secrets, CI/CD tokens, SSH key material, browser-stored credentials, cryptocurrency wallet data, and .env files, then exfiltrates everything to an attacker-controlled endpoint. StepSecurity confirmed end-to-end exploitation in an isolated runner environment.

Any composer install or composer update run between May 22 22:32 UTC and May 23 00:00 UTC against any of these four packages executed the malicious payload. The blast radius is every build environment, developer machine, and CI/CD runner that touched these packages in that window.

Why Traditional Scanners Produced Zero Findings

No CVE was assigned. No NVD entry exists. Aikido Security and Snyk published advisories post-discovery, but there is no CVE identifier to query. Traditional SCA and SAST tools match installed packages against known vulnerability databases. When no CVE exists, those tools produce zero findings regardless of whether your build pipeline already exfiltrated your cloud credentials.

Several structural properties make this attack class invisible to standard tooling:

• Tag rewriting is not a version change. Your composer.lock shows a version string that existed before the attack. A diff against last week's lockfile may show nothing, depending on when you last ran an update.
• Packagist resolves the underlying commit on install. The version number is cosmetically unchanged; the commit SHA behind it is not.
• autoload.files injection executes arbitrary code at install time. It is a legitimate Composer feature used for bootstrap code, and no default scanner flags autoload.files entries as suspicious.
• Ephemeral CI/CD runners leave no disk artifact. The exfiltration completes before the runner is torn down. There is no post-run artifact to scan.

TRIS Scoring: Priority-One Without a CVSS Score

CVSS is not applicable here. No CVE means no CVSS score. CVEasy AI's TRIS (Threat and Risk Intelligence Scoring) engine scores exposure across multiple intelligence layers beyond raw severity. For this event, three TRIS layers drive the score to the top of the queue.

Active exploitation. Confirmed. StepSecurity reproduced the full exploit chain in an isolated runner. This is not a theoretical risk; it is a documented, working attack against a real package ecosystem.

Blast radius. Extremely high for any PHP project running these packages in CI/CD. The payload targets cloud credentials, Vault tokens, SSH keys, and .env files. A single compromised build runner with AWS credentials or a Kubernetes service account token represents a direct lateral movement path into production infrastructure.

Real exposure beyond raw severity. Organizations running composer install in CI/CD with access to production secret managers, code-signing infrastructure, or cloud IAM roles are in the highest-risk tier. A development laptop install is serious. A CI runner with cloud keys is critical.

The absence of a CVSS score does not reduce the priority. TRIS weighs active exploitation, blast radius, and real exposure independently of CVE database coverage, which is precisely the gap this attack exploits in every other tool in the market.

Remediation Steps

1. Audit CI/CD logs first. Identify every composer install or composer update run that touched laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, or laravel-lang/actions during May 22 2026 22:32 UTC through May 23 2026 00:00 UTC. That window defines your blast radius boundary.

2. Rotate all credentials accessible from affected environments. Do not wait for confirmed exfiltration evidence. The payload ran. Rotate AWS, GCP, and Azure keys; GitHub Actions secrets; GitLab CI variables; CircleCI contexts; Kubernetes service account tokens; Vault tokens; SSH private keys; and any secrets in .env files accessible from the affected runner. Treat every secret as compromised.

3. Verify your lockfile commit SHAs. Compare the commit SHAs recorded in your composer.lock against the official laravel-lang GitHub repositories. GitHub removed the attacker-controlled fork commits after discovery and clean tags are now restored. If your lockfile was generated during the attack window, re-run composer install against the clean state and generate a new lockfile.

4. Review outbound network connections. Look for unusual POST requests from the runner process to unknown endpoints during or immediately after the attack window. Cloud provider network flow logs and SIEM detections on outbound data from build infrastructure are your primary signal sources.

5. Pin critical Composer dependencies to commit SHAs. Composer supports require with a specific git reference. Tags are mutable; commit SHAs are not. For critical packages, pinning to a verified SHA removes this entire attack vector. See BleepingComputer and Security Boulevard for full technical detail on the attack mechanics.

How CVEasy AI Surfaces This Without a CVE

No CVE means no NVD trigger. No NVD trigger means no alert in any scanner that depends on CVE feed ingestion. CVEasy AI, the number one local-first CTEM platform, ingests threat intelligence beyond NVD: package ecosystem compromise feeds, security research publications, and confirmed exploitation reports from sources including StepSecurity, Socket, and Aikido Security.

When CVEasy AI ingests a confirmed supply chain event, TRIS scores it against your environment's installed package inventory. If your environment includes any of the affected laravel-lang packages and you ran a Composer operation in the attack window, TRIS flags the event at the highest priority tier, generates a targeted remediation workflow focused on credential rotation rather than version patching, and surfaces it in your triage queue without waiting for a CVE number to be assigned.

Local-first architecture is not incidental here. Your Composer lockfiles, package inventories, and CI/CD pipeline metadata never leave your infrastructure. TRIS runs the analysis on your hardware. This event is a direct illustration of why supply chain exposure management requires more than CVE-feed ingestion: the most dangerous attacks are the ones that never get a number.

Sources: BleepingComputer, StepSecurity, Aikido Security, Socket, Snyk, The Hacker News, Security Boulevard