Supply-Chain-Angriff auf Laravel-Lang-Pakete: Wenn Open-Source-Code zur Falle wird

Angreifer missbrauchen GitHub-Versions-Tags, um Credential-Stealing-Malware über Composer-Pakete zu verbreiten – mit potenziell gravierenden Folgen für deutsche Unternehmen.

Was ist passiert – und warum sollten deutsche IT-Verantwortliche aufhorchen?

Ende Mai 2025 wurde bekannt, dass Angreifer eine raffinierte Supply-Chain-Attacke gegen die weit verbreiteten Laravel-Lang-Lokalisierungspakete durchgeführt haben. Betroffen sind Millionen von PHP-Entwicklern weltweit, die diese Pakete über den Paketmanager Composer in ihre Laravel-Projekte einbinden – darunter mit hoher Wahrscheinlichkeit auch zahlreiche Entwicklungsteams in Deutschland.

Das Perfide an diesem Angriff: Die Malware wurde nicht durch einen klassischen Hack der offiziellen Paket-Repository eingeschleust, sondern über einen Missbrauch von GitHub-Versions-Tags. Dadurch konnten Angreifer bösartigen Code verteilen, ohne dass offizielle Prüfmechanismen sofort anschlugen. Das Ziel: Zugangsdaten stehlen – von Entwicklermaschinen, CI/CD-Pipelines und Produktivsystemen.

Für deutsche Unternehmen ist dieser Vorfall aus mehreren Gründen brisant:

• Laravel ist eine der meistgenutzten PHP-Frameworks – auch hierzulande in zahlreichen Web-Applikationen, E-Commerce-Systemen und internen Tools im Einsatz.
• Gestohlene Credentials können als Einfallstor für weitreichende Angriffe auf Unternehmensinfrastrukturen dienen.
• Unter NIS2 müssen betroffene Unternehmen solche Sicherheitsvorfälle unter Umständen innerhalb von 24 Stunden melden.

Technischer Hintergrund: So funktioniert der Angriff

Der Angriffsvektor: GitHub Tags und Composer

Laravel-Lang ist ein beliebtes Open-Source-Projekt, das Übersetzungsdateien für das Laravel-Framework bereitstellt. Es wird über Packagist – das zentrale PHP-Paket-Repository – und den Paketmanager Composer in Projekte eingebunden. Täglich zählen diese Pakete Hunderttausende von Downloads.

Der Angriff nutzt eine strukturelle Schwachstelle im Open-Source-Ökosystem:

1. Tag-Manipulation auf GitHub: Angreifer erlangen Zugriff auf GitHub-Repositories (z. B. durch kompromittierte Maintainer-Accounts oder durch Fork-basierte Manipulation) und erstellen oder überschreiben Versions-Tags (z. B. v12.1.0) mit Commit-Referenzen, die Schadcode enthalten.
2. Composer löst die manipulierte Version auf: Wenn Entwickler composer install oder composer update ausführen, lädt Composer die mit dem Tag verknüpfte Version herunter – inklusive des eingeschleusten Malware-Codes.
3. Ausführung des Schadcodes: Die Malware wird beim Build-Prozess oder beim ersten Ausführen der Anwendung aktiv und beginnt, Credentials zu exfiltrieren – darunter Datenbankpasswörter, API-Keys, SSH-Schlüssel und Browser-gespeicherte Zugangsdaten.

Warum sind klassische Sicherheitsprüfungen oft blind dafür?

• Pakete werden oft nicht vor der Installation auf Schadcode geprüft – Entwickler vertrauen der Integrität des Repositories.
• Checksummen-Mechanismen von Composer greifen nur dann zuverlässig, wenn eine composer.lock-Datei vorhanden und committet ist.
• CI/CD-Pipelines mit automatisierten Abhängigkeits-Updates (wie Dependabot oder Renovate) können unwissentlich kompromittierte Versionen automatisch einführen.

NIS2-Relevanz: Was bedeutet das für deutsche Unternehmen?

Betroffenheit nach BSIG (BSI-Gesetz) / NIS2-Umsetzungsgesetz

Deutschland hat die NIS2-Richtlinie der EU im Rahmen des NIS2-Umsetzungsgesetzes (NIS2UmsuCG) in nationales Recht überführt. Für Unternehmen in wesentlichen und wichtigen Einrichtungen – etwa aus den Bereichen Digitalinfrastruktur, IT-Dienstleistungen, Gesundheit, Energie oder Finanzwesen – gelten konkrete Pflichten:

Ein Supply-Chain-Angriff wie dieser auf Laravel-Lang kann als erheblicher Sicherheitsvorfall eingestuft werden, wenn:
- sensible Daten oder Credentials exfiltriert wurden,
- Produktivsysteme betroffen sind oder
- kritische Geschäftsprozesse beeinträchtigt wurden.

Hinweis des BSI: Das Bundesamt für Sicherheit in der Informationstechnik hat in seinem aktuellen BSI-Lagebericht wiederholt auf die wachsende Gefahr durch Supply-Chain-Angriffe hingewiesen und empfiehlt explizit den Einsatz von Software-Composition-Analysis (SCA)-Tools sowie die Pflege einer Software Bill of Materials (SBOM).

DSGVO-Dimension nicht vergessen

Falls durch gestohlene Credentials auch personenbezogene Daten kompromittiert wurden, greift zusätzlich die DSGVO (Art. 33): Eine Meldung an die zuständige Datenschutzbehörde muss innerhalb von 72 Stunden erfolgen.

Praktische Schutzmaßnahmen: Was Sie jetzt tun sollten

1. 🔍 Bestandsaufnahme: Welche Projekte nutzen Laravel-Lang?

Führen Sie unmittelbar eine Inventur aller PHP-Projekte durch, die Laravel-Lang-Pakete einbinden. Prüfen Sie, welche Versionen installiert sind und ob diese im betroffenen Zeitraum (März–Mai 2025) installiert oder aktualisiert wurden.

composer show | grep laravel-lang

Vergleichen Sie installierte Paket-Hashes mit offiziell verifizierten Werten.

2. 🔒 composer.lock committen und verifizieren

Die composer.lock-Datei ist Ihre erste Verteidigungslinie. Sie fixiert exakte Paketversionen inklusive Checksummen:

• Stellen Sie sicher, dass composer.lock in allen Repositories committet ist.
• Aktivieren Sie composer audit als Teil Ihrer CI/CD-Pipeline – seit Composer 2.4 meldet dieser Befehl bekannte Schwachstellen in Abhängigkeiten.
• Nutzen Sie composer install --no-scripts in Produktionsumgebungen, um Post-Install-Skripte zu deaktivieren, die Schadcode ausführen könnten.

3. 🛡️ Software Composition Analysis (SCA) einsetzen

Integrieren Sie SCA-Tools in Ihre Entwicklungspipeline:

• Trivy, Snyk oder OWASP Dependency-Check analysieren Open-Source-Abhängigkeiten auf bekannte Schwachstellen und verdächtige Paket-Manipulationen.
• Erstellen und pflegen Sie eine Software Bill of Materials (SBOM) – dies ist unter NIS2 und zunehmend auch für öffentliche Auftraggeber (CRA – Cyber Resilience Act) eine Anforderung.

4. 🔑 Credential-Rotation nach Vorfall

Falls eine Kompromittierung nicht ausgeschlossen werden kann:

• Rotieren Sie sofort alle Credentials, die auf betroffenen Entwickler- oder Build-Systemen hinterlegt waren: Datenbankpasswörter, API-Keys, Cloud-Zugangsdaten, SSH-Schlüssel.
• Aktivieren Sie Multi-Faktor-Authentifizierung (MFA) für alle Entwickler-Accounts, insbesondere für GitHub, Packagist und Cloud-Konsolen.
• Überprüfen Sie Audit-Logs auf ungewöhnliche Zugriffsaktivitäten.

5. 📋 Lieferketten-Sicherheitsrichtlinie etablieren

Implementieren Sie eine formale Software Supply Chain Security Policy:

• Definieren Sie einen Freigabeprozess für neue Open-Source-Abhängigkeiten (Review durch Sicherheitsteam, Bewertung des Maintainer-Reputations).
• Nutzen Sie Private Package Mirrors (z. B. Satis oder Packagist Private) für kritische Produktivsysteme, um unkontrollierte Updates zu vermeiden.
• Schulen Sie Entwickler regelmäßig zu Secure Coding und Dependency Management – der BSI-Grundschutz (SYS.1.6, CON.4) liefert hierfür geeignete Bausteine.

6. 🚨 Incident-Response-Plan vorbereiten

Stellen Sie sicher, dass Ihr Unternehmen im Ernstfall handlungsfähig ist:

• Wer ist zuständig für die NIS2-Meldung an das BSI?
• Wie schnell kann ein forensisches Team die Kompromittierung bewerten?
• Ist der BSI-Meldeprozess (über das MELDEPUNKT-Portal) bekannt und geübt?

Fazit: Open Source ist kein Freifahrtschein – Vertrauen muss verdient werden

Der Angriff auf Laravel-Lang-Pakete ist kein Einzelfall – er reiht sich ein in eine wachsende Serie von Supply-Chain-Angriffen auf populäre Open-Source-Projekte (erinnert sei an den XZ-Utils-Backdoor-Fall 2024 oder den Event-Stream-Angriff). Die Botschaft ist klar: Vertrauen in Open-Source-Pakete darf nicht blind sein.

Für deutsche Unternehmen gilt: Wer unter NIS2 fällt, ist gesetzlich verpflichtet, solche Risiken systematisch zu managen – nicht erst dann, wenn der Schaden eingetreten ist. Aber auch Unternehmen unterhalb der NIS2-Schwellenwerte tun gut daran, ihre Abhängigkeitsmanagement-Prozesse zu professionalisieren.

💡 Tipp für IT-Verantwortliche

Die manuelle Überwachung von Compliance-Anforderungen, Meldepflichten und Risikomanagement-Prozessen wird mit wachsender Bedrohungslage schnell zur Überforderung. Spezialisierte NIS2-Compliance-Software kann dabei helfen, Ihre Risikobewertungen zu dokumentieren, Lieferkettenrisiken strukturiert zu erfassen und im Ernstfall die Meldepflicht fristgerecht zu erfüllen. Informieren Sie sich über Plattformen, die BSI-Grundschutz-Anforderungen und NIS2-Pflichten in einem integrierten Workflow abbilden – das spart nicht nur Zeit, sondern schützt auch vor kostspieligen Compliance-Verstößen.

Quellen: Bleeping Computer (24.05.2025), BSI-Lagebericht 2024, ENISA Threat Landscape 2024, NIS2-Richtlinie (EU) 2022/2555, BSI-Grundschutz-Kompendium