Lieferkettenangriffe auf KI-Agenten: Härtungsleitfaden

Anfang Juni 2026 fegte ein sich selbst verbreitender Wurm durch die npm-Registry und legte binnen weniger Minuten Dutzende Microsoft-Repositorys lahm. Die Kampagne mit dem Namen Miasma zielte nicht auf Menschen, sondern auf die automatisierten Abhängigkeitsketten, die KI-Programmieragenten heute in Ihrem Namen abarbeiten. Wenn in Ihrem Stack Pakete installiert werden, ohne dass ein Mensch jede Änderung liest, betrifft Sie das unmittelbar.

Dies ist ein Härtungsleitfaden für Entwicklerinnen und Entwickler, kein Nachrichtenrückblick. Im Folgenden erfahren Sie, was tatsächlich geschah, warum der Angriff die gängigen Schutzmaßnahmen aushebelt und welche konkrete Prüfliste Sie noch heute auf Ihre eigene Pipeline anwenden können.

Was die Miasma-Welle wirklich war

Laut StepSecurity kompromittierte die erste Welle 57 npm-Pakete in mehr als 286 schädlichen Versionen, und das in einer rollierenden Kampagne von weniger als zwei Stunden (StepSecurity). In den Tagen darauf weitete sie sich stark aus. Orca Security meldete 32 offizielle @redhat-cloud-services-npm-Pakete, die mit einem Wurm zum Diebstahl von Zugangsdaten kompromittiert wurden, der automatisch während der Installation läuft (Orca Security). Phoenix Security dokumentierte, wie der Wurm Microsoft erreichte: Die Azure Functions Action und 72 weitere Repositorys wurden in rund 105 Sekunden deaktiviert, hinzu kamen 37 betroffene PyPI-Pakete (Phoenix Security). Bis Mitte Juni zählte Aikido 141 kompromittierte Pakete des KI-Agenten-Frameworks Mastra, in die eine schädliche Abhängigkeit eingeschleust worden war (Aikido).

Sicherheitsforscher ordnen Miasma als Variante der Shai-Hulud-Wurmlinie ein (Phoenix Security). Das eigentlich Lehrreiche ist das Muster: Aus einem kompromittierten Maintainer-Token wird der Diebstahl von Zugangsdaten, daraus eine automatische Neuveröffentlichung, daraus das nächste kompromittierte Token. Kein Mensch entscheidet dabei über einen einzigen Schritt.

Warum der Angriff Ihre bestehenden Schutzmaßnahmen aushebelte

Die meisten Teams gehen davon aus, dass schädlicher npm-Code in den preinstall- oder postinstall-Hooks steckt. Snyk dokumentierte, dass Miasma seinen Code stattdessen über binding.gyp und node-gyp während der Installation ausführte, also über den Pfad für native Builds, und damit die Skriptprüfung umging, auf die sich viele Werkzeuge und Entwickler verlassen (Snyk). Ein Paket kann einen Lockfile-Vergleich und eine Skriptprüfung bestehen und Ihre Maschine trotzdem in dem Moment übernehmen, in dem es kompiliert wird.

Für ein Vertrauen, das auf Herkunftsnachweisen beruht, wird es noch heikler. Unit 42, die Forschungsabteilung von Palo Alto Networks, berichtete über Zugangstechniken in dieser Welle, die ganz ohne gestohlene Zugangsdaten auskommen, sowie über die ersten schädlichen npm-Pakete mit gültigem SLSA-Herkunftsnachweis (Unit 42). Wer SLSA-Attestierungen als grünes Licht verstanden hat, dem genügt dieses Signal allein nicht mehr.

Der eigentliche Hebel liegt im Agenten selbst. StellarCyber beschreibt die nächste Eskalationsstufe: Angreifer nutzen kompromittierte interne Agenten, um Anfragen von innen heraus anzustoßen, und umgehen so die Skepsis, die Teams üblicherweise externer Kommunikation entgegenbringen (StellarCyber). Ein autonomer Agent, der einen Pull Request zur „Abhängigkeitsoptimierung“ öffnet, genießt Vertrauen, gerade weil er zu Ihnen gehört. Genau dieses Vertrauen ist die Angriffsfläche. Wir haben bereits darüber geschrieben, wie Sie prüfen, was Ihre Agenten überhaupt dürfen; diese Welle zeigt, warum diese Prüfung nicht optional sein darf.

Wie der Wurm in Ihre Agenten-Pipeline gelangt

Es lohnt sich, die Schleife von Anfang bis Ende nachzuvollziehen, denn die Verteidigung sitzt an genau einem Glied dieser Kette. Zuerst erbeutet ein Angreifer das Veröffentlichungs-Token eines Maintainers; Unit 42 verwies auf Varianten dieser Welle, die gar keine gestohlenen Zugangsdaten benötigten, was diesen Schritt nur verkürzt (Unit 42). Zweitens veröffentlicht der Wurm eine manipulierte Patch-Version eines beliebten Pakets. Drittens führt Ihre Pipeline oder ein darin arbeitender Agent eine Installation aus und zieht diese Version, weil ein flexibler Versionsbereich sie zuließ. Viertens läuft der schädliche Code während des nativen Build-Schritts, nicht über einen Skript-Hook, weshalb eine Skriptprüfung ihn durchwinkte (Snyk). Fünftens sammelt er sämtliche in der Umgebung vorhandenen Zugangsdaten ein, genau das Verhalten, das Orca bei den Red-Hat-Paketen beobachtete (Orca Security). Sechstens veröffentlicht er sich mit diesen gestohlenen Token erneut, und die Schleife beginnt von vorn.

Jeder dieser Schritte lässt sich automatisieren, weshalb StepSecurity für die erste Welle 57 kompromittierte Pakete in unter zwei Stunden maß. Ein Mensch in dieser Schleife ist eine Reibung, die der Wurm nicht einkalkulieren kann. Die folgende Prüfliste ist im Grunde nichts anderes als eine Sammlung von Stellen, an denen Sie diese Reibung kostengünstig wieder einbauen.

Die Härtungs-Prüfliste für Entwickler

Wenden Sie diese Punkte auf Ihren eigenen Stack an. Nichts davon erfordert einen neuen Anbieter.

1. Alles fixieren, mit eingefrorenem Lockfile prüfen. Flexible Versionsbereiche lassen eine vom Wurm veröffentlichte Patch-Version bei der nächsten Installation zu Ihnen gelangen. Fixieren Sie exakte Versionen und lassen Sie die CI bei jeder Abweichung im Lockfile scheitern.
2. Lifecycle- und Build-Skripte standardmäßig deaktivieren. Setzen Sie ignore-scripts=true (npm) oder das Äquivalent und geben Sie nur die wenigen Pakete ausdrücklich frei, die wirklich native Builds brauchen. Das entschärft sowohl den postinstall- als auch den binding.gyp-Ausführungspfad.
3. In einer Sandbox installieren, nicht auf dem Entwicklerrechner. Geben Sie Ihren Agenten und CI-Runnern eine flüchtige, netzwerkbeschränkte Umgebung ohne dauerhaft hinterlegte Zugangsdaten. Ein Wurm, der während der Installation läuft, sollte in einem Container landen, der wenige Minuten später wieder zerstört wird und keinen Weg zurück zu Ihrer Registry oder Cloud hat. Auch die Filterung des ausgehenden Datenverkehrs zählt hier: Eine Schadlast, die weder nach Hause telefonieren noch eine neue Version hochladen kann, setzt die Schleife nicht fort, selbst wenn sie ausgeführt wird.
4. Geheimnisse aus dem Installationskontext entfernen. Der Diebstahl von Zugangsdaten funktioniert nur, wenn Zugangsdaten vorhanden sind. Halten Sie Registry-Token, Cloud-Schlüssel und CI-Geheimnisse aus jeder Umgebung heraus, in der nicht vertrauenswürdige Installationen laufen.
5. Machen Sie einen Menschen zum Freigabepunkt für Abhängigkeitsänderungen. Jede von einem Agenten erzeugte Änderung an package.json, an einem Lockfile oder einer Build-Konfiguration erhält eine verpflichtende menschliche Prüfung. Das ist die eine Kontrolle, um die herum die gesamte Welle gebaut wurde. Es ist dieselbe Disziplin an der Vertrauensgrenze, die ohnehin den Schreibzugriff von Agenten regeln sollte.
6. Eingeschleuste Konfigurationsdateien in geforkten und geklonten Repositorys prüfen. Behandeln Sie eingecheckte Agenten-Konfiguration, also alles, was Anweisungen automatisch in einen Programmieragenten lädt, als ausführbaren Code. Prüfen Sie sie bei jedem Fork und jedem Klon, bevor ein Agent sie liest.
7. Überlassen Sie das Urteil nicht allein einem Scanner. Endor Labs weist darauf hin, dass regelbasierte SAST mit den Mustern, die KI-Assistenten erzeugen, nicht Schritt halten kann und dass KI-gestützte Analyse nötig ist, um KI-spezifische Risiken zu erkennen (Endor Labs). Nutzen Sie die Werkzeuge, koppeln Sie sie aber mit dem menschlichen Freigabepunkt von oben.

Der rote Faden: Geschwindigkeit ohne Kontrollpunkt ist die Schwachstelle. Dieselbe ingenieurmäßige Disziplin, die echte Agentenarbeit vom Vibe Coding trennt, verhindert, dass sich ein selbstverbreitender Wurm über Nacht durch Ihre Pipeline aufschaukelt.

Was das für KI-native Teams bedeutet

Die unbequeme Erkenntnis ist, dass die Geschichte über Produktivität und die Geschichte über Risiko ein und dieselbe sind. Ein Agent, der Abhängigkeiten installiert, Pull Requests öffnet und seine eigene Arbeit zusammenführt, ist schnell, weil kein Mensch beteiligt ist, und genau diese fehlende Verzögerung nutzt ein Wurm, um sich zu verbreiten, bevor jemand eine Änderung prüft. Sie lösen das nicht, indem Sie jeden Agenten ausbremsen, sondern indem Sie einen bewussten menschlichen Kontrollpunkt an die Stelle mit der größten Hebelwirkung setzen: das Zusammenführen von Abhängigkeiten. Wenn Sie Agenten-Pipelines bauen, die schnell und widerstandsfähig sein sollen, ist das genau die Architekturarbeit, bei der unser Team Unternehmen unterstützt. Governance auf der Laufzeitebene, das Thema jüngster Veröffentlichungen rund um die Governance von Agenten-Laufzeiten, wird zur Grundvoraussetzung, nicht zum Komfortmerkmal.

Häufig gestellte Fragen

Was ist ein Lieferkettenangriff auf KI-Agenten? Es ist ein Angriff, der die Open-Source-Pakete, Build-Schritte oder Konfigurationsdateien kompromittiert, die autonome Programmieragenten automatisch installieren und denen sie vertrauen. Der Miasma-Wurm verbreitete sich im Juni 2026 über npm und traf Red Hat, Microsoft Azure und das Mastra-Framework (Aikido).

Wie entging der Miasma-Wurm der Entdeckung? Er führte seinen Code während der Installation über binding.gyp und node-gyp aus statt über die preinstall-/postinstall-Skripte, die die meisten Scanner überwachen, sodass Pakete bis zum Kompilieren sauber wirkten (Snyk).

Schützt mich ein SLSA-Herkunftsnachweis davor? Nicht für sich allein. Unit 42 meldete die ersten schädlichen npm-Pakete mit gültigem SLSA-Herkunftsnachweis, sodass die Attestierung notwendig, aber kein hinreichendes Signal für Sicherheit mehr ist (Unit 42).

Warum sind KI-Programmieragenten ein größeres Ziel? Agenten installieren und führen Änderungen mit dem Vertrauen der eigenen Organisation zusammen und umgehen so die Skepsis gegenüber externen Quellen, wodurch sich ein Wurm verbreiten kann, bevor ein Mensch ihn prüft (StellarCyber).

Welche Kontrolle ist die wichtigste? Eine verpflichtende menschliche Prüfung jeder von einem Agenten erzeugten Änderung an package.json, Lockfiles oder Build-Konfigurationen. Es ist der eine Kontrollpunkt, um den herum die gesamte Welle gebaut wurde.

Fazit

Die Miasma-Welle war kein Ausreißer, sondern eine Vorschau darauf, wie Lieferkettenangriffe funktionieren, wenn Verteidiger und Angreifer mit Maschinengeschwindigkeit agieren. Die Verteidigung besteht nicht aus mehr Automatisierung. Sie besteht aus einem gut platzierten menschlichen Kontrollpunkt beim Zusammenführen von Abhängigkeiten, einer Installationsumgebung, in der es nichts zu stehlen gibt, und der Disziplin, jede einem Agenten anvertraute Datei als ausführbaren Code zu behandeln. Keine dieser Kontrollen bremst die Arbeit, die ein Agent gut erledigt; sie unterbricht nur den einen Schritt, den ein Wurm zum Verbreiten braucht. Bauen Sie das jetzt ein, solange es eine Prüfliste ist und kein Vorfall.

Quellen

1. StepSecurity — Miasma npm Supply Chain Attack: Self-Spreading Worm
2. Snyk — Node-gyp Supply Chain Compromise
3. Orca Security — Red Hat npm Supply Chain Attack
4. Phoenix Security — Miasma: Azure Hit, 73 Repos Down, 37 PyPI
5. Phoenix Security — Miasma: Red Hat npm, Shai-Hulud-Variante
6. Aikido — Red Hat und Mastra npm-Pakete kompromittiert
7. Unit 42 — Monitoring npm Supply Chain Attacks
8. StellarCyber — Top Agentic AI Security Threats in Late 2026
9. Endor Labs — AI Risk Reduction: Mitigation Strategies for 2026
10. The Hacker News — Miasma Compromises Red Hat npm Packages
11. Cloud Security Alliance — Miasma npm Supply Chain Research Note