Laravel Lang Supply-Chain-Warnung

Laravel-Lang-Supply-Chain-Angriff: Über 700 historische Packagist-Versionen kompromittiert

Update – 25. Mai 2026: Wir haben diesen Beitrag aktualisiert, um neue Erkenntnisse aus der laufenden Untersuchung aufzunehmen. Das Update erläutert den Kompromittierungsmechanismus genauer, ersetzt frühere Verweise auf einen Veröffentlichungsprozess auf Basis eines Forks und ergänzt Hinweise für Composer-/Packagist-Nutzer dazu, wie sie feststellen können, ob ein Projekt betroffen war. Da die betroffenen Versionsnummern später wieder legitimen Code zugeordnet wurden, reichen Versionsnummern allein möglicherweise nicht aus, um die Auswirkungen zu bestätigen. Snyk-Kunden sollten den Abschnitt „Erkennung des Laravel-Lang-Supply-Chain-Angriffs mit Snyk“ lesen, um die aktualisierten Hinweise zu Scans, Triage und Behebung zu erhalten.

Kurzfassung

Am 22. und 23. Mai 2026 veröffentlichte ein Angreifer Hunderte schädliche Versionen unter historischen Release-Tags von vier Community-gepflegten Laravel-Lokalisierungsbibliotheken, die unter dem laravel-lang-Namespace auf Packagist veröffentlicht werden.

Eine eingeschleuste Datei helpers.php wurde in den Composer-Eintrag autoload.files eingebunden. Dadurch wurde sie bei jeder PHP-Anfrage ausgeführt, sobald das Paket installiert war. Dieser Hook stellt eine Verbindung zu flipboxstudio[.]info her, lädt eine plattformübergreifende zweite Stufe herunter und führt einen Zugangsdaten-Stealer aus, der Cloud-Schlüssel, Kubernetes- und Vault-Geheimnisse, CI/CD-Token, SSH-Material, Umgebungsdateien, Browserdaten, Tresore von Passwort-Managern, Krypto-Wallets und Messaging-Token ausliest.

Jede Umgebung, in der eine der betroffenen Versionen der Laravel-Lokalisierungsbibliothek installiert wurde, sollte bis zum Gegenbeweis als kompromittiert gelten.

Zum betroffenen Bestandteil

Die betroffenen Pakete befinden sich im laravel-lang/*-Namespace auf Packagist und GitHub.

Die Laravel-Community verwendet sie häufig, um Übersetzungszeichenfolgen, Validierungsmeldungen, HTTP-Statusbeschreibungen und ähnliche lokalisierte Ressourcen in mehr als siebzig Sprachen bereitzustellen.

Sie werden nicht vom Laravel-Core-Team gepflegt und sind kein Bestandteil des offiziellen Laravel-Frameworks. Dennoch werden sie im typischen Laravel-Anwendungsverzeichnis installiert und tauchen häufig als transitive Abhängigkeiten in anderen Lokalisierungs-Helpers auf. Da die Pakete über Composer bezogen und über composer.json registriert werden, wird jeder darin enthaltene schädliche Code automatisch von der Laufzeitumgebung der Anwendung geladen und ausgeführt.

Betroffene Pakete

Alle veröffentlichten Versionen der folgenden vier Pakete gelten als kompromittiert. Packagist hatte die Pakete vorübergehend aus der Liste genommen. Nach der Behebung sind sie nun wieder gelistet.

Frühere Schätzungen von Forschenden bezifferten die Zahl der manipulierten Versionen auf etwa 233. Diese Zahl stieg jedoch weiter, als der Angreifer zusätzliche Tags veröffentlichte. Aktuelle Berichte sprechen von rund 700 historischen Versionen der vier Pakete.

Bekannter Zeitablauf

Wie es zur Kompromittierung kam

Der Angreifer verschaffte sich über ein geleaktes GitHub Personal Access Token (PAT) Zugriff auf die kompromittierten Repositorys. Vermutlich stammte dieses Token aus einer jüngsten GitHub-Datenpanne. Mit diesem Zugriff ersetzte der Angreifer viele oder alle Release-Tags in vier laravel-lang/-Repositorys durch schädliche Imitate, die auf eigene, Malware enthaltende Commits verwiesen. Die übrigen legitimen Repositorys und alle früheren Commits blieben während der gesamten Kompromittierung bestehen.

Sobald ein schädlicher Tag vorhanden war, lud jede neue Composer-Installation, bei der eine der betroffenen Versionen aufgelöst wurde, den Code des gefälschten Commits herunter. Die Nutzlast war in einer neu hinzugefügten Datei, src/helpers.php, versteckt und in composer.json unter autoload.files registriert. Composer lädt alle Dateien in dieser Liste bedingungslos ein. Der schädliche Code wird daher gleich zu Beginn des PHP-Anfragezyklus ausgeführt, auch bei Befehlen, Hintergrundprozessen und Queue-Handlern.

Funktionsweise der Nutzlast

Die in src/helpers.php eingebettete erste Stufe ist bewusst schlank gehalten. Sie schreibt eine Infektionsmarkierung in ein temporäres Verzeichnis auf dem jeweiligen Host, damit dieser nur einmal infiziert wird. Anschließend ruft sie eine zweite Stufe von https://flipboxstudio\[.\]info/payload ab und führt diese im Hintergrund aus. Der Starter berücksichtigt die jeweilige Plattform und funktioniert unter Linux, macOS und Windows.

Die zweite Stufe ist ein Stealer für Zugangsdaten und Geheimnisse. Nach dem Einschleusen durchsucht er zahlreiche Quellen nach wertvollen Informationen:

• Zugangsdaten und Token von Cloud-Anbietern (zum Beispiel AWS-, GCP- und Azure-Profildateien).

• Kubernetes-kubeconfig-Dateien, HashiCorp-Vault-Token und in der Umgebung vorhandene CI/CD-Geheimnisse.

• Private SSH-Schlüssel und known_hosts-Daten.

• Anwendungsdateien vom Typ .env mit Datenbank-, API- und Dienstzugangsdaten.

• Browserdaten, darunter Cookies, Verlauf und gespeicherte Anmeldedaten.

• Tresore von Passwort-Managern, auf die lokal zugegriffen werden kann.

• Dateien und Keystores von Kryptowährungs-Wallets.

• Messaging- und Kollaborations-Token für Tools wie Slack, Discord und Telegram.

Die erfassten Daten werden verschlüsselt und an https://flipboxstudio\[.\]info/exfil übertragen. Nach der Exfiltration versucht der Stealer, seine abgelegten Dateien zu löschen, um die forensische Wiederherstellung zu erschweren. Auf Windows-Hosts umfasst die Infektionskette ein .vbs-Starter-Skript und eine ausführbare Datei namens DebugChromium.exe, die auf infizierten Systemen beobachtet wurde.

Kompromittierungsindikatoren

Nutzen Sie die folgenden Indikatoren, um nach betroffenen Systemen zu suchen. Die C2-Domain und URLs sind als schädlich einzustufen.

Hinweise zu Erkennung und Scans

Betrachten Sie jeden Host, auf dem zwischen dem 22. und 23. Mai 2026 eines der vier Pakete aufgelöst wurde, als verdächtig – auch wenn er inzwischen neu aufgesetzt wurde. Der schnellste Hinweis findet sich auf Abhängigkeitsebene: Prüfen Sie composer.lock und composer.json in all Ihren Projekten auf Verweise auf die oben aufgeführten laravel-lang-Pakete. Hier sind einige konkrete Prüfungen.

• Durchsuchen Sie Build- und Deployment-Artefakte nach laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes oder laravel-lang/actions und erfassen Sie die in composer.lock verzeichnete Version und Integritäts-Hash.

• Prüfen Sie jede installierte Kopie unter vendor/laravel-lang/*/ auf das Vorhandensein von src/helpers.php und kontrollieren Sie, ob sie in composer.json unter dem autoload-Schlüssel files aufgeführt ist. Ein legitimes Lokalisierungspaket hat keinen Grund, eine Helpers-Datei mitzuliefern, die bei jeder Anfrage automatisch geladen wird.

• Suchen Sie auf Linux- und macOS-Hosts in $TMPDIR und /tmp nach einem Verzeichnis namens .laravel_locale – jeder darin enthaltene Inhalt weist auf eine Ausführung hin. Sichern Sie die Dateien vor der Bereinigung für die forensische Analyse.

• Suchen Sie auf Windows-Hosts im temporären Benutzerverzeichnis (in der Regel %TEMP%) nach einem Ordner namens .laravel_locale mit .vbs-Droppern, deren Dateinamen aus acht zufälligen Hexadezimalzeichen bestehen. Durchsuchen Sie außerdem das Dateisystem nach einer ausführbaren Datei namens DebugChromium.exe.

• Prüfen Sie Egress-Proxy-, DNS- und Firewall-Protokolle auf Abfragen oder Verbindungen zu flipboxstudio[.]info. Sperren Sie die Domain sowohl am Resolver als auch am Netzwerkrand.

• Suchen Sie in EDR- und Endpunktprotokollen nach unerwarteten PHP- oder CScript-Prozessausführungen im Hintergrund. Überwachen Sie unter Linux und macOS zusätzlich Lesezugriffe auf /var/run/secrets/ und `/proc/[pid]/environ`, auf die der Zugangsdaten-Stealer beim Sammeln von Geheimnissen zugreift.

Klarstellung zu Hinweisen zum Ignorieren

Aufgrund der Art der Kompromittierung und der anschließenden Behebung erkennen Snyk-Systeme möglicherweise derzeit nur die zuletzt installierte Version. Kunden sollten einen historischen Scan durchführen, um festzustellen, ob das schädliche Paket zwischen dem 22. und 23. Mai 2026 jemals installiert war. Verlassen Sie sich nicht ausschließlich auf den Status der neuesten Version. Gehen Sie davon aus, dass jeder Host, auf dem während des Kompromittierungszeitraums eines der vier Pakete installiert wurde, betroffen ist, bis das Gegenteil bewiesen ist.

Erkennung des Laravel-Lang-Supply-Chain-Angriffs mit Snyk

Für Snyk-Nutzer kennzeichnen das Open Source-Produkt und die Snyk Vulnerability Database bereits alle Versionen der betroffenen Pakete. Während der Kompromittierung wurden schädliche Tags mit legitimen Versionsnummern veröffentlicht. Nach der Wiederherstellung der Projekte wurden dieselben legitimen Tags von den schädlichen Commits getrennt. Daher lässt sich anhand der Versionsnummern allein nicht feststellen, ob ein installiertes Paket von dieser Kompromittierung betroffen ist oder war. (Siehe oben die Abschnitte „Kompromittierungsindikatoren“ und „Hinweise zu Erkennung und Scans“.) Führen Sie umgehend einen Scan für alle Composer-basierten Repositorys durch und achten Sie besonders auf Monorepos und gemeinsam genutzten Plattformcode.

Wenn Sie nach Prüfung Ihrer composer.lock, des Build- oder Installationszeitpunkts und der verfügbaren Kompromittierungsindikatoren feststellen, dass Ihr Projekt nicht betroffen war, können Sie die Ignore-Funktion von Snyk verwenden, damit dieses Problem bei künftigen Scans nicht mehr angezeigt wird. Weitere Informationen finden Sie in der Snyk-Dokumentation zum Ignorieren von Problemen.

Die Snyk CLI erkennt Ihre Composer-Lockdatei automatisch und erkennt anfällige sowie schädliche Pakete:

1snyk test

Die Snyk CLI ist kostenlos. Falls Sie die Snyk CLI noch nicht installiert haben, folgen Sie der Snyk CLI-Benutzerdokumentation.

Wenn Sie Snyk mit Ihren Git-Repositorys verbinden, kann Snyk automatisch Pull Requests öffnen, um anfällige Pakete in Ihrer Datei composer.lock auf sichere Versionen zu aktualisieren.

Für Snyk Enterprise-Kunden haben wir bereits Scans in Ihrem Namen erneut ausgeführt. Sie finden die Ergebnisse unter Analytics → Reports → Zero-Day → Active Security Incident Assessment für Laravel-Lang Supply Chain Attack.

Eindämmung und Behebung

Wenn bestätigt ist, dass die betroffenen Pakete installiert wurden, gehen Sie davon aus, dass alles, worauf der PHP-Prozess zum Ausführungszeitpunkt zugreifen konnte, exfiltriert wurde, und handeln Sie entsprechend. Die folgende Reihenfolge entspricht dem typischen Ablauf einer Reaktion auf Sicherheitsvorfälle.

• Isolieren Sie betroffene Hosts. Nehmen Sie alle internetseitig erreichbaren Dienste, auf denen die betroffenen Versionen ausgeführt wurden, aus dem Betrieb, erstellen Sie für die Forensik Datenträger-Snapshots und setzen Sie die Systeme anhand eines bekanntermaßen sauberen Images neu auf, statt sie vor Ort zu bereinigen.

• Stellen Sie sicher, dass Sie die betroffene Laravel-Lang-Paketgruppe nicht beziehen (und wahrscheinlich auch keine anderen Pakete dieses Maintainers bzw. Teams). Da der Angreifer historische Git-Tags umgeschrieben hat, ist keine veröffentlichte Versionsnummer für sich genommen vertrauenswürdig; eine ältere Release-Nummer kann jetzt auf den schädlichen Commit verweisen.

• Rotieren Sie alle Zugangsdaten, auf die der PHP-Prozess möglicherweise zugreifen konnte. Dazu gehören Schlüssel von Cloud-Anbietern, Datenbankpasswörter, Zugangsdaten für Warteschlangen und Caches, API-Tokens von Drittanbietern, OAuth-Client-Secrets, SSH-Schlüssel, Signaturschlüssel, Vault- und Kubernetes-Tokens sowie alle über CI/CD injizierten Secrets.

• Überprüfen Sie die Konten von Personen, die dieselben Arbeitsstationen nutzen. Im Browser gespeicherte Anmeldedaten, Tresore von Passwort-Managern, Krypto-Wallets sowie Slack- oder Discord-Tokens könnten ebenfalls gestohlen worden sein. Ändern Sie im Browser gespeicherte Passwörter, machen Sie Sitzungen ungültig und überprüfen Sie die MFA-Registrierungen.

• Blockieren Sie die C2-Domain. Nehmen Sie flipboxstudio[.]info in DNS-Sinkholes, Proxy-Sperrlisten und EDR-Erkennungen auf. Schon ein einziger Auflösungsversuch ist ein starkes Anzeichen für eine Gefährdung.

• Überprüfen Sie die Berechtigungen für SCM und Registrys, da laravel-lang/* transitiv bezogen worden sein könnte. Stellen Sie sicher, dass Ihre eigenen Organisationen auf GitHub, GitLab und Packagist hardwaregestützte MFA und eingeschränkte Tokens verwenden und für das Erstellen von Tags und Veröffentlichen von Paketen einen Prüfschritt vorsehen.

Erkenntnisse und mehrschichtige Sicherheitsmaßnahmen

Dieser Vorfall erinnert daran, dass die Vertrauensgrenze eines Pakets nicht das Quell-Repository in Ihrem Browser-Tab ist. Sie umfasst vielmehr die Kette von Systemen, die bestimmt, welcher Commit als veröffentlichtes Artefakt bereitgestellt wird. Mit einigen Maßnahmen lässt sich der Schadensradius ähnlicher Angriffe begrenzen:

• Überprüfen Sie die Integrität bei der Installation. Composer speichert Paket-Content-Hashes in composer.lock. Verwenden Sie --no-cache und eine Integritätsprüfung in CI, damit Manipulationen sichtbar werden.

• Setzen Sie Egress-Kontrollen in Build-Umgebungen ein. CI-Runner und Produktionscontainer sollten nicht auf beliebige Domains zugreifen können. Eine Zulassungsliste hätte den Download der zweiten Stufe in diesem Fall verhindert.

• Verwenden Sie kurzlebige, eingeschränkte Secrets. Langlebige Zugangsdaten in .env-Dateien vergrößern den Schaden, den jeder Diebstahl von Secrets innerhalb eines Prozesses anrichten kann.

Die offizielle Stellungnahme des betroffenen Projekts, einschließlich der Hinweise zu GitHub, finden Sie hier: Offizielle Stellungnahme zum Vorfall.

Wir empfehlen Ihnen außerdem, Ihre Sicherheitspraktiken zu überprüfen und in einem zuvor von uns veröffentlichten Artikel zu erfahren, wie Sie das Laravel-PHP-Framework absichern. Sehen Sie sich auch die Ressource von Snyk Learn zu sicheren PHP-Entwicklungspraktiken an.

Snyk-Status

Die Produkte und die Infrastruktur von Snyk sind von diesem Vorfall nicht betroffen. Snyk-Hinweise zu den betroffenen Paketen wurden veröffentlicht. Die Snyk Vulnerability Database wird aktualisiert, sobald weitere betroffene Versionsbereiche bestätigt werden. Snyk beobachtet die Lage weiterhin und aktualisiert diesen Sicherheitshinweis, sobald weitere Details bekannt werden.