Ninety minutes. That’s the window an attacker needed to rewrite over 230 package versions across one of PHP’s most widely used library sets and push a fully operational cloud credential stealer into enterprise CI/CD pipelines worldwide.
On 22–23 May, someone obtained push access to the Laravel-Lang GitHub organisation and rewrote git tags across four popular Composer packages (laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, laravel-lang/actions), redirecting them to malicious commits in attacker-controlled forks. Researchers estimate up to 700 historical versions affected, based on how Packagist resolves GitHub tag references. If your PHP builds touched any of those packages during that window, you have a problem.
How the substitution worked
Packagist, PHP’s primary package registry, fetches the git tag corresponding to a requested version from GitHub. It does not cryptographically verify that the tag points to a commit in the canonical repository. The attacker exploited this gap: rewriting tags to reference attacker-controlled commits silently substituted malicious code for legitimate code in any build that resolved an affected version during the attack window.
The injected entry point was src/helpers.php, a dropper that executes automatically via Composer’s autoloader on inclusion. It called home to flipboxstudio[.]info to fetch the main payload: roughly 5,900 lines of PHP, organised across fifteen collection modules, exfiltrating harvested credentials encrypted with AES-256. Well-structured. Not hastily written.
What the stealer was actually after
Cloud credentials, primarily. The payload targeted AWS access keys, secret keys, and session tokens; GCP application default credentials; Azure access tokens; Kubernetes secrets; HashiCorp Vault tokens. Also in scope: GitHub Actions, GitLab CI, and CircleCI pipeline tokens; SSH private keys; Git credential stores. Seventeen Chromium-based browsers. Cryptocurrency wallet seed phrases.
The CI/CD focus is deliberate. Build pipelines are credential gold mines: they load .env files that aggregate secrets across the entire stack, and they routinely hold deployment credentials with production access. A developer running composer install on their laptop picks up maybe a handful of credentials. A CI job running the same command might expose an AWS role with full production rights, a repository with write access, and deployment keys for three separate services.
That’s what this was targeting. Not the developer. The pipeline.
The exposure picture
Any organisation running PHP-based applications (financial services, insurance, e-commerce, public sector web platforms) should check their build logs. Automated dependency tools like Dependabot and Renovate may have silently pulled affected versions without human review. A composer install that ran quietly at 3am is as exposed as one that ran manually.
This campaign isn’t novel in intent. npm, PyPI, and RubyGems have all taken hits from similar attacks over the past eighteen months. The consistent thread is cloud credential harvesting via supply chain substitution. Composer was always a viable target. Now it’s been confirmed as one.
Immediate response
Check composer.lock and CI build logs for references to the four affected packages. Any build that resolved them on 22–23 May should be treated as compromised until proven otherwise.
Then rotate. All AWS, GCP, and Azure credentials present in the build environment: rotate them, regardless of whether you can confirm exfiltration. Include CI/CD pipeline tokens, SSH keys, and any secrets accessible via .env files in the build context. If you’re unsure what was in scope, assume everything was.
Block outbound connections to flipboxstudio[.]info and pull egress logs for historical connections to that domain. Packagist has removed the affected versions; current builds are clean. But build caches and container image layers from the attack window may still contain the malicious code, so don’t assume a clean rebuild from cache is safe.