npm und Composer: Wie Supply-Chain-Angriffe funktionieren und wie du dich schützt

Ein Supply-Chain-Angriff trifft deine Anwendung nicht direkt, sondern über ein Paket, dem du vertraust. Bei npm und Composer ist das seit 2025 der Weg, über den Angreifer die meisten Systeme gleichzeitig erreichen. Schützen kannst du dich mit wenigen, aber konsequenten Maßnahmen: feste Lockfiles, keine automatischen Install-Scripts, kurzlebige Tokens, minimale Rechte in der CI und ein Plan für den Ernstfall.

Dieser Artikel zeigt, was in den großen Vorfällen der letzten 14 Monate passiert ist, was die Muster dahinter sind und welche Maßnahmen wirklich helfen.

Was ist seit September 2025 passiert?

September 2025: chalk und debug. Ein Maintainer zentraler npm-Pakete fiel auf eine Phishing-Mail von der Domain npmjs.help herein. Die Angreifer veröffentlichten daraufhin manipulierte Versionen. Laut Semgrep und Check Point waren meist 18 Pakete mit zusammen rund 2 Milliarden wöchentlichen Downloads betroffen. Der Schadcode zielte auf Krypto-Wallets im Browser. Die schädlichen Versionen waren nur kurz online.

September 2025: Shai-Hulud. Kurz danach tauchte der erste selbstreplizierende Wurm im npm-Ökosystem auf. Er stahl GitHub-Tokens sowie AWS-, GCP- und Azure-Schlüssel und veröffentlichte sie in öffentlichen Repositories mit dem Namen „Shai-Hulud“. Mit den gestohlenen Tokens infizierte er weitere Pakete. GitHub hat laut eigener Aussage mehr als 500 Pakete entfernt, die US-Behörde CISA gab eine Warnung heraus.

November 2025: Shai-Hulud 2.0. Die zweite Welle lief bereits im preinstall-Schritt, also noch bevor ein Paket überhaupt fertig installiert war. Laut Wiz wurden über 25.000 GitHub-Repositories mit gestohlenen Secrets angelegt und rund 350 npm-Accounts kompromittiert. Unter den betroffenen Paketen waren laut The Register auch solche von Zapier, PostHog und Postman.

Mai 2026: TanStack. Hier lief der Angriff über die Build-Pipeline. Laut Orca Security nutzten die Angreifer einen pull_request_target-Workflow, vergifteten den GitHub-Actions-Cache und stahlen OIDC-Tokens. Laut Orca waren 373 Paketversionen in 169 npm-Paketen betroffen. Die schädlichen Pakete trugen gültige npm-Provenance. Der Herkunftsnachweis war echt, weil die Pipeline selbst übernommen war.

August 2026: ChainDrop. Microsoft beschreibt einen weiteren Wurm mit über 400 betroffenen Paketen, darunter keyv, flat-cache und cache-manager. Ein preinstall-Hook startete den Schadcode. Laut Microsoft legte er außerdem Dateien in Konfigurationspfaden von Claude und VS Code ab. Das zielt auf Entwicklerrechner, nicht nur auf Server.

Ist PHP mit Composer sicherer?

Nein. Composer hat 2026 eigene Vorfälle erlebt.

Mai 2026: Laravel-Lang. Laut Snyk waren vier Pakete betroffen, darunter laravel-lang/lang. Die Angreifer schrieben vermutlich mit einem geleakten GitHub-Token Git-Tags um. Laut Snyk waren dadurch über 700 historische Versionen kompromittiert. Der Schadcode lief über autoload.files bei jedem PHP-Request und stahl Zugangsdaten. Das Tückische: Eine Versionsnummer beweist nichts, wenn Tags nachträglich umgeschrieben werden.

Mai 2026: Packagist. Laut The Hacker News waren acht Pakete auf Packagist betroffen, darunter devdojo/wave. Der Schadcode steckte im postinstall der package.json, nicht in der composer.json. PHP-Projekte mit Frontend-Build sind also doppelt exponiert.

Welche Muster stecken dahinter?

Die Vorfälle sehen unterschiedlich aus, folgen aber denselben Mustern:

1. Gestohlene Zugangsdaten von Maintainern, per Phishing oder aus früheren Vorfällen.
2. Install-Scripts (preinstall, postinstall), die Code ausführen, bevor jemand hinschaut.
3. Übernommene Build-Pipelines, die echte, signierte Pakete mit Schadcode erzeugen.
4. Diebstahl von Secrets auf Entwicklerrechnern und in der CI, die dann den nächsten Angriff ermöglichen.

Wer diese vier Punkte adressiert, ist gegen die meisten Varianten gut aufgestellt.

Was hat sich bei npm geändert?

GitHub hat nach Shai-Hulud reagiert. Laut GitHub-Changelog wurden im November 2025 keine neuen Classic Tokens mehr ausgegeben und Schreib-Tokens zeitlich begrenzt. Am 9. Dezember 2025 wurden alle Classic Tokens widerrufen. npm login liefert seitdem nur noch Session-Tokens mit zwei Stunden Laufzeit.

Der größte Schritt ist npm 12: Install-Scripts von Abhängigkeiten laufen standardmäßig nicht mehr. Laut Socket und The Hacker News ist npm 12 seit Juli 2026 allgemein verfügbar. Das nimmt Würmern wie Shai-Hulud und ChainDrop ihren wichtigsten Startpunkt.

Wie schützt du deine Projekte?

Lockfiles verbindlich nutzen. In CI und Produktion wird nur installiert, was im Lockfile steht.

npm ci
composer install --no-dev

Install-Scripts abschalten, wo sie nicht nötig sind. Mit npm 12 ist das Standard. Auf älteren Versionen und bei Composer setzt du es bewusst:

npm ci --ignore-scripts
composer install --no-scripts

Wenn ein Paket ein Script braucht, gibst du es gezielt frei, statt allen alles zu erlauben.

Commit-Hashes statt Tags prüfen. Der Laravel-Lang-Fall zeigt: Tags können umgeschrieben werden. Composer speichert im composer.lock die Commit-Referenz. Unerwartete Änderungen daran sollten im Review auffallen.

Updates nicht sofort übernehmen. Die meisten schädlichen Versionen waren nur Stunden bis Tage online. Ein kurzer Puffer vor dem Übernehmen neuer Versionen fängt viele Vorfälle ab. Sicherheitsupdates prüfst du gezielt und spielst sie dann schnell ein.

CI-Rechte minimieren. Workflows bekommen nur die Rechte, die sie brauchen. pull_request_target mit Code aus fremden Forks ist ein bekanntes Einfallstor und sollte vermieden oder streng abgesichert werden. Veröffentlichungen laufen über Trusted Publishing statt über langlebige Tokens.

Secrets klein halten. Keine Cloud-Schlüssel mit Vollzugriff auf Entwicklerrechnern oder in der CI. Kurzlebige Tokens, getrennt nach Zweck.

Für den Ernstfall vorbereiten. Wenn ein Paket kompromittiert war, reicht ein Update nicht. Alle Zugangsdaten, die auf betroffenen Rechnern oder in der Pipeline verfügbar waren, müssen rotiert werden. Erst dann wird sauber neu installiert.

Warum betrifft das auch dein Unternehmen?

Weil fast jede Webanwendung Hunderte Pakete mitbringt, die niemand im Team einzeln kennt. Und weil die Folgen über die eigene Anwendung hinausgehen: Gestohlene Cloud-Schlüssel öffnen Datenbanken, Backups und Kundendaten. Wer Software für andere herstellt, muss aktiv ausgenutzte Schwachstellen seit September 2026 außerdem melden. Mehr dazu im Artikel zum Cyber Resilience Act.

Lücken in der Laufzeit selbst bleiben trotzdem ein Thema. Dazu passen unsere Artikel zu Node.js 20 End of Life, PHP2Shell und dem Support-Ende von PHP 8.2.

Wie HR CodeLabs dir hilft

Wir arbeiten täglich mit npm und Composer und haben die Maßnahmen aus diesem Artikel in unseren eigenen Projekten umgesetzt. So unterstützen wir dich:

• Sicherheits-Check: Wir prüfen deine Abhängigkeiten, Lockfiles, CI-Workflows und Tokens. Du siehst, wo betroffene Versionen oder riskante Einstellungen stecken.
• Update- & Wartungsservice: Wir halten Pakete kontrolliert aktuell, spielen Sicherheitsupdates zeitnah ein und überwachen neue Meldungen.
• Migration alter Versionen: Wir bringen alte Node.js-, PHP- und Paketstände auf einen Stand, der wieder Updates bekommt.
• Notfallhilfe nach Angriff: Wenn ein kompromittiertes Paket bei dir gelandet ist, helfen wir beim Eingrenzen, beim Rotieren der Zugangsdaten und beim sauberen Neuaufbau.

Mehr dazu auf der Seite Sicherheit & Wartung. Oder du buchst ein kostenloses Erstgespräch und wir schauen uns deine Pipeline gemeinsam an.