Twin Composer Incident on 22 May 2026 — Laravel-Lang Tag Injection (Aikido) and Postinstall Wave in 8 Composer Packages + 700+ GitHub Repositories (Socket)

TL;DR — the 90-second summary

What is the problem? — Force-push with compromised org credential

Which versions are actually affected?

Aikido has not published a complete version list for the manipulated tags. StepSecurity performed a live detonation in an isolated runner and documented the specific imposter commits for all four repos. What is publicly confirmed:

• All manipulated tags were created between 23:41 and 23:56 UTC on 22 May 2026.
• Distribution per StepSecurity: laravel-lang/http-statuses all tags v1.0.0–v3.4.5; laravel-lang/actions all 46 tags 1.0.0–1.12.2; laravel-lang/attributes all 86 tags; laravel-lang/lang also affected (Aikido first find).
• Identification of imposter commits: commit author Your Name <you@example.com> on every compromised tag commit; each commit modifies exactly two files: composer.json and src/helpers.php.
• Safe lockfile boundary: a composer.lock from before 22 May 2026 (23:41 UTC) run with composer install (no update) is outside the wave window — provided the pinned commit SHA is not one of the imposter commits. Check: compare the SHA from the lockfile against the StepSecurity imposter-commit list.

Current tag state after clean-up (as of evening 23 May):

The attack vector — force-push with compromised org credential

Per StepSecurity’s analysis (live detonation in an isolated runner), the attacker had direct push access to the Laravel-Lang GitHub organisation and rewrote all existing tags in the affected repositories via git push --force onto new malicious commits. The commits in each repo run 5–13 seconds apart — consistent with an automated script walking every tag in sequence and force-pushing a payload commit.

Aikido’s initial analysis described the mechanism as “version tags may point to commits from a fork” — that describes a related but separate GitHub property. StepSecurity’s more detailed live evaluation shows: here the existing tags were not redirected to fork commits but were fully overwritten with new imposter commits. Both vectors are technically possible; for this attack it was a direct force-push.

Packagist resolves version tags through GitHub and caches the tarballs. Anyone who ran composer install or composer update against Packagist during this window received a cleanly resolved tag (from Composer’s point of view) containing code that was never in the official repo’s main branch.

Stage 1 — Dropper via Composer autoload

The manipulated tags contain a file src/helpers.php. At first glance it looks like a Laravel localisation helper file: two harmless functions laravel_lang_locale() and laravel_lang_fallback(). Below the functions sits a self-executing code block — the moment the file is loaded it runs.

Composer packages are registered via the autoload section in composer.json. For Laravel-Lang the file is registered as a files-autoload entry, meaning it is evaluated automatically on the first require 'vendor/autoload.php' of the application. No application-side function call is needed — the dropper fires as soon as the application starts. StepSecurity performed a full live detonation; the entire sequence completes in under two seconds from the moment the autoloader fires.

What the dropper does:

1. Fingerprints the host (MD5 of file path + hostname + inode — per Aikido; Socket describes this differently as “directory path + system architecture + inode” — the sources conflict), writes a marker <tmp>/.laravel_locale/<md5> and fires only once per host.
2. Decodes the C2 domain flipboxstudio[.]info from an integer array — static scanning sees no suspicious string.
3. Pulls the payload via file_get_contents with a curl fallback (both with verify_peer = false) from flipboxstudio[.]info/payload.
4. Writes two files to /tmp: the PHP loader to /tmp/.laravel_locale/<12-hex>.php (hidden directory) and an ELF binary to /tmp/.<8-hex> (no extension, dot-prefixed — per StepSecurity live detonation).
5. On Linux/macOS: launches the PHP loader via sh -c "php /tmp/.laravel_locale/<name>.php > /dev/null 2>&1 &" in the background; the loader is reparented to ppid=1 (init adoption). The loader then launches the ELF binary via nohup /tmp/.<name> > /dev/null 2>&1 &.
6. The ELF binary then deletes both files from disk. The processes continue running from memory (the Linux kernel only releases an inode once no process holds it open) — no on-disk footprint, but visible in ps as orphaned processes with ppid=1.
7. On Windows: drops a .vbs launcher file and runs it silently via cscript.

Stage 2 — Credential stealer

The downloaded payload is a ~5,900-line PHP stealer with 15 specialised collector modules. After collection it AES-256-encrypts, exfiltrates to flipboxstudio[.]info/exfil and deletes itself to minimise forensic traces.

What the stealer takes (full list per the Aikido analysis):

• Cloud credentials: AWS access/secret keys + session tokens (from environment, ~/.aws/credentials, EC2 instance metadata); GCP application default credentials, access-token DB, all named CLI configurations; Azure access tokens, MSAL cache, service principal profiles; DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io auth tokens.
• Infrastructure secrets: all kubeconfigs (incl. /etc/kubernetes/admin.conf); HashiCorp Vault tokens; Helm repository configs; Docker config.json.
• Developer credentials: SSH private keys, all .git-credentials and .gitconfig, .netrc, .npmrc, .yarnrc, .pypirc, .gem/credentials, .composer/auth.json; GitHub/GitLab/Hub CLI tokens; shell history (bash, zsh, psql, mysql, python, node); all .env and config files (wp-config.php, settings.py, docker-compose.yml, secrets.yaml) via recursive scan in the working directory.
• Browsers and password managers: 17 Chromium browsers (Chrome, Edge, Brave, Opera, Opera GX, Vivaldi, Chromium, Yandex, …) — on Windows with a bundled .exe for DPAPI decryption of the Chrome login database; Firefox/Thunderbird logins.json and key4.db across all profiles; KeePass .kdbx/.kdb; 1Password and Bitwarden local vault.
• Crypto wallets: Bitcoin, Ethereum, Monero, Litecoin, Dash, Dogecoin, Zcash wallet files; Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow; browser extension wallets by extension ID — MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, Rabby.
• Windows-specific: Credential Manager and Vault, PuTTY and WinSCP sessions (WinSCP passwords actively decrypted), .rdp files from Desktop/Documents/Downloads, Outlook registry profiles, OST/PST inventory.
• Chat tokens: Slack tokens, Discord bot tokens, Telegram bot tokens.
• VPN configs: NordVPN, ExpressVPN, ProtonVPN, CyberGhost, Private Internet Access, Windscribe, Mullvad, Surfshark, WireGuard, OpenVPN.

This is not selective espionage, it is a broad credential sweep — there is no worm character (unlike Shai-Hulud), but the loot class per infected machine is unusually complete.

On the same day, the Socket Research Team published a second Composer incident — structurally different from the Laravel-Lang tag injection, but thematically closely related: a malicious postinstall hook in package.json (not composer.json) that pulls a Linux binary from a GitHub releases URL into /tmp/.sshd and starts it in the background.

Affected Composer packages (Socket finding)

Eight Composer packages in branch-tracking versions:

Packagist has temporarily removed the affected packages but notes that branch-tracking packages can be restored at the next package update if the upstream repository has not been cleaned. Three of the eight repos had not been reverted at the time of the Socket research.

Comparison table of the two incidents on 22 May

What both incidents structurally show in common

Both incidents hit the same trust break in the Composer/Packagist model: the delivered code reference is not cryptographically bound to the SemVer version or branch name. Composer and Packagist trust the resolved commit hash; whoever manipulates that at the GitHub layer — whether via tag injection from a fork (Laravel-Lang) or via malicious commits directly in the upstream repository (Socket wave) — manipulates without a hint in the SemVer label.

Both incidents also show that version-name trust is the only thing Composer has on the dist side. Local Composer caches do not re-validate tarball hashes against the repo state. Lockfile hash pinning on the application side remains the most reliable brake — which leads directly into the reflection in the „What we actually did“ section further down.

An additional layer that the Socket report uncovers: cross-ecosystem reviewer blindspot. A security reviewer auditing a PHP Composer package looks at composer.json and the PHP classes — package.json with postinstall hooks, sitting in the same repository for the JavaScript build tooling, rarely receives the same attention. The same pattern in .github/workflows/*.yml files is the next layer.

At Moselwal: none of the 8 packages in the tree, branch tracking not in production anyway

The eight packages named by Socket (silverstripe-cms-theme, crosierlib-base, devdojo/wave, devdojo/genesis, katanaui/katana, elitedevsquad/sidecar-laravel, r2luna/brain, baskarcm/tzi-chat-ui) are not in any of the Composer trees we operate — they are starter kits, CMS themes or specific tooling packages that do not appear in our platform selection. Branch-tracking Composer versions (dev-main, dev-master, 3.x-dev) are generally to be avoided in serious production setups and are not in use in our platforms. The cross-ecosystem reviewer-blindspot question (package.json alongside composer.json) is still a point for our audit routine — we are verifying whether the SBOM generation of the managed platforms covers package.json files in Composer vendor directories.

Who is affected?

At Moselwal: no exposure as of now

Laravel is used at Moselwal only in smaller projects — none of the central client platforms runs on Laravel. Our Composer logs show no executed update operations on the managed Laravel projects since 22 May 2026; the wave window was not crossed. The managed platforms are therefore not affected as of now.

Precautions we are running anyway:

• Composer updates for the Laravel projects remain paused until Aikido and the maintainers publish a complete cleaned version list and Friends-Of-PHP marks the manipulated versions in composer audit.
• Lockfile diff against the current GitHub tag list for the Laravel projects — if a version in the lockfile no longer appears in the official tag index after cleanup, that would be a hit. As of the evening of 23 May: no such finding.
• Outbound DNS logs on the build agents are scanned for resolutions of flipboxstudio.info — as of the evening of 23 May: no hits.

We don’t assume, we check — and the check on the Laravel projects is complete (negative). For non-Laravel stacks the wave is structurally not relevant.

Impact

Build-time credential exfiltration at a scale that exceeds previous Composer waves. While the Mini-Shai-Hulud / intercom-php wave on 30 April targeted a relatively narrow loot list (npm tokens, GitHub PATs, cloud credentials), the Laravel-Lang stealer takes practically every reachable credential from a developer or build machine — including browser passwords and crypto wallets, which goes beyond the classical build-pipeline threat and points to developer workstations as an additional target.

Structural note on tag injection: unlike classical compromised maintainer accounts (phishing, token theft, then push into the official repo), the expected repository state often still looks clean. The manipulation sits between the version-name/tag trust layer and the actually delivered commit/dist — Composer and Packagist ultimately trust the resolved reference, not a cryptographically immutable SemVer version. Code review and git log on the official repo show nothing; only a comparison of tag commit hashes against the commits reachable from the main branch finds the discrepancy. Maintainers do not normally automate that verification.

Composer autoload layer as a silent trigger trace. Unlike npm preinstall hooks, the Composer autoload mechanism is not a dedicated pre-install hook — it is part of the normal application bootstrap. This means: composer install --ignore-scripts (the standard mitigation against npm worm payloads) does not help here, because the payload does not run through lifecycle scripts but through the files autoload field. The stealer only fires on the first application start, but in CI pipelines with a test run that is effectively immediate.

Latent traces in the Composer cache: Packagist pulled the tags, but that only protects against future installs. Local ~/.composer/cache/ directories on build agents still contain the compromised tarballs. A later re-install without a network pull (e.g. after a build cache restore) can roll out the payload again.

Cross-ecosystem reviewer blindspot (Socket finding from the same day): the parallel Composer incident with a postinstall hook in package.json hits a different but structurally related layer. A reviewer auditing a PHP Composer package looks at composer.json and the PHP classes — package.json hooks alongside the Composer manifest, stored in the same repository for the JavaScript build tooling, rarely receive the same attention; the same applies to .github/workflows/*.yml files. Both wave patterns on a single day show that the Composer trust model relies in several places on conventions that are not cryptographically bound.

As of the evening of 23 May 2026: no confirmed mass exploitation reports against productive end users — but the pull window of ~24–36 hours since 22 May was sufficient to hit a relevant number of build agents. The reach will become clearer over the next few days via token audit reports from the affected cloud providers.

Mitigation / Immediate actions

Path 1 — Determine the pull window

# CI log analysis: did a composer install/update run since 22 May 2026 (from 23:41 UTC)?
grep -E "(composer install|composer update)" .github/workflows/*.yaml

# Match in the tree (now four packages):
composer show | grep "laravel-lang/"

# Check lockfile hashes of all four packages
grep -A 2 'laravel-lang/(lang|attributes|http-statuses|actions)' composer.lock

# Check imposter commit author in a local git clone
git log --format='%H %ae' | grep 'you@example.com'

If composer.lock contains a dist.reference commit hash from the May window (from 23:41 UTC), the pipeline very likely pulled the payload. Additional check: verify the commit author of the tagged version in the GitHub repo — imposter commits carry Your Name <you@example.com> as author and change exactly two files (composer.json + src/helpers.php).

Path 2 — Check Composer cache, markers and running processes

# Clear Composer cache (build agents and developer machines)
composer clear-cache

# Search for PHP loader marker and drop
find /tmp -type d -name ".laravel_locale" -print 2>/dev/null
find /tmp -path '*/.laravel_locale/*' 2>/dev/null

# Search for ELF binary drop (dot-prefixed, no extension, self-deletes after start)
find /tmp -maxdepth 1 -name '.*' -not -type d 2>/dev/null

# Check orphaned processes: PHP loader + ELF continue running from memory
# even after file deletion (reparented to ppid=1)
ps auxf | awk '{if ($3==1) print}'
ls -la /proc/*/exe 2>/dev/null | grep deleted

# On Windows (PowerShell)
Get-ChildItem -Path $env:TEMP -Filter '.laravel_locale' -Recurse -Force

If markers, drops or orphaned processes with ppid=1 running from deleted /tmp paths are found: the machine is compromised. Pull forensic images before wiping traces — the ELF binary continues running from memory after file deletion.

Path 3 — Credential rotation

On hit the entire credential stack needs to rotate, because the stealer reaches broadly:

• Cloud tokens: AWS, GCP, Azure, DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io
• Git/repo tokens: GitHub PAT, GitLab token, Hub CLI token, .git-credentials files
• Container registry: Docker Hub login, GHCR, ECR, GCR, ACR
• Kubernetes: all kubeconfigs and service-account tokens on the affected machine
• SSH keys: all private keys (knock-on effect: server access, deployment targets)
• HashiCorp Vault: all tokens that sat in the Vault CLI auth cache
• Browser passwords and password manager vaults: change master passwords, regenerate affected vault files

On Windows additionally: WinSCP sessions, PuTTY sessions, Outlook profile credentials, RDP targets.

Path 4 — Network detection

# Search DNS/proxy logs for the C2 domain
grep -i 'flipboxstudio' /var/log/squid/access.log
grep -i 'flipboxstudio' /var/log/named/queries.log

# Outbound connections on the build agents over the last 72 h
journalctl --since "2026-05-21" | grep -i 'flipboxstudio'

Falco/Tetragon rule (short form) for DNS resolutions of the C2 host:

- rule: Laravel-Lang Stealer C2 DNS Lookup
  desc: Process resolves the Laravel-Lang stealer C2 domain
  condition: >
    evt.type=connect and
    fd.name contains "flipboxstudio.info"
  output: "Laravel-Lang stealer C2 lookup (proc=%proc.name fd=%fd.name)"
  priority: CRITICAL

Path 5 — composer audit as a pre-deploy gate

composer audit --format=plain

The Friends-Of-PHP database picks up the manipulated tags once the GHSA advisories are published. Until then: cross-check the SBOM (CycloneDX) against the StepSecurity imposter-commit list.

Path 6 — Roll the lockfile back to a pre-22-May state

If a clean lockfile state from before 22 May 2026 (23:41 UTC) is available in the git history (typically the last successful production deploy), a git checkout <commit> -- composer.lock plus composer install is enough to restore a safe state. If you run continuous updates, check the last lockfile commit hash against the wave window.

Indicators of compromise — Laravel-Lang (Aikido / StepSecurity)

Indicators of compromise — Postinstall wave (Socket)

Composer tree inventory (general, for platform operators)

# Find applications with Laravel-Lang in the tree (now four packages)
find . -name composer.json -exec grep -l 'laravel-lang/' {} \;

# Version state per application
find . -name composer.lock -exec grep -A 1 'laravel-lang/' {} \;

# Check imposter commit author in a local git clone
git log --format='%H %ae %s' | grep 'you@example.com'

# Socket wave: find branch-tracking constraints in your tree
find . -name composer.json -exec grep -E '"(dev-main|dev-master|[0-9]+\.x-dev)"' {} \;

# Cross-ecosystem: package.json in Composer vendor trees
find vendor -name package.json -exec grep -l '"postinstall"' {} \;

Process hunting on build agents (Linux)

# Orphaned processes with ppid=1 running from /tmp (persist after file deletion)
ps auxf | awk '{if ($3==1) print}'
ls -la /proc/*/exe 2>/dev/null | grep deleted

# ELF binary drop (dot-prefixed, no extension, self-deletes after start)
find /tmp -maxdepth 1 -name '.*' -not -type d 2>/dev/null

# PHP loader drop and marker
find /tmp -type d -name '.laravel_locale' 2>/dev/null
find /tmp -path '*/.laravel_locale/*' 2>/dev/null

CI pipeline traces

# Which pipelines ran a Composer pull since 22 May 2026 (from 23:41 UTC)?
gh run list --created '>=2026-05-22' --workflow ci.yml

# Socket wave: outbound connections to parikhpreyash4 GitHub release URLs
grep -i 'parikhpreyash4/systemd-network-helper' /var/log/squid/access.log

# Check drop path
ls -la /tmp/.sshd 2>/dev/null && echo 'HIT: /tmp/.sshd present'

Operational Decision Block

• Act immediately if … a build pulled against Packagist since 22 May 2026 (from 23:41 UTC) with laravel-lang/lang, /attributes, /http-statuses or /actions in the tree or a Composer tree contains a branch-tracking version (dev-main, dev-master, 3.x-dev) of one of the 8 Socket-named packages: credential rotation, clear Composer cache, marker-file scan, /tmp/.sshd check.
• Precaution if … Laravel-Lang is in the tree but the last pull was before 22 May 2026: verify lockfile pinning, enforce composer install without update, compare the SBOM against the Aikido version list.
• Pause is recommended as long as … the maintainers are still cleaning up the tag resolution trace and the Friends-Of-PHP database does not fully cover the manipulated versions: no Composer updates on affected projects. For branch-tracking packages the rule generally is: do not use in production.
• Not deferrable: no effective workaround mitigation other than pausing pulls and clearing the cache.

Mittelstand (Laravel platforms)

If you run Laravel projects in production and use Laravel-Lang: pause updates, audit the pull window, rotate credentials on affected build agents and developer machines. Operators using Renovate/Dependabot with auto-merge should pause the auto-merge until the maintainers clarify.

Enterprise (multi-tenant builds)

Central SBOM audit across all tenants against the Aikido version list, build-agent pool inventory for marker files, token audit logs from the cloud providers for unusual AssumeRole / GetSessionToken / iam:* activity since 22 May 2026. Rotate Vault tokens with audit log activity. In parallel: package.json inventory in Composer vendor trees (Socket pattern) and .github/workflows/*.yml scan for the same shell command pattern.

Kubernetes / containerised setups

If a build agent with kubeconfig access was hit: treat all kubeconfigs on that agent as compromised, rotate affected service-account tokens in the cluster, review the audit log for unusual API calls since 22 May.

Declarative stacks (NixOS, Talos, Flatcar with Wolfi images)

Image rebuild against a cleaned composer.lock, new image tag, staged rollout. The pull layer of the Wolfi images is signature-checked, but the build layer inside the image that runs composer install is just as vulnerable as any other Composer build layer.

As of the evening of 23 May 2026: after the Aikido report we paused all Composer update pipelines on the Laravel projects — Renovate auto-merge stopped there, scheduled maintenance-window pulls deferred. Laravel is used at Moselwal only in smaller projects, which keeps the auditing scope manageable.

The audit has completed with a negative finding:

• CI log audit: there were no executed Composer update operations on the Laravel projects between 22 and 23 May 2026. The wave window was not crossed.
• Lockfile diff: the Laravel-Lang versions in the composer.lock states of the affected projects are on old, clean versions from before 22 May. A diff against the current GitHub tag list shows no versions that disappeared from the tag index after the cleanup.
• Build agent inventory: the tmp directory on the build agents contains no .laravel_locale markers; the Composer cache was cleared as a precaution. Additionally: no /tmp/.sshd on the agents (Socket IoC).
• Outbound DNS logs: no resolutions of flipboxstudio.info in the DNS and proxy logs of the build infrastructure across 22–23 May. Also no resolutions of GitHub releases paths of parikhpreyash4/systemd-network-helper-aa5c751f (Socket IoC).
• Socket package check: none of the 8 Socket-named packages (silverstripe-cms-theme, crosierlib-base, devdojo/wave, devdojo/genesis, katanaui/katana, elitedevsquad/sidecar-laravel, r2luna/brain, baskarcm/tzi-chat-ui) appears in any of the managed Composer trees. Branch-tracking Composer versions are not in use in our production platforms anyway.

Composer updates for the Laravel projects remain paused for now, until a full version list of the manipulated tags (Aikido Intel feed or GHSA advisory) is published and Friends-Of-PHP covers the wave in composer audit. Renovate auto-merge will be re-activated at the earliest after that; a targeted manual update in a maintenance window is conceivable once the exact range of withdrawn versions is known.

Structural note from this incident: the tag injection method is new in the Composer world (the npm universe saw comparable patterns in 2025). Unlike classical maintainer-account takeovers, code review is not enough — the resolution from tag → commit hash → tree membership must be verified. Today that is not automated in the standard Composer pipeline. A central, language-agnostic convention enforcing that tags may only point to commits from the default branch of the official repo would be a structural answer — that sits with GitHub and the package-manager registries, not with individual maintainers.

Reflection on our own approach: in the wake of this incident Moselwal is investigating whether the rule „libraries do not track a lockfile“ is still appropriate in package and extension development. Composer tradition (and npm tradition) is that libraries do not carry a composer.lock or package-lock.json in git — the lock file is maintained per application, not per library, because constraint ranges are resolved on the consuming side anyway. The Laravel-Lang incident shows, however, that in a world where tag injection is possible at the GitHub layer and Composer caches do not re-validate tarball hashes against the repo state, lockfile hash pinning at the application level is the most reliable brake — and a library repository that does not itself maintain a traceable lockfile cannot unambiguously document its own productively tested dependency state. We are looking at the question openly, without a foregone answer: for applications the rule remains clear (commit the lockfile with the integrity hash); for our own libraries and TYPO3 extensions the line is conventionally different, and this incident is reason to question that line critically.

The Laravel-Lang tag injection is not the largest Composer incident of recent weeks — the intercom-php wave at the end of April had the broader reach with more than 20 million lifetime installs, and the npm Shai-Hulud series is in another league thanks to its worm mechanics. But it is structurally particularly instructive: the expected repository state can look clean while the manipulation enters the supply chain via rewritten git tags and the reference Packagist subsequently delivers. The trigger is not necessarily an explicit lifecycle hook — it can be the normal Composer autoload layer. Anyone who treated composer install --ignore-scripts as a sufficient defence against supply chain attacks now has a fairly clear data point that that assumption is too narrow.

The parallel Socket incident on the same day sharpens the picture from another side. While Laravel-Lang touches the tag-resolution layer between GitHub and Packagist, the eight Composer packages reported by Socket hit the branch-tracking mechanism — dev-main, dev-master, 3.x-dev as versions that are by definition not immutable, plus the cross-ecosystem reviewer blindspot: malicious code in package.json, not in composer.json. That the same payload pattern reproduced in .github/workflows/*.yml files is the third layer. The two incidents are not independent one-offs but two species of the same structural problem: the Composer trust model rests on the delivered reference, not on a cryptographically immutable version binding. Until that layer is fixed, lockfile hash pinning on the application side remains the most reliable brake — which is exactly the starting point for the reflection on whether the convention „libraries do not track a lockfile“ is still appropriate in our own package and extension development.