Doppelter Composer-Vorfall am 22. Mai 2026 — Laravel-Lang-Tag-Injection (Aikido) und postinstall-Welle in 8 Composer-Paketen + 700+ GitHub-Repos (Socket)

TL;DR — die 90-Sekunden-Zusammenfassung

Was ist das Problem? — Force-Push mit kompromittiertem Org-Credential

Welche Versionen sind konkret betroffen?

Aikido hat keine vollständige Versionsnummern-Liste publiziert. StepSecurity hat alle vier Repos live in einem isolierten Runner detoniert und die konkreten Imposter-Commits dokumentiert. Was öffentlich gesichert ist:

• Alle manipulierten Tags entstanden zwischen 23:41 und 23:56 UTC am 22. Mai 2026.
• Verteilung laut StepSecurity: laravel-lang/http-statuses alle Tags v1.0.0–v3.4.5; laravel-lang/actions alle 46 Tags 1.0.0–1.12.2; laravel-lang/attributes alle 86 Tags; laravel-lang/lang ebenfalls betroffen (Aikido-Erstfund).
• Erkennungszeichen aller Imposter-Commits: Autor Your Name <you@example.com>; jeder Commit modifiziert exakt zwei Dateien: composer.json und src/helpers.php.
• Sichere Lockfile-Grenze: ein composer.lock vor dem 22. Mai 2026 (23:41 UTC) mit composer install (ohne update) ist außerhalb des Welle-Fensters — sofern der gepinnte Commit-SHA kein Imposter-Commit ist. Prüfung: die SHA aus dem Lockfile gegen die StepSecurity-Imposter-Commit-Liste abgleichen.

Aktueller Tag-Stand nach der Aufräumarbeit (Stand 23. Mai abends):

Der Angriffsvektor — Force-Push mit kompromittiertem Org-Credential

Laut StepSecurity-Analyse (Live-Detonation in isoliertem Runner) hatte der Angreifer direkten Push-Zugriff zur Laravel-Lang GitHub-Organisation und hat alle bestehenden Tags in den betroffenen Repositories via git push --force auf neue malicious Commits umgeschrieben. Die Commits laufen 5–13 Sekunden auseinander — konsistent mit einem automatisierten Script, das alle Tags eines Repos der Reihe nach force-pusht.

Die Aikido-Erstanalyse beschrieb den Mechanismus als „Version-Tags können auf Commits aus einem Fork zeigen“ — das trifft eine verwandte, aber separate GitHub-Eigenschaft. StepSecurity’s detailliertere Live-Auswertung zeigt: hier wurden bestehende Tags nicht auf Fork-Commits umgeleitet, sondern vollständig mit neuen Imposter-Commits überschrieben. Beide Vektoren sind technisch möglich; für diesen Angriff war es ein direkter Force-Push.

Packagist löst Version-Tags über GitHub auf und cached die Tarballs. Wer in dieser Phase ein composer install oder composer update gegen Packagist gefahren hat, bekommt einen sauber aufgelösten Tag (aus Composer-Sicht) mit Code, der nie im offiziellen Repo-Hauptbranch war.

Stage 1 — Dropper über Composer-Autoload

Die manipulierten Tags enthalten eine Datei src/helpers.php. Auf den ersten Blick sieht sie nach einer Laravel-Lokalisierungs-Hilfsdatei aus: zwei harmlose Funktionen laravel_lang_locale() und laravel_lang_fallback(). Unter den Funktionen sitzt ein self-executing Code-Block — sobald die Datei geladen wird, läuft er.

Composer-Pakete werden über die autoload-Sektion in composer.json registriert. Für Laravel-Lang ist die Datei als files-Autoload eingetragen, das heißt: sie wird beim ersten require 'vendor/autoload.php' der Anwendung automatisch ausgewertet. Ein Application-Code-Aufruf der Funktionen ist nicht nötig — der Dropper feuert, sobald die Anwendung startet. StepSecurity hat die vollständige Kill Chain live detoniert; die gesamte Sequenz läuft in unter zwei Sekunden ab dem Moment, in dem der Autoloader feuert.

Was der Dropper macht:

1. Fingerprintet den Host (MD5 aus Dateipfad + Hostname + Inode — laut Aikido; Socket nennt abweichend „Directory Path + System Architecture + Inode“, die Quellen widersprechen sich), schreibt einen Marker <tmp>/.laravel_locale/<md5> und feuert pro Host nur einmal.
2. Dekodiert die C2-Domain flipboxstudio[.]info aus einem Integer-Array — statisches Scanning sieht keinen verdächtigen String.
3. Holt das Payload via file_get_contents mit curl-Fallback (beide mit verify_peer = false) von flipboxstudio[.]info/payload.
4. Schreibt zwei Dateien in /tmp: den PHP-Loader nach /tmp/.laravel_locale/<12-hex>.php (hidden directory) und ein ELF-Binary nach /tmp/.<8-hex> (kein Extension, dot-prefixed — laut StepSecurity-Detonation).
5. Auf Linux/macOS: startet den PHP-Loader via sh -c "php /tmp/.laravel_locale/<name>.php > /dev/null 2>&1 &" im Hintergrund; der Loader wird zu ppid=1 reparented (init-Adoption). Der Loader startet dann das ELF-Binary via nohup /tmp/.<name> > /dev/null 2>&1 &.
6. Das ELF-Binary löscht anschließend beide Dateien vom Disk. Der Prozess läuft danach weiter aus dem Speicher (Linux-Kernel gibt einen Inode erst frei, wenn kein Prozess ihn hält) — kein On-Disk-Footprint, aber sichtbar in ps als orphaned Prozess mit ppid=1.
7. Auf Windows: dropt eine .vbs-Launcher-Datei und führt sie via cscript still aus.

Stage 2 — Credential-Stealer

Das nachgeladene Payload ist ein ~5.900 Zeilen langer PHP-Stealer mit 15 spezialisierten Collector-Modulen. Nach der Sammlung verschlüsselt er AES-256, exfiltriert an flipboxstudio[.]info/exfil und löscht sich selbst, um die forensische Spur zu minimieren.

Was der Stealer mitnimmt (vollständige Liste laut Aikido-Analyse):

• Cloud-Credentials: AWS-Access-/Secret-Keys + Session-Tokens (aus Environment, ~/.aws/credentials, EC2-Instance-Metadata); GCP Application Default Credentials, Access-Token-DB, alle Named-CLI-Konfigurationen; Azure-Access-Tokens, MSAL-Cache, Service-Principal-Profile; DigitalOcean-, Heroku-, Vercel-, Netlify-, Railway-, Fly.io-Auth-Tokens.
• Infrastruktur-Secrets: alle Kubeconfigs (inkl. /etc/kubernetes/admin.conf); HashiCorp-Vault-Tokens; Helm-Repository-Configs; Docker config.json.
• Developer-Credentials: SSH-Private-Keys, alle .git-credentials und .gitconfig, .netrc, .npmrc, .yarnrc, .pypirc, .gem/credentials, .composer/auth.json; GitHub-/GitLab-/Hub-CLI-Tokens; Shell-History (bash, zsh, psql, mysql, python, node); alle .env und Config-Files (wp-config.php, settings.py, docker-compose.yml, secrets.yaml) per rekursivem Scan im Working-Directory.
• Browser und Password-Manager: 17 Chromium-Browser (Chrome, Edge, Brave, Opera, Opera GX, Vivaldi, Chromium, Yandex, …) — auf Windows mit gebundelter .exe für die DPAPI-Entschlüsselung der Chrome-Login-Datenbank; Firefox/Thunderbird logins.json und key4.db über alle Profile; KeePass .kdbx/.kdb; 1Password und 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 nach Extension-ID — MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, Rabby.
• Windows-spezifisch: Credential-Manager und Vault, PuTTY- und WinSCP-Sessions (WinSCP-Passwörter aktiv entschlüsselt), .rdp-Files aus Desktop/Documents/Downloads, Outlook-Registry-Profile, 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.

Das ist keine selektive Spionage, sondern ein breit angelegtes Credential-Sweep — der Worm-Charakter fehlt (anders als Shai-Hulud), aber die Beuteklasse pro infizierter Maschine ist außergewöhnlich vollständig.

Am gleichen Tag hat das Socket Research Team einen zweiten Composer-Vorfall publiziert — strukturell anders als die Laravel-Lang-Tag-Injection, aber thematisch eng verwandt: ein malicious postinstall-Hook in package.json (nicht composer.json), der einen Linux-Binary von einer GitHub-Releases-URL nach /tmp/.sshd zieht und im Hintergrund startet.

Betroffene Composer-Pakete (Socket-Befund)

Acht Composer-Pakete in Branch-Tracking-Versionen:

Packagist hat die betroffenen Pakete temporär entfernt, weist aber darauf hin, dass Branch-Tracking-Pakete beim nächsten Package-Update wiederhergestellt werden können, wenn das Upstream-Repository nicht bereinigt ist. Drei der acht Repos waren zum Zeitpunkt der Socket-Recherche noch nicht revertet.

Vergleichstabelle der zwei Vorfälle vom 22. Mai

Was beide Vorfälle strukturell gemeinsam zeigen

Beide Vorfälle treffen denselben Vertrauensbruch im Composer-/Packagist-Modell: die ausgelieferte Code-Referenz ist nicht kryptografisch an die SemVer-Version oder den Branch-Namen gebunden. Composer und Packagist vertrauen auf den aufgelösten Commit-Hash; wer den auf der GitHub-Schicht manipuliert — sei es durch Tag-Injection aus einem Fork (Laravel-Lang) oder durch malicious commits direkt im Upstream-Repository (Socket-Welle) —, manipuliert ohne Hinweis im SemVer-Label.

Beide Vorfälle zeigen außerdem, dass das Versionsname-Vertrauen das einzige ist, was Composer auf der Dist-Seite hat. Lokale Composer-Caches validieren die Tarball-Hashes nicht erneut gegen den Repo-Stand. Lockfile-Hash-Pinning auf der Application-Seite bleibt die zuverlässigste Bremse — was direkt zur Reflektion in der „Was ich konkret getan habe“-Sektion weiter unten führt.

Eine zusätzliche Schicht, die der Socket-Bericht aufdeckt: Cross-Ecosystem-Reviewer-Blindspot. Wer als Security-Reviewer ein PHP-Composer-Paket prüft, schaut auf composer.json und die PHP-Klassen — package.json mit postinstall-Hooks, die im selben Repository für das JavaScript-Build-Tooling liegen, bekommt selten dieselbe Aufmerksamkeit. Dasselbe Pattern in .github/workflows/*.yml-Files ist die nächste Schicht.

Bei mir: keiner der 8 Pakete im Tree, Branch-Tracking ohnehin nicht in Production

Die acht von Socket genannten Pakete (silverstripe-cms-theme, crosierlib-base, devdojo/wave, devdojo/genesis, katanaui/katana, elitedevsquad/sidecar-laravel, r2luna/brain, baskarcm/tzi-chat-ui) sind in keinem der von mir betreuten Composer-Trees zu finden — sie sind durchweg Starter-Kits, CMS-Themes oder spezifische Tooling-Pakete, die in meiner Plattform-Auswahl nicht vorkommen. Branch-Tracking-Composer-Versionen (dev-main, dev-master, 3.x-dev) sind in seriösen Production-Setups generell zu vermeiden und werden in meinen Plattformen nicht eingesetzt. Die Cross-Ecosystem-Reviewer-Blindspot-Frage (package.json neben composer.json) ist trotzdem ein Punkt für meine Audit-Routine — ich prüfe, ob die SBOM-Generierung der betreuten Plattformen package.json-Files in Composer-Vendor-Verzeichnissen abdeckt.

Wer ist betroffen?

Bei mir: keine Betroffenheit nach aktuellem Stand

Laravel kommt bei mir nur in kleineren Projekten zum Einsatz — keine der zentralen Mandanten-Plattformen läuft auf Laravel. Meine Composer-Logs zeigen seit dem 22. Mai 2026 keine ausgeführten Update-Operationen auf den betreuten Laravel-Projekten; das Welle-Fenster wurde nicht durchlaufen. Damit sind die betreuten Plattformen nach aktuellem Stand nicht betroffen.

Vorsichtsmaßnahmen, die ich trotzdem fahre:

• Composer-Updates für die Laravel-Projekte bleiben ausgesetzt, bis Aikido und die Maintainer eine vollständige bereinigte Versions-Liste publiziert haben und Friends-Of-PHP die manipulierten Versionen in composer audit markiert.
• Lockfile-Diff gegen die aktuelle GitHub-Tag-Liste bei den Laravel-Projekten — falls eine Version im Lockfile steht, die nach der Aufräumarbeit nicht mehr im offiziellen Tag-Index auftaucht, wäre das ein Treffer. Stand 23. Mai abends: kein solcher Fund.
• Outbound-DNS-Logs der Build-Agenten werden auf Auflösungen von flipboxstudio.info gescannt — Stand 23. Mai abends: keine Treffer.

Ich vermute nichts, ich prüfe — und das Prüfen ist bei den Laravel-Projekten durch (negativ). Bei nicht-Laravel-Stacks ist die Welle strukturell nicht relevant.

Auswirkungen

Build-Time-Credential-Exfiltration in einem Umfang, der über frühere Composer-Wellen hinausgeht. Während die Mini-Shai-Hulud-/intercom-php-Welle am 30. April auf eine relativ enge Beuteliste zielte (npm-Tokens, GitHub-PATs, Cloud-Credentials), nimmt der Laravel-Lang-Stealer praktisch alle reichweitenfähigen Credentials einer Entwickler- oder Build-Maschine mit — inkl. Browser-Passwörter und Crypto-Wallets, was über die klassische Build-Pipeline-Bedrohung hinausgeht und auf Entwickler-Workstations als zusätzliches Ziel hindeutet.

Strukturhinweis Tag-Injection: anders als bei klassischen kompromittierten Maintainer-Accounts (Phishing, Token-Diebstahl, dann Push in den offiziellen Repo) bleibt der erwartete Repository-Zustand häufig sauber. Die Manipulation sitzt zwischen der Versionsname-/Tag-Vertrauens-Schicht und dem tatsächlich ausgelieferten Commit/Dist — Composer und Packagist vertrauen am Ende auf die aufgelöste Referenz, nicht auf eine kryptografisch unveränderliche SemVer-Version. Code-Review und git log auf dem offiziellen Repo zeigen nichts; nur ein Vergleich der Tag-Commit-Hashes gegen die im Hauptbranch erreichbaren Commits findet die Diskrepanz. Maintainer haben diese Verifikation in der Regel nicht automatisiert.

Composer-Autoload-Schicht als stille Trigger-Spur. Anders als bei npm-preinstall-Hooks ist der Composer-Autoload-Mechanismus kein dedizierter Pre-Install-Hook — er ist Teil des normalen Application-Bootstraps. Das heißt: composer install --ignore-scripts (die Standard-Mitigation gegen npm-Worm-Payloads) hilft hier nicht, weil das Payload nicht über Lifecycle-Scripts läuft, sondern über das files-Autoload-Feld. Der Stealer feuert erst beim ersten Anwendungs-Start, aber das ist in CI-Pipelines mit Test-Run praktisch sofort.

Latente Spuren im Composer-Cache: Packagist hat die Tags gezogen, aber das schützt nur vor zukünftigen Installs. Lokale ~/.composer/cache/-Verzeichnisse auf Build-Agenten enthalten die kompromittierten Tarballs weiterhin. Ein späterer Re-Install ohne Network-Pull (z. B. nach einem Build-Cache-Restore) kann das Payload erneut ausrollen.

Cross-Ecosystem-Reviewer-Blindspot (Socket-Befund vom selben Tag): der parallele Composer-Vorfall mit postinstall-Hook in package.json trifft eine andere, aber strukturell verwandte Schicht. Wer ein PHP-Composer-Paket reviewed, schaut auf composer.json und die PHP-Klassen — package.json-Hooks neben dem Composer-Manifest, im selben Repository für das JavaScript-Build-Tooling abgelegt, bekommen selten dieselbe Aufmerksamkeit; dasselbe gilt für .github/workflows/*.yml-Files. Beide Welle-Pattern an einem Tag zeigen, dass das Composer-Vertrauensmodell sich gleich an mehreren Stellen auf Konventionen verlässt, die nicht kryptografisch gebunden sind.

Stand 23. Mai 2026 abends: keine bestätigten Mass-Exploitation-Berichte gegen produktive End-Anwender — aber das Pull-Fenster von ~24–36 Stunden seit dem 22. Mai war ausreichend, um eine relevante Zahl Build-Agenten zu treffen. Die Reichweite klärt sich in den nächsten Tagen über Token-Audit-Reports der betroffenen Cloud-Anbieter.

Mitigation / Sofortmaßnahmen

Pfad 1 — Pull-Fenster bestimmen

# CI-Log-Analyse: lief seit dem 22. Mai 2026 (ab 23:41 UTC) ein composer install/update?
grep -E "(composer install|composer update)" .github/workflows/*.yaml

# Treffer im Tree (jetzt vier Pakete):
composer show | grep "laravel-lang/"

# Lockfile-Hashes der vier Pakete prüfen
grep -A 2 'laravel-lang/(lang|attributes|http-statuses|actions)' composer.lock

# Imposter-Commit-Autor im lokalen Git-Klon prüfen
git log --format='%H %ae' | grep 'you@example.com'

Wenn composer.lock einen dist.reference-Commit-Hash aus dem Mai-Fenster (ab 23:41 UTC) enthält, hat die Pipeline das Payload mit hoher Wahrscheinlichkeit gezogen. Zusätzlich: Commit-Autor der getaggten Version im GitHub-Repo prüfen — Imposter-Commits tragen Your Name <you@example.com> als Autor und ändern exakt zwei Dateien (composer.json + src/helpers.php).

Pfad 2 — Composer-Cache, Marker und laufende Prozesse prüfen

# Composer-Cache leeren (Build-Agenten und Entwickler-Maschinen)
composer clear-cache

# PHP-Loader-Marker und -Drop suchen
find /tmp -type d -name ".laravel_locale" -print 2>/dev/null
find /tmp -path '*/.laravel_locale/*' 2>/dev/null

# ELF-Binary-Drop suchen (dot-prefixed, kein Extension, self-deletes nach Start)
find /tmp -maxdepth 1 -name '.*' -not -type d 2>/dev/null

# Orphaned Prozesse prüfen: PHP-Loader + ELF laufen weiter aus Speicher
# auch nach File-Deletion (ppid=1 nach init-Adoption)
ps auxf | awk '{if ($3==1) print}'
ls -la /proc/*/exe 2>/dev/null | grep deleted

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

Wenn Marker, Drops oder orphaned Prozesse mit ppid=1 gefunden werden, die von gelöschten /tmp-Pfaden ausgeführt werden: die Maschine ist kompromittiert. Forensik-Bilder ziehen bevor die Spuren weggeräumt werden — das ELF-Binary läuft nach File-Deletion weiter aus dem Speicher.

Pfad 3 — Credential-Rotation

Bei Treffer ist der gesamte Cred-Stack zu rotieren, weil der Stealer breit greift:

• 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: alle kubeconfigs und Service-Account-Tokens auf der betroffenen Maschine
• SSH-Keys: alle Private-Keys (Knock-on-Effekt: Server-Zugänge, Deployment-Targets)
• HashiCorp-Vault: alle Tokens, die in der Vault-CLI-Auth-Cache lagen
• Browser-Passwörter und Password-Manager-Vaults: Master-Passwörter ändern, betroffene Vault-Files neu generieren

Auf Windows zusätzlich: WinSCP-Sessions, PuTTY-Sessions, Outlook-Profil-Credentials, RDP-Targets.

Pfad 4 — Network-Detection

# DNS-/Proxy-Logs nach C2-Domain durchsuchen
grep -i 'flipboxstudio' /var/log/squid/access.log
grep -i 'flipboxstudio' /var/log/named/queries.log

# Outbound-Connections auf den Build-Agenten der letzten 72 h
journalctl --since "2026-05-21" | grep -i 'flipboxstudio'

Falco/Tetragon-Rule (Kurzform) für DNS-Auflösungen auf den 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

Pfad 5 — Composer-Audit als Pre-Deploy-Gate

composer audit --format=plain

Die Friends-Of-PHP-Datenbank zieht die manipulierten Tags nach, sobald die GHSA-Advisories veröffentlicht sind. Bis dahin: SBOM (CycloneDX) gegen die StepSecurity-Imposter-Commit-Liste abgleichen.

Pfad 6 — Lockfile vorübergehend auf vor-22.-Mai-Stand zurücksetzen

Wenn ein sauberer Lockfile-Stand von vor dem 22. Mai 2026 (23:41 UTC) im Git-History verfügbar ist (typischerweise der letzte erfolgreiche Production-Deploy), reicht ein git checkout <commit> -- composer.lock plus composer install, um einen sicheren Zustand wiederherzustellen. Wer kontinuierliche Updates fährt, prüft den letzten Lockfile-Commit-Hash gegen das Welle-Fenster.

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

Indicators of Compromise — Postinstall-Welle (Socket)

Composer-Tree-Inventur (allgemein für Plattform-Betreiber)

# Anwendungen mit Laravel-Lang im Tree finden (jetzt vier Pakete)
find . -name composer.json -exec grep -l 'laravel-lang/' {} \;

# Versions-Stand pro Anwendung
find . -name composer.lock -exec grep -A 1 'laravel-lang/' {} \;

# Imposter-Commit-Autor in lokalem Git-Klon prüfen
git log --format='%H %ae %s' | grep 'you@example.com'

# Socket-Welle: Branch-Tracking-Constraints im eigenen Tree finden
find . -name composer.json -exec grep -E '"(dev-main|dev-master|[0-9]+\.x-dev)"' {} \;

# Cross-Ecosystem: package.json in Composer-Vendor-Bäumen
find vendor -name package.json -exec grep -l '"postinstall"' {} \;

Process-Hunting auf Build-Agenten (Linux)

# Orphaned Prozesse mit ppid=1 die von /tmp ausgeführt werden
ps auxf | grep -E '(ppid=1|/tmp/)'

# Prozesse die von gelöschten Pfaden laufen (deleted)
ls -la /proc/*/exe 2>/dev/null | grep deleted

# ELF-Binary-Drop suchen (dot-prefixed, kein Extension)
find /tmp -maxdepth 1 -name '.*' -not -type d 2>/dev/null

# PHP-Loader-Drop und Marker
find /tmp -type d -name '.laravel_locale' 2>/dev/null
find /tmp -path '*/.laravel_locale/*' 2>/dev/null

CI-Pipeline-Spuren

# Welche Pipelines haben seit dem 22. Mai 2026 (ab 23:41 UTC) einen Composer-Pull gefahren?
gh run list --created '>=2026-05-22' --workflow ci.yml

# Socket-Welle: Outbound-Connections auf parikhpreyash4-GitHub-Release-URLs
grep -i 'parikhpreyash4/systemd-network-helper' /var/log/squid/access.log

# Drop-Pfad prüfen
ls -la /tmp/.sshd 2>/dev/null && echo 'TREFFER: /tmp/.sshd vorhanden'

Operational Decision Block

• Sofort handeln, wenn … ein Build seit dem 22. Mai 2026 (ab 23:41 UTC) mit laravel-lang/lang, /attributes, /http-statuses oder /actions im Tree gegen Packagist gepullt hat oder ein Composer-Tree eine Branch-Tracking-Version (dev-main, dev-master, 3.x-dev) eines der 8 Socket-genannten Pakete enthält: Credential-Rotation, Composer-Cache löschen, Marker-File-Scan, /tmp/.sshd-Prüfung.
• Vorsichtsmaßnahme, wenn … Laravel-Lang im Tree ist, der letzte Pull aber vor dem 22. Mai 2026 lag: Lockfile-Pinning prüfen, composer install ohne update erzwingen, SBOM gegen die Aikido-Versionsliste vergleichen.
• Aussetzen empfohlen, solange … die Maintainer die Tag-Auflösungs-Spur noch aufräumen und die Friends-Of-PHP-Datenbank die manipulierten Versionen nicht voll abdeckt: keine Composer-Updates für betroffene Projekte fahren. Für Branch-Tracking-Pakete gilt grundsätzlich: nicht in Production verwenden.
• Nicht aufschiebbar: keine wirksame Workaround-Mitigation außer Pull aussetzen und Cache leeren.

Mittelstand (Laravel-Plattformen)

Wer Laravel-Projekte produktiv betreibt und Laravel-Lang nutzt: Updates aussetzen, Pull-Fenster prüfen, Credential-Rotation für betroffene Build-Agenten und Entwickler-Maschinen. Wer Renovate/Dependabot mit Auto-Merge betreibt, pausiert den Auto-Merge bis zur Maintainer-Klärung.

Enterprise (mit Multi-Mandanten-Builds)

Zentrales SBOM-Audit über alle Mandanten gegen die Aikido-Versionsliste, Build-Agent-Pool-Inventur auf Marker-Files, Token-Audit-Logs der Cloud-Anbieter auf ungewöhnliche AssumeRole-/GetSessionToken-/iam:*-Aktivität seit dem 22. Mai 2026. Vault-Tokens mit Audit-Log-Aktivität rotieren. Parallel: package.json-Inventur in Composer-Vendor-Bäumen (Socket-Pattern) und .github/workflows/*.yml-Scan auf das gleiche Shell-Command-Pattern.

Kubernetes / containerisierte Setups

Wenn ein Build-Agent mit kubeconfig-Zugriff betroffen war: alle kubeconfigs auf dem Agenten als kompromittiert behandeln, betroffene Service-Account-Tokens im Cluster rotieren, Audit-Log auf ungewöhnliche API-Calls seit dem 22. Mai prüfen.

Deklarative Stacks (NixOS, Talos, Flatcar mit Wolfi-Images)

Image-Rebuild gegen ein bereinigtes composer.lock, neuer Image-Tag, gestaffelter Rollout. Die Pull-Schicht der Wolfi-Images ist signaturgeprüft, aber die Build-Schicht innerhalb des Images, die composer install fährt, ist genauso anfällig wie jede andere Composer-Build-Schicht.

Stand 23. Mai 2026 abends: nach Erscheinen des Aikido-Reports habe ich alle Composer-Update-Pipelines auf den Laravel-Projekten ausgesetzt — Renovate-Auto-Merge dort angehalten, geplante Wartungsfenster-Pulls verschoben. Laravel kommt bei mir nur in kleineren Projekten zum Einsatz, das macht den Auditing-Umfang überschaubar.

Der Audit ist durchgelaufen, mit negativem Befund:

• CI-Log-Audit: auf den Laravel-Projekten gab es zwischen 22. und 23. Mai 2026 keine ausgeführten Composer-Update-Operationen. Das Welle-Fenster wurde nicht durchlaufen.
• Lockfile-Diff: die Laravel-Lang-Versionen in den composer.lock-Ständen der betroffenen Projekte sind auf alten, sauberen Versionen aus der Zeit vor dem 22. Mai. Ein Diff gegen die aktuelle GitHub-Tag-Liste zeigt keine Versionen, die nach der Aufräumarbeit aus dem Tag-Index verschwunden sind.
• Build-Agent-Inventur: das tmp-Verzeichnis der Build-Agenten enthält keine .laravel_locale-Marker, der Composer-Cache wurde vorsorglich geleert. Zusätzlich: kein /tmp/.sshd auf den Agenten (Socket-IoC).
• Outbound-DNS-Logs: keine Auflösungen von flipboxstudio.info in den DNS- und Proxy-Logs der Build-Infrastruktur über den 22.–23. Mai. Auch keine Auflösungen auf GitHub-Releases-Pfade von parikhpreyash4/systemd-network-helper-aa5c751f (Socket-IoC).
• Socket-Pakete-Check: keines der 8 Socket-genannten Pakete (silverstripe-cms-theme, crosierlib-base, devdojo/wave, devdojo/genesis, katanaui/katana, elitedevsquad/sidecar-laravel, r2luna/brain, baskarcm/tzi-chat-ui) findet sich in einem der von mir betreuten Composer-Trees. Branch-Tracking-Composer-Versionen sind in meinen Production-Plattformen ohnehin nicht im Einsatz.

Composer-Updates für die Laravel-Projekte bleiben vorerst weiter ausgesetzt, bis eine vollständige Versions-Liste der manipulierten Tags (Aikido Intel Feed oder GHSA-Advisory) publiziert ist und Friends-Of-PHP die Welle in composer audit abdeckt. Renovate-Auto-Merge wird frühestens danach reaktiviert; ein gezielter manueller Update-Lauf im Wartungsfenster ist denkbar, wenn vorher die genaue Range der zurückgezogenen Versionen feststeht.

Strukturhinweis aus diesem Vorfall: die Tag-Injection-Methode ist neu in der Composer-Welt (im npm-Universum gab es vergleichbare Pattern in 2025). Anders als bei klassischen Maintainer-Account-Übernahmen reicht Code-Review nicht — die Auflösung von Tag → Commit-Hash → Tree-Membership muss verifiziert werden. Das ist heute in der Standard-Composer-Pipeline nicht automatisiert. Eine zentrale, sprachübergreifende Konvention zu erzwingen, dass Tags nur auf Commits aus dem Default-Branch des offiziellen Repos zeigen dürfen, wäre eine strukturelle Antwort — sie liegt bei GitHub und den Paketmanager-Registries, nicht bei den einzelnen Maintainern.

Reflektion über das eigene Vorgehen: ich untersuche im Nachgang dieses Vorfalls, ob bei der Paket- und Extension-Entwicklung die Regel „Libraries tracken kein Lockfile“ noch angemessen ist. Composer-Tradition (und npm-Tradition) ist es, dass Libraries kein composer.lock bzw. package-lock.json im Git mitführen — die Lock-Datei wird pro Application gepflegt, nicht pro Library, weil Constraint-Ranges ohnehin auf der konsumierenden Seite aufgelöst werden. Der Laravel-Lang-Vorfall zeigt allerdings: in einer Welt, in der Tag-Injection auf der GitHub-Schicht möglich ist und Composer-Caches die Tarball-Hashes nicht erneut gegen den Repo-Stand validieren, ist Lockfile-Hash-Pinning auf Application-Ebene die zuverlässigste Bremse — und ein Library-Repository, das selbst kein nachvollziehbares Lockfile pflegt, kann seinen eigenen produktiv getesteten Dependency-Stand nicht eindeutig dokumentieren. Ich prüfe die Frage offen, ohne vorgefasste Antwort: für Anwendungen bleibt die Regel klar (Lockfile mit Integrity-Hash committen), für meine eigenen Libraries und TYPO3-Extensions ist die Linie konventionsbedingt anders, und der Vorfall ist Anlass, diese Linie kritisch zu hinterfragen.

Die Laravel-Lang-Tag-Injection ist nicht der größte Composer-Vorfall der letzten Wochen — die intercom-php-Welle Ende April hatte mit über 20 Millionen Lifetime-Installs die breitere Reichweite, und die npm-Shai-Hulud-Reihe spielt durch ihre Worm-Mechanik ohnehin in einer anderen Liga. Aber sie ist strukturell besonders aufschlussreich: der erwartete Repository-Zustand kann sauber wirken, während die Manipulation über rewritten Git-Tags und die anschließend von Packagist ausgelieferte Referenz in die Supply Chain gelangt. Der Trigger ist nicht zwingend ein expliziter Lifecycle-Hook, sondern kann die normale Composer-Autoload-Schicht sein. Wer bisher composer install --ignore-scripts als ausreichende Schutzlinie gegen Supply-Chain-Angriffe verstanden hat, hat jetzt einen ziemlich klaren Datenpunkt, dass diese Annahme zu eng ist.

Der parallele Socket-Vorfall vom selben Tag verschärft das Bild von einer anderen Seite. Während Laravel-Lang die Tag-Auflösungs-Schicht zwischen GitHub und Packagist anfasst, treffen die acht von Socket gemeldeten Composer-Pakete den Branch-Tracking-Mechanismus — dev-main, dev-master, 3.x-dev als Versionen, die per Definition nicht immutable sind, plus den Cross-Ecosystem-Reviewer-Blindspot: malicious code in package.json, nicht in composer.json. Dass dasselbe Payload-Pattern in .github/workflows/*.yml-Files reproduziert wurde, ist die dritte Schicht. Beide Vorfälle sind keine unabhängigen Einzelfälle, sondern zwei Spielarten desselben Strukturproblems: das Composer-Vertrauensmodell stützt sich auf die ausgelieferte Referenz, nicht auf eine kryptografisch unveränderliche Versionsbindung. Solange diese Schicht nicht repariert ist, bleibt Lockfile-Hash-Pinning auf Application-Seite die zuverlässigste Bremse — und genau hier setzt die Reflektion an, ob die Konvention „Libraries tracken kein Lockfile“ in der eigenen Paket- und Extension-Entwicklung noch angemessen ist.