Ein harmloses Sprachpaket, das plötzlich deine Schlüssel stiehlt — genau das ist gerade passiert. Am 22. Mai wurde ein laufender Supply-Chain-Angriff auf das Laravel-Lang-Ökosystem entdeckt. Die Angreifer haben in 233 Paketversionen über mehr als 700 GitHub-Repositories einen Schadcode untergebracht, der Zugangsdaten abgreift und Code nachlädt. Wer PHP-Projekte mit Laravel baut, sollte jetzt genau hinschauen.
Worum geht es bei Laravel-Lang?
Laravel-Lang ist eine Sammlung von Lokalisierungspaketen (also Übersetzungen) für das PHP-Framework Laravel. Wichtig: Es handelt sich um Drittanbieter-Pakete, nicht um einen offiziellen Teil von Laravel selbst. Betroffen sind unter anderem laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/actions und laravel-lang/attributes — Pakete, die in vielen Projekten still im Hintergrund mitlaufen.
SCHOCK: Der Schadcode startet von selbst
Das Perfide an diesem Angriff: Der Schadcode landete nie im offiziellen Code-Verlauf der Projekte. Stattdessen nutzten die Angreifer eine GitHub-Funktion aus, um bösartige Versions-Tags zu erstellen, die auf Commits in einem von ihnen kontrollierten Fork zeigen. Zieht ein Entwickler diese Pakete über Packagist/Composer, wird die manipulierte Datei src/helpers.php beim Laden automatisch ausgeführt — dank Composers autoload.files-Mechanismus. Es braucht also keinen aktiven Aufruf; allein das Einbinden reicht.
GEFAHR: Was der Stealer alles mitnimmt
Der eingeschleuste, plattformübergreifende PHP-Stealer durchsucht das infizierte System systematisch und greift unter anderem ab:
- Cloud-Zugangsschlüssel für AWS, Google Cloud, Azure und DigitalOcean
- Infrastruktur-Konfigurationen wie Kubernetes-Profile und Docker-Tokens
- Entwickler-Geheimnisse: SSH-Schlüssel, Git-Zugangsdaten und CI/CD-Tokens
- Gespeicherte Browser-Passwörter, Passwort-Manager-Daten und Krypto-Wallets
Für eine Entwickler-Workstation oder einen CI-Server ist das ein Worst-Case-Szenario: Mit gestohlenen Cloud-Keys und CI-Tokens lassen sich ganze Infrastrukturen kapern.
So reagierst du RICHTIG
- Abhängigkeiten prüfen: Schau in deine composer.lock und prüfe, ob betroffene Laravel-Lang-Pakete in verdächtigen Versionen installiert sind.
- Saubere Versionen erzwingen: Packagist hat die bösartigen Versionen entfernt und betroffene Pakete vorübergehend ausgeblendet — aktualisiere bzw. fixiere auf eine geprüfte, saubere Version.
- Zugangsdaten rotieren: Wenn der Verdacht besteht, dass ein betroffenes Paket installiert war, rotiere ALLE potenziell abgegriffenen Schlüssel und Tokens.
- CI-Logs checken: Sieh nach ungewöhnlichen ausgehenden Verbindungen während der Builds.
EXTRA-TIPP: Tags sind kein Vertrauensanker
Die Lehre aus diesem Fall: Ein Git-Tag ist verschiebbar und sagt allein nichts über die Echtheit des Codes aus. Setze auf gepinnte Versionen mit Integritäts-Prüfung, beobachte deine Lieferkette aktiv und gib CI-Runnern nur die minimal nötigen Rechte. So begrenzt du den Schaden, falls doch mal ein Paket kippt.
FAZIT: Kurz prüfen, viel Ärger sparen
Ein Blick in die composer.lock und ggf. das Rotieren der Schlüssel kostet wenige Minuten — und kann den Unterschied zwischen „nichts passiert“ und „Cloud-Account gekapert“ ausmachen. Prüfe deine PHP-Projekte jetzt.
Häufige Fragen
Welche Pakete sind von dem Angriff betroffen?
Wie merke ich, ob ich betroffen bin?
Wie behebe ich das Problem konkret?
Warum reicht es nicht, den Code im offiziellen Repo zu prüfen?
Quellen:
The Hacker News ·
Aikido ·
Socket.dev ·
Cyber Security News
Stand: 24.05.2026. Angriff entdeckt am 22.05.2026, Packagist hat reagiert.