Clinejection: Wie ein Issue-Titel an Clines npm-Token gelangte

Am 9. Februar 2026 veröffentlichte der Sicherheitsforscher Adnan Khan einen Bericht über eine Schwachstelle, die er am 1. Januar privat an Cline gemeldet hatte: Der Open-Source-KI-Codierungsassistent hatte einen automatisierten Issue-Triager, der auf Anthropics claude-code-action GitHub Action aufbaute, mit einem Prompt verdrahtet, der jeden eingehenden GitHub-Issue-Titel unverändert in die Anweisungen des Modells einfügte. Jedes GitHub-Konto konnte ihn auslösen, indem es ein Issue eröffnete, und in Khans Reproduktion brachte ein als Anweisung formulierter Titel den Agenten dazu, einen Shell-Befehl innerhalb des Workflows auszuführen. Anschließend verfolgte er den Weg von diesem Einstiegspunkt über Cache-Poisoning bei GitHub Actions bis zu den Release-Anmeldedaten für den VS Code Marketplace, OpenVSX und npm. Acht Tage nachdem Cline den Workflow behoben hatte, wurde ein npm-Publish-Token, von dem Cline annahm, es sei rotiert worden, verwendet, um cline 2.3.0 zu veröffentlichen, das OpenClaw auf jedem Rechner installierte, auf dem das Paket installiert wurde. Der vollständige Eintrag mit seinen Schweregrad- und Konfidenz-Bewertungen findet sich im Orca AI Incident Archive, neben den benachbarten Supply-Chain-Einträgen aus demselben Zeitraum.

Zwei Termine, nicht einer

Das Archiv datiert diesen Datensatz auf den 9. Februar 2026, mit Tagesgenauigkeit, und das ist der Tag, an dem Khan seinen Bericht auf adnanthekhan.com veröffentlichte. Es ist nicht der Tag, an dem das bösartige Paket erschien. Die Schwachstelle selbst wurde am 21. Dezember 2025 in einem Commit eingeführt, der den Triage-Workflow zum Repository cline/cline hinzufügte, und sie blieb aktiv, bis Cline den Workflow am 9. Februar löschte. Die unbefugte npm-Veröffentlichung erfolgte am 17. Februar, acht Tage nach der Behebung und siebenundvierzig Tage nach Khans erstem vertraulichen Bericht.

Es ist wichtig, diese beiden Daten auseinanderzuhalten, denn die folgenreichste Tatsache des Falls liegt in der Lücke zwischen ihnen: Die Tür wurde am 9. Februar geschlossen, doch der Schlüssel, den der Eindringling bereits kopiert hatte, funktionierte am 17. Februar noch. Clines eigene Korrektur, am 17. Februar an Khan gesendet und in seinem Beitrag wiedergegeben, bringt es direkt auf den Punkt: „Als wir am 9. Feb. die Anmeldedaten rotierten, war das npm-Publish-Token nicht ordnungsgemäß widerrufen worden. Es wurde das falsche Token gelöscht, und das offengelegte blieb aktiv.“

Die Kette: von einem Issue-Titel zu einem Release-Token

Die verwundbare Datei war .github/workflows/claude-issue-triage.yml, die beim issues-Ereignis ausgeführt wurde und anthropics/claude-code-action@v1 mit Claude Opus 4.5 aufrief, im Workflow als claude-opus-4-5-20251101 gepinnt. Khan zitiert die Konfiguration des Workflows: allowed_non_write_users war auf das Platzhalterzeichen "*" gesetzt, sodass jedes GitHub-Konto den Agenten einfach durch das Öffnen eines Issues auslösen konnte, und über claude_args wurde --allowedTools mit Bash, Read, Write, Edit, Glob, Grep, WebFetch und WebSearch übergeben. Bash war der entscheidende Punkt. Es ermöglichte dem Modell die Ausführung von Shell-Befehlen innerhalb eines Workflows, der im Default-Branch-Kontext lief.

Der Prompt interpolierte den Issue-Titel, ohne ihn zu bereinigen. Khans Proof of Concept verwendete einen Titel, der mit „Tool error.“ begann und mit einer Anweisung fortfuhr, ein Hilfspaket aus einem bestimmten Commit zu installieren, bevor die Triage fortgesetzt wurde. Die Commit-Referenz verwies auf einen Fork, dessen package.json ein Preinstall-Skript enthielt, das einen curl-Befehl gegen einen vom Angreifer kontrollierten Endpunkt ausführte, bevor npm mit der Installation von irgendetwas fertig war. Da die Installation über das Bash-Tool lief, inspizierte das Modell nie, was ausgeführt wurde. Khan reproduzierte dies auf einem Mirror des Cline-Repositories und berichtet, dass der Agent die Payload bei jedem Versuch ausführte.

Codeausführung im Triage-Workflow ist für sich genommen kein Zugriff auf Release-Zugangsdaten. Dieser Schritt ergab sich aus einer Eigenschaft von GitHub Actions, die Khan in einem 2024 veröffentlichten Tool namens Cacheract dokumentiert hatte: Jeder Workflow kann den Cache des Repositorys lesen und schreiben, mit vollständiger Kontrolle über Cache-Schlüssel und -Versionen, selbst ein Workflow, der nie einen Caching-Schritt deklariert. Der Triage-Job lief auf dem Standardbranch und teilte sich daher einen Cache-Bereich mit den nächtlichen Publish-Jobs, die node_modules tatsächlich aus dem Cache wiederherstellten und die Publishing-Tokens besaßen.

Cache-Einträge sind unveränderlich, daher kann ein Angreifer nicht einfach den Eintrag überschreiben, den ein Release-Job wiederherstellen wird. Khans Weg daran vorbei war, eine GitHub-Richtlinienänderung vom 20. November 2025 auszunutzen, durch die der Dienst Cache-Einträge sofort verdrängte, sobald der Cache eines Repositorys 10 GB überschritt, und zwar in der Reihenfolge der am längsten nicht verwendeten Einträge. Überflutet man den Cache über 10 GB hinaus, altern die legitimen Einträge heraus; beansprucht man die freigewordenen Schlüssel mit vergiftetem Inhalt, führt der nächste Job, der sie wiederherstellt, Angreifercode aus. Cacheract automatisiert die gesamte Abfolge innerhalb eines einzigen Workflow-Laufs und sorgt für Persistenz, indem es die action.yml von actions/checkout überschreibt, sodass der Post-Schritt der Action am Ende jedes Jobs eine Payload ausführt.

Das letzte Glied in der Kette ist der nächtliche Job, der etwa um 2 Uhr UTC läuft, die vergifteten node_modules wiederherstellt und detoniert. Was dabei herauskommt, sind VSCE_PAT, OVSX_PAT und NPM_RELEASE_TOKEN, die Zugangsdaten für den VS Code Marketplace, OpenVSX bzw. npm. Ob jedes Glied in dieser Reihenfolge gegen Clines eigenes Repository lief, ist eine separate Frage, die weiter unten behandelt wird.

Warum die nächtlichen Zugangsdaten Produktionszugangsdaten waren

Der naheliegende Einwand ist, dass Nightly- und Produktions-Releases unterschiedliche Secrets verwenden sollten. Khans Antwort ist, dass die Trennung nur nominell war. OpenVSX und der VS Code Marketplace binden ein Veröffentlichungstoken an eine Publisher-Identität, nicht an eine einzelne Extension, und sowohl die Stable- als auch die Nightly-Cline-Extension wurden unter derselben Identität veröffentlicht, die Khan auf OpenVSX als saoudrizwan angibt. Bei npm ist das Modell feingranularer Tokens an ein Paket gebunden, und Cline veröffentlichte seine Stable- und Nightly-CLI-Builds im selben Paket cline. Ein Token, das für den Nightly-Job ausgestellt wurde, konnte daher das Produktionsartefakt veröffentlichen – und genau das geschah acht Tage später.

Khans eigene Darstellung der Tragweite stützt sich auf die Größenordnung: Er verweist auf Clines Ankündigung, dass die Marke von 5 Millionen Installationen überschritten worden sei, und merkt an, dass ein über gestohlene Zugangsdaten eingeschleustes Erweiterungs-Update im Kontext jedes Entwicklers ausgeführt wird, dessen Editor sich automatisch aktualisiert – mit den Berechtigungen dieses Entwicklers und mit allem an Schlüsseln, Tokens und Quellcode, das sich auf dem Rechner befindet.

Was tatsächlich veröffentlicht wurde und was es bewirkt hat

Das veröffentlichte Artefakt war Cline 2.3.0, und es war klein. Die eigenen Zeitstempel der npm-Registry setzen 2.3.0 auf 11:26:51 UTC am 17. Februar 2026 und das saubere 2.4.0 auf 19:23:08 UTC am selben Tag – einen Expositionszeitraum, den der Cline-Hinweis auf rund acht Stunden schätzt, bis 2.3.0 um 11:30 Uhr PT als veraltet markiert wurde. Die package.json des Pakets enthielt eine hinzugefügte Zeile, ein postinstall-Skript mit dem Inhalt npm install -g openclaw@latest. Der Cline-Hinweis GHSA-9ppg-jx86-fqw7 stellt fest, dass keine anderen Paketdateien verändert wurden und dass dist/cli.mjs byteidentisch mit dem legitimen 2.2.3-Build ist.

OpenClaw ist ein echtes Open-Source-KI-Agenten-Framework und keine Malware, und Clines Sicherheitshinweis sagt das ausdrücklich: Es ist ein legitimes Projekt, aber seine Installation war weder autorisiert noch beabsichtigt. Endor Labs, das den Tarball analysiert hat, bewertete die Gesamtauswirkung als gering, mit der Begründung, dass die Installation den Gateway-Daemon von OpenClaw nicht gestartet hat. StepSecuritys Bericht beleuchtet die andere Seite: Eine globale Installation hinterlässt das Framework auf dem Datenträger, mit welchen Anmeldedaten und welchem Dateizugriff der installierende Benutzer auch immer hat, und OpenClaws Design – ein persistenter lokaler Gateway mit einer Operator-API – macht es zu einem äußerst wertvollen Fund an dieser Stelle. Die beiden Bewertungen widersprechen sich nicht. Die eine beschreibt, was während des Zeitfensters lief; die andere beschreibt, was danach zurückblieb.

Die Downloadzahl ist die eine Zahl, die mit Vorsicht zu behandeln ist. StepSecurity berichtete, dass die kompromittierte Version etwa 4.000 Mal heruntergeladen wurde, bevor sie als veraltet markiert wurde, und The Register wiederholte diese Zahl. Endor Labs bezifferte die monatliche Downloadzahl von cline für den Zeitraum 19. Januar bis 17. Februar auf 418.545, wobei sich diese Zahl auf den normalen Traffic des Pakets und nicht auf den bösartigen Build bezieht. Keine der beiden Zahlen zählt Maschinen: Eine Downloadzahl ist keine Zahl der betroffenen Entwickler, und keine Partei hat eine Zahl zur installierten Basis für 2.3.0 veröffentlicht. Das Threat-Intelligence-Team von Microsoft erklärte auf X, es habe am 17. Februar einen „kleinen, aber bemerkbaren Anstieg“ bei OpenClaw-Installationen beobachtet, der auf das Cline-Installationsskript zurückgehe, wie The Hacker News berichtete.

GitHubs Advisory-Eintrag für GHSA-9ppg-jx86-fqw7 enthält weder eine CVE noch eine CWE, und sein Schweregrad ist Niedrig. Diese Einstufung betrifft die harmlose Nutzlast, nicht den Diebstahl von Anmeldedaten, und sie wirkt seltsam neben der kritischen Einstufung des Archivs für den Vorfall selbst. Der Advisory-Eintrag verzeichnet 2.3.0 als betroffene Version und 2.4.0 als Behebung.

Die Offenlegung, auf die Cline nicht geantwortet hat

Khans Zeitplan vor der Veröffentlichung ist der Teil der Aufzeichnung, der am wenigsten mit dem Modell und am meisten mit dem Prozess zu tun hat. Er reichte am 1. Januar 2026 über GitHubs private Schwachstellenmeldung ein GHSA ein und schrieb noch am selben Tag eine E-Mail an den auf Clines Vertrauensseite aufgeführten Sicherheitskontakt. Am 8. Januar schickte er einem Cline-Entwickler eine Nachfrage. Am 18. Januar versuchte er, dem CEO von Cline auf X eine Direktnachricht zu senden. Am 7. Februar schrieb er erneut und erhielt nichts als eine automatische Ticketnummer. Am 9. Februar veröffentlichte er.

Cline hat den Fix, Pull Request 9211, etwa dreißig Minuten bis eine Stunde später zusammengeführt. Der PR löscht drei Workflow-Dateien, claude-issue-triage.yml, claude-pr-review.yml und cline-pr-review.yml, und entfernt das Caching aus publish.yml, publish-nightly.yml, npm-nightly.yaml und npm-main.yaml, insgesamt sieben Dateien, wobei die Installationsschritte nun bedingungslos ausgeführt werden, da es keinen Cache-Treffer mehr gibt, auf den man sich verlassen könnte.

Clines öffentliche Antwort vom 10. Februar, zitiert in Khans Beitrag, akzeptierte den Befund und listete unmittelbare Maßnahmen auf: die Entfernung der Bot-Review-Workflows für Issues und PRs, die Entfernung von actions/cache aus Publish-Workflows, die Release-Anmeldedaten verarbeiten, sowie die Rotation der relevanten Anmeldedaten einschließlich Bot-, Provider- und Publishing-Tokens. Außerdem räumte sie den Umgang damit ein: „Wir erkennen an, dass unsere Reaktionszeit auf Ihren ursprünglichen Bericht inakzeptabel war. Ein am 1. Januar eingereichter Bericht hätte nicht am 9. Februar öffentlich offengelegt werden müssen, um bearbeitet zu werden.“

Am 11. Februar erklärte Cline, es habe eine vollständige Rotation von VSCE_PAT, OVSX_PAT und NPM_RELEASE_TOKEN abgeschlossen, und eine Prüfung jeder Veröffentlichung auf allen drei Vertriebskanälen zwischen dem 21. Dezember 2025 und dem 9. Februar 2026 habe ergeben, dass jede Marketplace- und OpenVSX-Version einem mit einem Tag versehenen GitHub-Release zugeordnet werden konnte und dass alle 41 npm-Versionen mit dem Quellcode übereinstimmten. Es kam zu dem Schluss, dass „während des behaupteten Expositionszeitraums“ keine unbefugte Veröffentlichung erfolgt sei. Sechs Tage später korrigierte es die Darstellung in der oben zitierten Nachricht: Das npm-Token sei nicht widerrufen worden, und 2.3.0 sei damit veröffentlicht worden.

Etabliert, zugeordnet, ungeklärt

• Bestätigt. Die Workflow-Konfiguration ist öffentlich und wurde vor der Behebung veröffentlicht. Khan reproduzierte die Prompt-Injection auf einem Mirror des Repositorys. Cline hat die Behebung zusammengeführt und eine Advisory veröffentlicht, die die Veröffentlichung von 2.3.0, die hinzugefügte postinstall-Zeile, das unveränderte CLI-Binary, das Acht-Stunden-Fenster und den Token-Fehler bestätigt. Die Zeitstempel der npm-Registry für 2.3.0 und 2.4.0 stimmen mit den Zeiten der Advisory überein. Das Archiv bewertet den Eintrag als kritisch, mit Konfidenz A, wobei realer Schaden verzeichnet ist und kein Dispute-Flag gesetzt ist.

• Zugeschrieben, nicht erwiesen. Wer 2.3.0 veröffentlicht hat, bleibt eine offene Zuschreibung. Die forensische Analyse, die Michael Bargury und ein automatisiertes Untersuchungstool namens Raptor am 19. Februar veröffentlichten, nennt ein GitHub-Konto, glthub-actions, und berichtet mit hoher Zuversicht, dass dieses Konto cline/cline geforkt, am 28. Januar 2026 um 03:51 UTC den Issue 8904 mit dem eingeschleusten Titel eröffnet und einen Fork-Commit genutzt habe, um eine Payload aus einem Gist auszuführen. Khan bestätigte, dass die Konten gcbrun und Dev11940518 seine eigenen sind und glthub-actions nicht. Das Konto war bereits gelöscht oder gesperrt, als die Analyse veröffentlicht wurde, und Cline hat niemanden namentlich genannt. Die Identität ist als Feststellung eines Dritten zu behandeln.

• In der Einordnung umstritten, nicht im Sachverhalt. Bargury bewertet den Vorfall als vereinbar mit einer Demonstration aus der Sicherheitsforschung und nicht als bösartige Kampagne, unter Verweis auf die harmlose Nutzlast und die Vorgeschichte des Akteurs gegenüber einem New Relic-Automatisierungsrepository. Cline nennt es eine unbefugte Veröffentlichung, und Khan schreibt, der Akteur, der 2.3.0 veröffentlicht habe, sei „vermutlich“ derselbe, der die Caches vergiftet habe. Niemand hat eine Absicht nachgewiesen, Schaden zu verursachen, und niemand hat nachgewiesen, dass keine bestand.

• Ungeklärt. Khans eigene Anmerkung aus der Zeit vor der Veröffentlichung ist bei einem Punkt sorgfältig, den die spätere Berichterstattung mitunter vereinfacht: Zwischen dem 31. Januar und dem 3. Februar 2026 scheiterten mehrere nächtliche Läufe an einem Post-Checkout-Schritt, der keine Ausgabe erzeugte, was Cacheracts Kompromittierungsindikator ist, und der Triage-Workflow ist der naheliegendste Weg, aber es ist nicht bewiesen, dass er der Einstiegspunkt für diese Aktivität war. Auch hat keine Partei Belege dafür veröffentlicht, dass die Marketplace- oder OpenVSX-Token verwendet wurden; das einzige Artefakt, das jemand hervorgebracht hat, ist der npm-Build.

Was hat sich danach geändert?

Die Behebung erfolgte auf mehreren Ebenen gleichzeitig, und es lohnt sich, jede einzelne zu benennen, weil sie unterschiedliche Teile des Fehlers adressieren. Der Workflow, der von einem Außenstehenden erreichbar war, wurde gelöscht statt eingeschränkt. Das Caching wurde aus den vier Release-Workflows entfernt, die Veröffentlichungsgeheimnisse enthalten, statt aus dem gesamten Repository – und genau diese Änderung durchbricht den Pivot. Credentials wurden rotiert, und nach der Korrektur vom 17. Februar wurde das korrekte npm-Token widerrufen. Cline's Advisory besagt, dass npm-Veröffentlichungen jetzt OIDC-Provenienz über GitHub Actions verwenden, und die Metadatenanalyse von StepSecurity zeigt, warum das wichtig war: Die legitimen Releases trugen bereits Provenienz-Attestierungen, und 2.3.0 war der Ausreißer, der von einem menschlichen Konto veröffentlicht wurde. Die Lücke bestand darin, dass der Pfad für langlebige Tokens neben dem Trusted Publishing offen blieb – genau das, wovon Endor Labs argumentiert, dass Maintainer es schließen sollten. Cline veröffentlichte GHSA-9ppg-jx86-fqw7, machte 2.3.0 mit der Meldung als veraltet kenntlich, dass es nicht installiert werden sollte, und verwies Nutzer auf 2.4.0 oder neuer.

Khans strukturelle Empfehlungen gehen weiter als das, was umgesetzt wurde, und es lohnt sich, sie als seine festzuhalten und nicht als die von Cline: Bash, Write und Edit aus jedem Triage-Workflow entfernen und ihm nur Dateilesevorgänge und die konkreten GitHub-CLI-Aufrufe belassen, die es benötigt; niemals einen Cache in einem Job wiederherstellen, der Secrets für die Produktionsveröffentlichung enthält; und Nightly-Releases einen eigenen Registry-Namespace sowie eine dedizierte Nicht-Produktions-Publishing-Identität geben, sodass ein gestohlenes Nightly-Token gar kein Stable-Release veröffentlichen kann.

Die acht Tage zwischen der Behebung und der bösartigen Veröffentlichung sind das Detail, das diesen Eintrag aufbewahrenswert macht. Jeder Schritt in der Kette war eine bekannte Technik; Khan hatte das Cache-Poisoning-Tool veröffentlicht, und die PromptPwnd-Untersuchung von Aikido Security vom Dezember 2025 dokumentierte dasselbe Muster einer Triage-Fehlkonfiguration. Aus ihnen einen Supply-Chain-Vorfall machten ein Workflow, der den Text eines Fremden bis in eine Shell gelangen ließ, ein Cache, der mit Jobs geteilt wurde, die Release-Schlüssel besaßen, und eine Token-Rotation, bei der ein Credential übersehen wurde. Jede der drei Fehlerbehebungen hätte die Kette für sich allein durchbrochen; die dritte kam acht Tage zu spät.