AMSTERDAM, 22 MAY 2026 — Security researchers disclosed on Thursday a coordinated supply-chain attack against the Laravel-Lang package family that compromised 233 package versions across more than 700 GitHub repositories, exploiting a subtle property of Composer's autoloader and GitHub's version-tag handling to deliver a 5,900-line PHP credential stealer to any project that pulled an affected package between 9 and 22 May 2026.

Key Takeaways

  • The attack rewrote version tags across four widely-used Laravel-Lang repositories — Laravel-Lang/lang, Laravel-Lang/http-statuses, Laravel-Lang/attributes, and Laravel-Lang/actions — to point to malicious commits in a forked repository the attacker controlled.
  • 233 package versions across 700+ GitHub repositories were affected. The legitimate source repository was never modified; only the version tags were repointed.
  • The payload is a 5,900-line PHP credential stealer with 15 specialist collector modules, designed to harvest cloud keys, infrastructure config, developer assets, browser passwords, and cryptocurrency wallets.
  • Exfiltration target: flipboxstudio[.]info/exfil. Data is AES-256 encrypted before transmission to evade content-inspection defences.
  • Packagist responded by taking down malicious versions and temporarily unlisting affected packages. Composer users who installed during the window of compromise must re-run composer install --update-with-dependencies after the patch and rotate exposed credentials.

The Facts

The compromise was first reported in detail by Aikido on 22 May 2026 after the firm's package-monitoring infrastructure flagged a pattern of unusual version tags appearing across the Laravel-Lang organisation on GitHub. Within hours, The Hacker News, Socket, and Cybersecurity News confirmed the breadth of the campaign.

The mechanism is what makes this attack distinct from the more familiar pattern of compromised maintainer accounts. The attacker did not commit malicious code to the official Laravel-Lang repositories. Instead, the attacker exploited a property of GitHub's version-tag handling: a tag can point to a commit that lives in a fork of the same repository, not necessarily in the upstream repository itself. When the attacker pushed new version tags to Laravel-Lang/lang and the sibling repositories, those tags pointed to commits in an attacker-controlled fork.

Composer — the PHP dependency manager that Laravel and the broader PHP ecosystem rely on — resolves package versions by tag name. When a user runs composer install or composer update, Composer queries the package registry (Packagist) for the latest matching version, then pulls the code at the corresponding Git tag. Packagist's automatic mirror of GitHub tags propagated the malicious version pointers directly to PHP developers worldwide.

The malicious code lives in a register.php file that runs at composer autoload time. The Laravel-Lang packages use Composer's files autoload directive to pre-register language files when the package is installed; the attacker injected the credential-stealing code into one of those autoload-triggered files. As a result, the malicious code executes the first time any Laravel application boots after pulling an affected Laravel-Lang version — including during php artisan commands, web requests, queue worker startup, and scheduler ticks. No exploit, no user interaction; the autoload mechanism itself is the trigger.

Cybersecurity News confirmed that 233 package versions and 700+ GitHub repositories were affected. The version-tag rewriting touched multiple historical version lines simultaneously, meaning users who pinned to older "safe" Laravel-Lang versions could still receive the malicious payload if their composer.lock file allowed for tag re-resolution.

Packagist responded immediately by taking down the malicious versions and temporarily unlisting the affected packages from the registry. Laravel-Lang maintainers issued an advisory and committed to multi-factor authentication enforcement on the organisation's GitHub credentials.

Technical Deep-Dive

The 5,900-line PHP payload is unusually engineering-grade for malware delivered through a supply-chain attack. It is organised into 15 specialist collector modules, each targeting a specific data class:

  1. Cloud access keys: AWS access key ID/secret access key pairs found in ~/.aws/credentials, environment variables, and common config-file locations. Same logic for GCP service account JSON keys, Azure CLI tokens, and DigitalOcean API tokens.
  2. Container and orchestration: Kubernetes config files (~/.kube/config), Docker Hub login tokens stored in ~/.docker/config.json, container registry credentials.
  3. Infrastructure-as-code: HashiCorp Vault tokens, Terraform Cloud API keys, Pulumi state-backend credentials.
  4. Developer assets: SSH private keys in ~/.ssh/, Git credential helpers, GitHub PATs in environment variables.
  5. Shell history: .bash_history, .zsh_history, .psql_history — frequently leaks credentials accidentally typed in command-line arguments.
  6. Browser credentials: Chrome, Firefox, Edge, and Brave password stores when accessible on the host running the PHP process.
  7. Cryptocurrency wallets: Local keystore files for Ethereum (Geth, Hardhat), Solana CLI, Bitcoin Core, MetaMask browser extensions.
  8. Password managers: Bitwarden CLI configuration, 1Password CLI tokens, KeePass database paths.
  9. Application secrets: .env files (Laravel-Lang's prime target audience), composer.json auth sections, npm .npmrc files.
  10. Database credentials: MySQL, PostgreSQL, Redis, MongoDB connection strings parsed from common Laravel config paths.
  11. Email and messaging: SMTP credentials, Mailgun/SendGrid API keys, Slack webhooks, Discord bot tokens.
  12. Payment provider keys: Stripe secret keys, PayPal credentials, Square API tokens — high direct monetisation value.
  13. CI/CD tokens: GitHub Actions tokens, GitLab pipeline credentials, CircleCI API keys.
  14. Mobile development: Apple Developer p8 keys, Android signing keystores, Firebase service accounts.
  15. Catch-all: Recursive scan of project directories for files matching credential-pattern regexes (-----BEGIN PRIVATE KEY-----, sk_live_, xoxb-, etc.)

After collecting, the payload AES-256 encrypts the bundle using a public key embedded in the malware, then POSTs the encrypted blob to flipboxstudio[.]info/exfil. The encryption is a defence-evasion measure: content-inspection systems looking for plaintext credentials in egress traffic see only the AES ciphertext.

The cross-platform aspect of the payload deserves attention. PHP runs on Linux, macOS, and Windows; the collector modules detect the host operating system and adjust file paths accordingly. Linux-specific paths (~/.bashrc), macOS-specific paths (~/Library/Application Support/), and Windows-specific paths (%APPDATA%, %LOCALAPPDATA%) are all handled. A developer running php artisan serve on a macOS laptop, a Docker-based CI runner on Linux, and a Windows production IIS server are all exposed.

The mechanism is, in retrospect, a known weakness in Composer + Packagist that has been discussed in security research circles for at least four years. The attack realises the theoretical risk in production scale.

ASEAN Perspective

Laravel is one of the most popular web framework ecosystems in Southeast Asia, with strong adoption in government digital services, fintech, e-commerce, and the broader SME software market. The Laravel-Lang packages specifically are used for internationalisation — adding non-English language support to Laravel applications — making them especially common in ASEAN deployments where multi-language UI is the default rather than the exception.

Indonesia has one of the largest Laravel developer communities in the world by per-capita measure. Indonesian e-commerce platforms, government portals, and fintech applications routinely include Laravel-Lang/lang and related packages to support Bahasa Indonesia, English, and regional dialects in a single codebase. Indonesian Laravel developers should treat this advisory as urgent: any production system that ran composer install or composer update between 9 and 22 May 2026 needs immediate audit.

Singapore's fintech sector has a notable Laravel deployment footprint, particularly among the smaller fintech firms that build customer-facing applications outside the dominant Java/Spring stacks of the major banks. Singapore's Cyber Security Agency advisory on supply-chain risks from earlier this year explicitly called out package-ecosystem attacks. Laravel-Lang fits that warning exactly.

Malaysia is similar to Singapore in deployment profile: smaller fintech firms, government digital services projects, and a growing SaaS ecosystem all rely on Laravel. The Malaysian Cyber Security Agency (CSM) typically follows CSA Singapore's lead on advisory timing; expect a regional advisory within 7 days.

Vietnam has an exceptionally large Laravel development sector driven by software outsourcing for European and US clients. Vietnamese outsourcing firms typically manage multiple client codebases through shared CI/CD infrastructure; a Laravel-Lang compromise in one client's pipeline can leak credentials from neighbouring clients' environments. Vietnamese CTOs should immediately audit any environment that ran Composer between 9 and 22 May.

Philippines and Thailand have smaller absolute Laravel footprints but the proportional impact is similar. Filipino back-office software firms and Thai e-commerce platforms are both common Laravel users. The advisory should be treated as immediate priority for any team that has not yet completed remediation.

For RECATOOLS readers building Laravel applications themselves: this is the closest-to-home supply-chain attack we have covered. The mitigation is the same as for any team — audit installs, rotate credentials, lock composer.lock — but the operational relevance is direct.

What Organisations Should Do

The remediation checklist for Laravel teams is concrete and time-sensitive:

  1. Identify whether you installed any affected Laravel-Lang version between 9 and 22 May 2026. Run composer show laravel-lang/* against your production composer.lock files. Cross-reference the installed versions against the IOC list in the Aikido and Socket advisories. If any match, treat the environment as compromised pending full audit.

  2. Block outbound connections to flipboxstudio[.]info at the network layer. The exfiltration domain is the known C2; blocking is a low-risk, high-value action that should be applied immediately to all production and CI infrastructure.

  3. Search application logs for autoload errors or unexpected outbound HTTP from PHP processes. The malicious code may have triggered visible errors in some environments (PHP warnings about missing functions or undefined constants). Application-level error logs from 9 May onward should be reviewed.

  4. Rotate all credentials accessible from affected environments. This is the painful, expensive, necessary step. Rotation must include cloud access keys, database passwords, SSH private keys, API tokens for third-party services, encryption keys stored in .env files, and session/cookie signing keys. Treat any credential reachable from a Composer-managed Laravel application as potentially compromised.

  5. Re-install affected packages from clean versions and lock composer.lock. After Packagist republishes safe versions, run composer install --no-cache --update-with-dependencies to pull clean code, then commit the updated composer.lock. Do not skip the --no-cache flag — local Composer caches may contain the malicious payload.

  6. Add Composer's secure-http and disable-tls audits to your routine. Enable Composer's signature verification where the package supports it. Pin to specific commit SHAs rather than version tags for high-value dependencies (composer.json supports both syntaxes).

  7. Adopt package-firewall tooling. Socket, Aikido, Sonatype, and Snyk all offer package-firewall services that quarantine new package versions until automated analysis confirms safety. For mid-sized and large Laravel teams, the cost of a package firewall is significantly lower than the cost of one supply-chain compromise.

RECATOOLS Verdict

We believe the Laravel-Lang attack is the most consequential PHP-ecosystem supply-chain attack since the Composer Cache Poisoning research demonstrations of 2020, and the first to inflict broad operational impact at production scale.

The technique is elegant in a way that should worry every PHP developer. The legitimate repositories were never modified. The maintainers' credentials were not exfiltrated. The package was hosted on the official registry with the official maintainers' authorship. The only thing the attacker did was push tags that pointed to commits in a fork — and Composer followed those tags because that is what Composer is designed to do. There is no obvious technical defence that does not also break legitimate use cases (Composer needs to follow tags; users need to be able to install pinned versions; forks are a core git primitive).

The cleanest fix is structural: Composer and Packagist should refuse to resolve a version tag that points to a commit outside the official repository's commit graph, by default. This is the same change npm made after the event-stream incident of 2018, and the same change PyPI made for its trusted-publishers programme. PHP's package ecosystem has been overdue for the same hardening.

For Laravel teams in ASEAN, we recommend three structural changes regardless of whether you were directly affected by this incident:

  1. Move to commit-pinned dependencies for security-critical packages. Composer supports this syntax; most teams do not use it. The trade-off is more manual update work in exchange for protection against version-tag manipulation. For a security-conscious team, the trade is correct.
  2. Adopt a package firewall. The economics of the trade-off — a few hundred dollars per month of tooling against the existential cost of a supply-chain breach — have shifted decisively in favour of the tooling.
  3. Run periodic credential rotation as a routine practice, not an emergency response. Most ASEAN teams treat credential rotation as something done after an incident. The new normal should be quarterly rotation of all production credentials, automated where possible. When the next supply-chain attack lands, the blast radius shrinks dramatically.

The Laravel framework itself is not at fault here. Laravel is one of the best-engineered web frameworks on any language stack. The vulnerability is in the package distribution layer — a layer Laravel inherits from PHP — and the fix has to come from Composer, Packagist, and the broader PHP packaging community.

Frequently Asked Questions

Was the official Laravel-Lang repository compromised? No. The legitimate Laravel-Lang/lang repository and its sibling repositories were never modified at the source level. The attacker rewrote version tags so that the tags pointed to commits in a fork they controlled. From Composer's perspective the tags resolved to malicious code, but the official repository's main branch and contributor history are clean.

How do I know if my application is compromised? Check composer.lock for any laravel-lang/* package installed between 9 May and 22 May 2026. Cross-reference the installed version against the indicator-of-compromise lists from Aikido, Socket, or Cybersecurity News. If your environment has reached out to flipboxstudio[.]info during that window — visible in DNS, firewall, or egress proxy logs — treat the environment as compromised.

Should I uninstall Laravel-Lang entirely? No. Laravel-Lang is a high-quality package family that provides essential internationalisation features. The right response is to pull the patched versions once Packagist republishes them, not to remove the dependency. If you are unable to identify whether you pulled an affected version, treating the environment as compromised and rotating credentials is the correct action — but uninstalling Laravel-Lang going forward does not fix the historical compromise.

Are non-Laravel PHP projects affected? The specific packages affected are part of the Laravel-Lang family and primarily used in Laravel projects. However, non-Laravel PHP projects that depend on any of the affected packages (uncommon but not impossible) inherit the same exposure. Run composer show on your composer.lock to confirm.

Could this happen to npm, PyPI, or Crates.io? The version-tag manipulation technique is specific to Composer's resolution model. Npm follows a different model (packages are uploaded to the registry, not pulled from Git tags). PyPI similarly stores package files directly. Crates.io has its own model. Each ecosystem has its own supply-chain attack surface — npm has dependency confusion, PyPI has typosquatting, Crates.io has had similar issues — but the specific Laravel-Lang technique does not directly translate. The structural lesson — that supply-chain trust assumptions are fragile — applies to every package ecosystem.