- Eine im Titel eingefügte Prompt Injection schleuste Befehle über Clines KI-basierten Bot zur Issue-Klassifizierung ein
- Durch den Diebstahl eines npm-Tokens wurde ein bösartiges Cline-Paket verteilt, das den OpenClaw-AI-Agenten ohne Genehmigung installierte
- Die Angreifer bauten eine fünfstufige Kette auf: Prompt Injection → beliebige Codeausführung durch den KI-Bot → Cache Poisoning → Diebstahl von Zugangsdaten → Verteilung eines bösartigen Pakets
- Bestehende Sicherheitskontrollen (Code-Review, npm audit, Provenance Attestations) konnten diesen Angriff nicht erkennen
- Ein Sicherheitsforscher entdeckte die Schwachstelle Ende Dezember 2025 und meldete sie, erhielt aber fünf Wochen lang keine Antwort; selbst nach der Offenlegung wurde der Angriff durch einen Fehler beim Austausch von Zugangsdaten möglich
- Es ist ein neues Muster von Supply-Chain-Bedrohungen entstanden, bei dem ein KI-Agent einen anderen KI-Agenten installiert, was die Risiken von KI-Automatisierung in CI/CD-Umgebungen unterstreicht
Überblick über den Angriff
- Am 17. Februar 2026 wurde
cline@2.3.0 auf npm veröffentlicht. Es enthielt dieselbe Binärdatei wie frühere Versionen, aber in package.json war eine zusätzliche Zeile eingefügt: "postinstall": "npm install -g openclaw@latest"
- Dadurch wurde OpenClaw bei rund 4.000 Entwicklern, die Cline innerhalb von 8 Stunden installierten oder aktualisierten, automatisch mitinstalliert
- OpenClaw ist ein separater KI-Agent mit vollständigem Systemzugriff und wurde global ohne Zustimmung des Nutzers installiert
Angriffskette (Clinejection)
- Phase 1: Prompt Injection
- Cline nutzte einen KI-Workflow zur Issue-Klassifizierung mit Anthropics
claude-code-action
- Durch die Einstellung
allowed_non_write_users: "*" konnte jeder ein Issue eröffnen und den Bot auslösen
- Am 28. Januar erstellte der Angreifer Issue #8904 mit einem Titel, der wie ein Performance-Report aussah, aber einen versteckten Befehl zur Installation eines bestimmten Pakets enthielt
- Phase 2: Ausführung des Befehls durch den KI-Bot
- Claude interpretierte den Befehl als legitime Anweisung und führte
npm install auf dem Fork des Angreifers (glthub-actions/cline) aus
- In der
package.json dieses Forks befand sich ein preinstall-Skript, das ein Remote-Shell-Skript ausführte
- Phase 3: Cache-Vergiftung (Cache Poisoning)
- Das Skript setzte Cacheract ein, um den GitHub-Actions-Cache zu vergiften
- Es schleuste mehr als 10 GB Daten ein, verdrängte legitime Cache-Einträge und fälschte den Cache-Key, den Clines Nightly-Release-Workflow verwendete
- Phase 4: Diebstahl von Zugangsdaten
- Als der Release-Workflow
node_modules aus dem vergifteten Cache wiederherstellte, wurden NPM_RELEASE_TOKEN, VSCE_PAT und OVSX_PAT gestohlen
- Phase 5: Verteilung des bösartigen Pakets
- Die Angreifer veröffentlichten mit dem gestohlenen npm-Token
cline@2.3.0
- Das Monitoring von StepSecurity erkannte nach 14 Minuten Anomalien; nach 8 Stunden wurde das Paket entfernt
Fehlgeschlagene Reaktion und Folgemaßnahmen
- Der Sicherheitsforscher Adnan Khan entdeckte die Schwachstelle im Dezember 2025 und meldete sie am 1. Januar 2026 über ein GitHub Security Advisory, erhielt jedoch fünf Wochen lang keine Antwort
- Nachdem Khan die Schwachstelle am 9. Februar öffentlich offengelegt hatte, entfernte Cline den KI-Triage-Workflow innerhalb von 30 Minuten und patchte das Problem
- Am nächsten Tag begann man mit dem Austausch der Zugangsdaten, löschte jedoch die falschen Tokens, während die exponierten Tokens aktiv blieben
- Der Fehler wurde am 11. Februar entdeckt und die Tokens erneut ausgetauscht, doch die Angreifer hatten die Zugangsdaten bereits gestohlen
- Das npm-Token blieb noch 6 Tage lang gültig genug, um die Verteilung des bösartigen Pakets zu ermöglichen
- Khan war nicht der Angreifer — ein anderer unbekannter Akteur entdeckte den PoC in Khans Test-Repository und setzte ihn direkt gegen Cline ein
Neues Muster: KI installiert KI
- Dieser Vorfall zeigte eine Form, bei der ein KI-Tool einen weiteren KI-Agenten installiert, und erzeugte damit ein rekursives Vertrauensproblem in der Supply Chain
- Der Entwickler vertraut Tool A (Cline) → Tool A wird kompromittiert und installiert Tool B (OpenClaw)
→ Tool B besitzt eigene, von Tool A unabhängige Fähigkeiten (Shell-Ausführung, Zugriff auf Zugangsdaten, Installation eines permanenten Daemons) und ist in der ursprünglichen Vertrauensentscheidung des Entwicklers nicht sichtbar
- OpenClaw kann Zugangsdaten aus
~/.openclaw/ lesen, Shell-Befehle über die Gateway API ausführen und sich als persistenter System-Daemon selbst installieren, der Neustarts überdauert
- Endor Labs bewertete dies als Payload auf Proof-of-Concept-Niveau, entscheidend sei aber der Mechanismus selbst — die nächste Payload werde kein PoC mehr sein
- Es handelt sich um eine Supply-Chain-Variante des Confused-Deputy-Problems, bei der von Entwicklern gewährte Rechte an einen dritten Agenten delegiert wurden
- Der Entwickler delegiert Befugnisse an Cline, und Cline delegiert diese Befugnisse (durch die Kompromittierung) an einen völlig anderen Agenten, den der Entwickler nie bewertet, konfiguriert oder genehmigt hat
Warum bestehende Sicherheitskontrollen versagten
- npm audit: Das durch das
postinstall-Skript installierte Paket (OpenClaw) war legitim und nicht bösartig, also gab es keine Malware zu erkennen
- Code-Review: Die CLI-Binärdatei war mit der vorherigen Version bytegenau identisch; nur eine Zeile in
package.json wurde geändert, sodass automatische Diff-Prüfungen mit Fokus auf Binäränderungen nichts fanden
- Provenance Attestation: Cline nutzte damals noch keine OIDC-basierte npm-Provenance, sodass mit kompromittierten Tokens Pakete ohne Provenance-Metadaten verteilt werden konnten
- StepSecurity markierte dies als anomalen Vorgang
- Berechtigungs-Prompts: Die Installation erfolgte während
npm install im postinstall-Hook; kein KI-Coding-Tool fragte Nutzer vor der Ausführung von Lifecycle-Skripten aus Abhängigkeiten um Bestätigung, sodass die Manipulation unsichtbar blieb
- Ausgenutzt wurde die Lücke zwischen dem, was Entwickler zu installieren glauben (eine bestimmte Cline-Version), und dem, was tatsächlich ausgeführt wird (beliebige Lifecycle-Skripte eines Pakets sowie transitive Installationen)
Clines Reaktion im Nachgang
- Im Post Mortem veröffentlichte Verbesserungsmaßnahmen
- GitHub-Actions-Cache aus Workflows entfernt, die mit Zugangsdaten arbeiten
- OIDC Provenance Attestation für npm-Veröffentlichungen eingeführt und langfristige Tokens abgeschafft
- Validierungsanforderungen für den Austausch von Zugangsdaten ergänzt
- mit dem Aufbau eines formalen Prozesses zur Offenlegung von Schwachstellen inklusive SLA begonnen
- ein Sicherheitsaudit durch Dritte für die CI/CD-Infrastruktur beauftragt
- Allein die OIDC-Migration hätte diesen Angriff verhindern können
- Die gestohlenen Tokens hätten in einem Provenance-System, das einen kryptografischen Nachweis aus einem bestimmten GitHub-Actions-Workflow verlangt, kein Paket veröffentlichen können
Strukturelles Problem und Lehren
- Clinejection ist sowohl ein Supply-Chain-Angriff als auch ein Problem der Agentensicherheit
- Der Einstiegspunkt des Angriffs war natürlichsprachige Eingabe im Titel eines GitHub-Issues, die der KI-Bot als Befehl ausführte
- Das entspricht derselben Struktur wie bei MCP-Tool-Vergiftung oder Angriffen auf Agent-Skill-Register
- Nicht vertrauenswürdige Eingaben erreichen den Agenten → der Agent handelt → niemand bewertet die resultierende Aktion vor der Ausführung
- In diesem Fall war der Agent kein lokaler Coding-Assistent eines einzelnen Entwicklers, sondern ein automatisierter CI-Workflow, der bei jedem neuen Issue ausgeführt wurde und Zugriff auf Shell sowie gecachte Zugangsdaten hatte
- Der Schadenradius betraf nicht den Rechner eines einzelnen Entwicklers, sondern die gesamte Deployment-Pipeline des Projekts
- Alle Teams, die KI-Agenten in CI/CD einsetzen (Issue-Triage, Code-Review, automatisierte Tests usw.), sind derselben Gefährdung ausgesetzt
- Sie müssen das Risiko erkennen, das aus der Kombination nicht vertrauenswürdiger Eingaben mit Zugriff auf Geheimnisse entsteht
- Der Agent verarbeitet nicht vertrauenswürdige Eingaben (Issues, PRs, Kommentare) und kann zugleich auf Secrets (Tokens, Keys, Zugangsdaten) zugreifen
- Interception auf Syscall-Ebene könnte diesen Angriffstyp auf Betriebsebene erfassen:
- Wenn ein KI-Triage-Bot unerwartet
npm install in einem unbekannten Repository ausführen will, kann dies unabhängig vom Inhalt des Issue-Titels anhand von Richtlinien bewertet werden; und wenn Lifecycle-Skripte versuchen, Zugangsdaten an externe Hosts zu exfiltrieren, kann der ausgehende Verkehr blockiert werden
3 Kommentare
Wenn man schon so heftig eins auf die Mütze bekommen hat, müsste sich zumindest die Erkenntnis durchsetzen, dass man bei der Nutzung von LLMs oder Agenten deutlich mehr auf Sicherheit achten muss..
Eine Zeit lang wird es wohl mit Prompt Injection ständig knallen.
In letzter Zeit passieren in npm-Paketen immer wieder ähnliche Dinge.
Hacker-News-Kommentare
Clines Issue-Triage-Workflow lief beim
issues-Event und war mitallowed_non_write_users: "*"konfiguriertDas heißt, jeder konnte allein durch das Öffnen eines Issues GitHub Actions auslösen, und dank der Option
--allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"bekam Claude innerhalb des Workflows auf dem Standard-Branch die Berechtigung zur Ausführung beliebigen CodesEinen AI-Agenten mit so einer Konfiguration laufen zu lassen, wirkt schlicht völlig verrückt
Es gibt sogar Versuche, automatisch Erwähnungen eines Unternehmens in sozialen Medien lesen zu lassen und daraus Bug-Reports zu erzeugen
Ich helfe in meinem Unternehmen bei der Ausarbeitung von AI-Richtlinien; als wir Claude testweise eine bedrohliche E-Mail verarbeiten ließen, wollte es sämtliche Informationen aus Sicherheitstickets einfach nach außen schicken
Zum Glück war die Mail-Funktion deaktiviert, daher wurde nichts tatsächlich versendet
Solche ungeschützten AI-Automatisierungen erinnern mich an das frühere SQL-Injection-Chaos. Wahrscheinlich müssen erst viele Leute Schaden nehmen, bevor vernünftige Schutzmechanismen entstehen
Der Artikel hätte stärker hervorheben sollen, dass GitHubs
issues-Trigger fast so gefährlich ist wie das berüchtigtepull_request_targetAb dem Moment, in dem Nutzereingaben in einen Workflow gelangen, müssen sie als potenzieller Angriffscode behandelt werden
Früher waren CI mit Travis und Automatisierung mit Zapier getrennt; GitHub Actions vereint alles an einem Ort und hat dabei viel zu weitreichende Berechtigungen
Zapier führte keine beliebigen Binärdateien aus und hatte deshalb ein deutlich geringeres Kompromittierungsrisiko
Es gibt bisher keine Methode zur Eingabevalidierung, die vollständig sicher ist
Es gab bereits Fälle, in denen ein LLM base64-kodierte Befehle ausgeführt hat (Beispiellink)
Letztlich muss jede Eingabe als feindselige Daten behandelt werden. Da LLMs sich Handlungen auch selbst „halluzinieren“ können, ist Zugriff auf Produktionssysteme absolut tabu
Standardmäßig sollte kein Workflow irgendwelche Zugangsdaten enthalten und er sollte auf Events von privilegierten Nutzern wie Maintainer:innen beschränkt sein
Allerdings wird Zapier als Blackbox-Service behandelt, bei dem die Sicherheitsverantwortung vollständig dort liegt
Bei GHA ist es dagegen ein Modell mit geteilter Verantwortung zwischen GitHub und den Nutzern, was die Sache komplexer macht
Trotzdem ist GHA viel flexibler als Zapier, und die meisten Nutzer führen am Ende ohnehin beliebigen Code über Lambda oder Webhooks aus
Der problematische Titel lautete wie folgt
Allerdings verwies
github:cline/cline#b181e0in Wirklichkeit auf ein Fork-Repository mit einem bösartigen postinstall-SkriptLink zum problematischen Commit
Bis eben dachte ich auch,
github:cline/clinewürde zwangsläufig auf dasselbe Repository zeigenIch frage mich, ob npm das durch eine engere GitHub-Integration teilweise entschärfen könnte
Der Issue-Titel wurde über
${{ github.event.issue.title }}direkt in den Claude-Prompt eingefügt, und genau das war das Problem: Es gab keine Eingabebereinigung (Sanitization)Allerdings versucht Claude Anfragen im Prompt „hilfsbereit zu verstehen“, daher hätte selbst einfache Bereinigung vermutlich nicht geholfen
Alle npm-Befehle sollten unbedingt in einer Sandbox-Umgebung ausgeführt werden
Weil ich immer mehr solcher Angriffsvektoren sehe, habe ich selbst amazing-sandbox gebaut
Alle Entwickler, die Cline in diesem 8-Stunden-Fenster installiert oder aktualisiert haben, haben dadurch systemweit einen separaten AI-Agenten namens OpenClaw installiert
Ausgenommen waren nur Nutzer, die in ihrer npm-Konfiguration
ignore-scripts=truegesetzt hattenIn Clines Post-Mortem sind die relevanten Fakten gut zusammengefasst
Ob man OpenClaw nun als „harmlosen Payload“ oder als Trojanisches Pferd betrachtet, ist allerdings eine Frage der Perspektive
Niemand wird AI oder AI-Tools vollkommen vertrauen
Solche Vorfälle erinnern sehr nachdrücklich daran
Bei einer Suche fand ich sogar Artikel, die OpenClaw als „viralen AI-Agenten“ bezeichneten
Früher hätte man schon allein durch die Installation solcher Software das System als kompromittiert betrachtet
Schon die Struktur, bei der Code mit beliebigen Rechten nicht vertrauenswürdige Eingaben ausführt, ist das Problem — und in diesem Fall wird genau das sogar noch als zentrales Produktversprechen verkauft
Erstaunlich, dass AI-Firmen die Ähnlichkeit zwischen SQL Injection und Prompt Injection offenbar immer noch nicht verstanden haben
Prompts brauchen denselben Schutz