Supply-Chain-Angriff: so schützt du Kundenseiten

Anfang August 2026 ging es schnell. Innerhalb weniger Stunden tauchten in der npm-Registry Dutzende, dann Hunderte neuer Paketversionen auf – winzige „Patch"-Updates zu bekannten Bibliotheken wie keyv, flat-cache oder cache-manager, ohne zugehörige Commits, ohne Pull Requests, ohne Ankündigung. Wer in dieser Zeit ein Projekt neu baute oder Abhängigkeiten aktualisierte, holte sich mit dem harmlos wirkenden Update womöglich Schadcode ins Haus. Der als „ChainDrop" bekannt gewordene Wurm hatte zugeschlagen, ein Ableger der Schadsoftware-Familie „Shai-Hulud".

Für kleine Agenturen ist das ein unbequemes Thema, weil es einen wunden Punkt trifft: Kaum jemand baut eine moderne Website noch komplett von Hand. Du ziehst dir Bibliotheken über npm, du installierst WordPress-Plugins, du nutzt Build-Tools – und mit jedem dieser Bausteine vertraust du fremdem Code. Genau dieses Vertrauen greift ein Supply-Chain-Angriff an. Dieser Beitrag erklärt, was im August passiert ist, warum es dich betrifft, auch wenn du kein reines Entwicklerteam bist, und mit welchen konkreten Schritten du deine Kundenprojekte absicherst.

Supply-Chain-Angriff: was im August 2026 geschah

Ein Supply-Chain-Angriff zielt nicht auf deine Seite direkt, sondern auf einen Baustein, dem du vertraust – eine Programmbibliothek, ein Plugin, ein Werkzeug in deiner Entwicklungskette. Wird dieser Baustein kompromittiert, verteilt sich der Schadcode automatisch an alle, die ihn einsetzen. Der ChainDrop-Wurm führte das im großen Stil vor.

Laut Analyse von Microsoft Security wurden mehr als 400 Pakete verschiedener, voneinander unabhängiger Herausgeber kompromittiert. Betroffen waren keine Nischenprojekte: Die Bibliothek keyv etwa verzeichnete im Monat vor dem Angriff laut Snyk rund 619,7 Millionen Downloads, flat-cache etwa 579,8 Millionen. Die staatliche Cybersicherheitsbehörde Singapurs zählte in ihrer Warnmeldung insgesamt über 1.300 kompromittierte Paketversionen mit zusammen rund zwei Milliarden monatlichen Downloads. Es handelt sich also nicht um ein Randproblem, sondern um eine Verseuchung mitten im Herzen des Ökosystems, auf dem ein Großteil des modernen Webs aufbaut.

Wie sich der Wurm selbst vermehrt

Das eigentlich Perfide an ChainDrop ist der Mechanismus, der ihn so schnell machte. Nach der Beschreibung von Microsoft läuft der Angriff in einer sich selbst verstärkenden Schleife ab: Sobald die Schadsoftware auf einem Entwicklerrechner einen npm-Veröffentlichungs-Token erbeutet, listet sie alle Pakete auf, die dieser Identität gehören, lädt deren aktuelle Version herunter, schleust den Schadcode ein, hängt einen sogenannten „preinstall"-Hook an, erhöht die Versionsnummer minimal und veröffentlicht die manipulierten Pakete erneut. Aus einer einzigen kompromittierten Identität werden so im Handumdrehen viele verseuchte Releases – der Wurm vermehrt sich exponentiell.

Der „preinstall"-Hook ist dabei der Zünder. Es handelt sich um ein Skript, das npm automatisch bei der Installation eines Pakets ausführt – noch bevor deine Anwendung überhaupt startet. Bei den betroffenen Paketen genügte laut Snyk der Eintrag "preinstall": "node setup.mjs", um den Schadcode ohne jedes Zutun des Entwicklers zu starten. Ein simples npm install reichte also aus.

Was der Wurm dann sucht, ist der Zugang zu allem Weiteren: npm- und GitHub-Tokens, Zugangsdaten für Cloud-Dienste wie AWS, für Kubernetes und HashiCorp Vault, dazu SSH-Schlüssel und Kommando-Historien. Die Beute wird verschlüsselt an einen Server der Angreifer geschickt; als Ausweichkanal legt die Software laut Microsoft öffentliche GitHub-Repositorys an, erkennbar an Beschreibungen wie „Shai-Hulud: Here We Go Again". Besonders heikel: In manchen Fällen wurde der bösartige Release durch legitime GitHub-Actions-Workflows sogar kryptografisch signiert, weil die Kompromittierung schon vor dem Build-Prozess saß. Die vertrauensbildende Signatur bestätigte damit ausgerechnet den Schadcode – ein Lehrstück darüber, dass ein Echtheitssiegel nur so gut ist wie der Prozess dahinter.

Warum das auch kleine Agenturen betrifft

Vielleicht denkst du jetzt: Wir bauen vor allem WordPress-Seiten, npm ist bei uns höchstens im Hintergrund. Doch das Prinzip ist dasselbe, egal welches System du nutzt. Auch WordPress ist eine Lieferkette – jedes Plugin und jedes Theme ist fremder Code, den du in Kundenseiten einspielst. Nicht umsonst stecken 96 Prozent aller WordPress-Sicherheitslücken in Plugins, wie wir im Beitrag zur WordPress-Wartung dargelegt haben. Ein gekapertes Plugin-Update wirkt nach demselben Muster wie ein gekapertes npm-Paket.

Und wer moderne Seiten mit Build-Tools, Page-Buildern oder JavaScript-Frameworks baut, ist ohnehin direkt in der npm-Welt unterwegs – oft, ohne es täglich zu merken. Das größere Risiko für eine kleine Agentur ist dabei nicht einmal die einzelne infizierte Seite, sondern der Dominoeffekt: Erbeutet ein solcher Wurm deine Deployment-Zugänge oder Server-Schlüssel, sind mit einem Schlag alle Kundenprojekte in Reichweite, die über dieselben Zugangsdaten laufen. Aus einem Vorfall wird schnell ein Flächenbrand – ein Szenario, das den Notfallplan für gehackte WordPress-Seiten auf einen Schlag für dein ganzes Portfolio relevant macht.

So sicherst du deine Projekte ab

Die gute Nachricht: Ein paar disziplinierte Gewohnheiten senken das Risiko erheblich, und keine davon setzt ein großes Sicherheitsbudget voraus. Der wichtigste Grundsatz lautet, nicht blind die jeweils neueste Version zu ziehen. Nutze eine Lockfile (package-lock.json) und installiere in produktiven Builds mit npm ci statt npm install, damit exakt die geprüften Versionen landen und nicht automatisch das neueste, womöglich frisch kompromittierte „Patch"-Release. Ein bewusster zeitlicher Abstand zwischen Veröffentlichung und Einsatz eines Updates – ein paar Tage „Reifezeit" – fängt viele solcher Wellen ab, weil sie meist schnell entdeckt und zurückgezogen werden.

Ein zweiter Hebel sind die Installationsskripte selbst. Da der Angriff über den „preinstall"-Hook lief, kannst du diese Skripte bei der Installation unterdrücken (etwa mit npm install --ignore-scripts) und nur dort gezielt zulassen, wo ein Paket sie wirklich braucht. Ergänzend hilft ein automatischer Abhängigkeits-Check, der bekannte Schwachstellen und kompromittierte Versionen meldet, bevor sie in ein Kundenprojekt wandern.

Der dritte Punkt betrifft deine Zugänge, denn genau darauf zielt der Wurm. Bewahre Tokens und Schlüssel nicht im Klartext in Projektordnern auf, trenne die Zugänge einzelner Kunden voneinander und aktiviere überall dort die Zwei-Faktor-Authentifizierung beziehungsweise Passkeys, wo es geht – für npm-, GitHub- und Hosting-Konten. Falls du in der fraglichen Zeit betroffene Pakete installiert hast, gilt die klare Empfehlung der Behörden: die betroffenen Versionen aus allen Entwicklungs- und CI-Umgebungen entfernen, die Systeme als potenziell kompromittiert behandeln und sämtliche exponierten Zugangsdaten neu vergeben.

Nicht zuletzt lohnt ein Blick auf die Herkunft dessen, was du einbaust. Bevorzuge Pakete und Plugins mit aktiver Pflege, vielen Nutzern und nachvollziehbarer Update-Historie, und sei skeptisch bei einem „Patch"-Release, das aus dem Nichts erscheint und im gleichen Atemzug ungewöhnliche Berechtigungen oder Skripte mitbringt. Genau in diese Richtung zielt auch der Gesetzgeber: Der Cyber Resilience Act rückt die Nachvollziehbarkeit von Software-Bestandteilen – Stichwort Stückliste, englisch SBOM – in den Vordergrund. Wer heute schon dokumentiert, welche Bausteine in seinen Projekten stecken, tut damit nicht nur etwas für die Sicherheit, sondern ist auch auf kommende Anforderungen besser vorbereitet.

Die strategische Lehre für deine Agentur

Über die Technik hinaus steckt in diesem Vorfall eine Grundsatzfrage: Wie viel fremden Code willst du selbst verwalten? Jede Abhängigkeit, jedes Plugin, jeder Build-Schritt ist eine Tür, die du im Blick behalten musst. Ein bewusster, schlanker Technik-Stack mit wenigen, gut gepflegten Bausteinen ist nicht nur schneller, sondern auch sicherer als ein Sammelsurium aus Dutzenden selten aktualisierter Erweiterungen.

Für manche Bausteine lohnt es sich zugleich, die Verantwortung bewusst abzugeben. Bei gehosteten Diensten – etwa einem DSGVO-Chatbot wie Ragnova – liegt die Absicherung der Lieferkette beim Anbieter, nicht bei dir; du sparst dir damit genau die Kette aus Abhängigkeiten, die hier zum Einfallstor wurde. Wo du selbst baust, mach die Lieferketten-Hygiene zum festen Bestandteil deiner Arbeit und deines Wartungsangebots: Updates geprüft und dokumentiert einspielen, Zugänge sauber trennen, im Ernstfall schnell reagieren können. Der ChainDrop-Wurm war nicht der erste Angriff dieser Art und wird nicht der letzte sein. Wer die Grundregeln verinnerlicht, muss beim nächsten Mal nicht hektisch reagieren, sondern hat bereits vorgesorgt.