Clinejection：あるIssueタイトルがClineのnpmトークンに到達するまで

2026年2月9日、セキュリティ研究者のAdnan Khanは、1月1日にClineへ非公開で報告した脆弱性についての説明を公開した。そのオープンソースAIコーディングアシスタントは、Anthropicのclaude-code-action GitHub Actionを基に構築した自動Issueトリアージツールを、受信したGitHub Issueのタイトルをそのままモデルの指示に貼り付けるプロンプトに接続していた。GitHubアカウントを持つ誰でも、Issueを開くだけでこれを起動でき、Khanの再現では、指示として書かれたタイトルによってエージェントがワークフロー内でシェルコマンドを実行した。彼はその後、その足掛かりからGitHub Actionsのキャッシュポイズニングを経て、VS Code Marketplace、OpenVSX、npmのリリース用認証情報に至る経路を追跡した。Clineがワークフローを修正してから8日後、Clineがローテーション済みと考えていたnpm公開トークンが使われてcline 2.3.0が公開され、このパッケージをインストールしたすべてのマシンにOpenClawがインストールされた。詳細な記録は、重大度と信頼度の格付けとともに、Orca AI Incident Archiveに、同時期の隣接するサプライチェーン記録と並んで収められている。

1つではなく2つの日付

アーカイブでは、この記録の日付は2026年2月9日（日単位の精度）とされており、それはKhanがadnanthekhan.comで記事を公開した日である。悪意のあるパッケージが出現した日ではない。脆弱性自体は2025年12月21日に、cline/clineリポジトリにトリアージワークフローを追加したコミットで導入され、Clineが2月9日にそのワークフローを削除するまで有効なままだった。無許諾のnpm公開は2月17日に行われ、それは修正から8日後、Khanの最初の非公開報告から47日後だった。

この二つの日付を区別しておくことは重要だ。なぜなら、この事件で最も重大な事実は、その間の隔たりの中にあるからだ。扉が閉ざされたのは2月9日だったが、侵入者がすでに複製していた鍵は、2月17日になってもまだ使えた。Cline自身による訂正は、2月17日にKhanへ送られ、自身の投稿に再掲されているが、それを端的に示している。「2月9日に認証情報をローテーションしたとき、npmのパブリッシュトークンは適切に失効されていませんでした。誤ったトークンが削除され、露出していたトークンは有効なままでした。」

連鎖：イシュータイトルからリリーストークンまで

脆弱なファイルは .github/workflows/claude-issue-triage.yml で、これは issues イベントで実行され、Claude Opus 4.5 を指定して anthropics/claude-code-action@v1 を呼び出していました。ワークフロー内では claude-opus-4-5-20251101 として固定されていました。Khan はそのワークフローの設定を引用しています。allowed_non_write_users がワイルドカード "*" に設定されていたため、どの GitHub アカウントでも issue を開くだけでエージェントを起動でき、また claude_args は --allowedTools に Bash、Read、Write、Edit、Glob、Grep、WebFetch、WebSearch を渡していました。問題だったのは Bash です。これにより、デフォルトブランチのコンテキストで実行されるワークフロー内で、モデルにシェル実行が与えられていました。

プロンプトはイシューのタイトルをサニタイズせずに補間していた。Khanの実証では、タイトルが「Tool error.」で始まり、その後に特定のコミットからヘルパーパッケージをインストールしてからトリアージを続行するよう指示する内容が続いていた。そのコミット参照はフォークを指しており、そのpackage.jsonにはpreinstallスクリプトが含まれていて、npmのインストールが完了する前に攻撃者が制御するエンドポイントに対してcurlコマンドを実行した。インストールはBashツール経由で実行されたため、モデルは何が実行されたかを一切確認しなかった。KhanはこれをClineリポジトリのミラー上で再現し、エージェントは毎回の試行でペイロードを実行したと報告している。

トリアージワークフローでのコード実行は、それ自体がリリース資格情報へのアクセスというわけではない。その段階は、Khanが2024年に公開したCacheractというツールで文書化していたGitHub Actionsの性質に由来していた。つまり、キャッシュステップを宣言していないワークフローであっても、あらゆるワークフローがキャッシュキーとバージョンを完全に制御してリポジトリのキャッシュを読み書きできる。トリアージジョブはデフォルトブランチで実行されたため、夜間の公開ジョブとキャッシュスコープを共有しており、それらの公開ジョブは実際にnode_modulesをキャッシュから復元し、公開トークンを保持していた。

キャッシュエントリは不変であるため、攻撃者はリリースジョブが復元するエントリを単純に上書きすることはできません。Khanがその回避に用いたのは、2025年11月20日のGitHubポリシー変更を悪用する手法でした。これは、リポジトリのキャッシュが10 GBを超えると、サービスが最も長く使われていない順（LRU順）でキャッシュエントリを直ちに追い出すようにしたものです。キャッシュを10 GB超まで溢れさせれば正規のエントリは古くなって追い出され、空いたキーを汚染された内容で奪えば、次にそれらを復元するジョブが攻撃者のコードを実行することになります。Cacheractはこの一連の流れを単一のワークフロー実行内で自動化し、さらにactions/checkoutのaction.ymlを上書きすることで永続化します。これにより、そのアクションのpostステップが各ジョブの終了時にペイロードを実行します。

連鎖の最後の環は夜間ジョブで、UTC 午前2時頃に実行され、汚染された node_modules を復元し、爆発する。そこから出てくるのは VSCE_PAT、OVSX_PAT、NPM_RELEASE_TOKEN で、それぞれ VS Code Marketplace、OpenVSX、npm の認証情報だ。すべての環がその順序で Cline 自身のリポジトリに対して実行されたかどうかは別問題であり、以下で取り上げる。

なぜナイトリーの認証情報が本番の認証情報だったのか

明白な反論は、ナイトリー版と本番版のリリースでは異なるシークレットを保持すべきだというものだ。カーン氏の答えは、その分離は名目上のものだったというものだ。OpenVSX と VS Code Marketplace は、公開トークンを個々の拡張機能ではなくパブリッシャー ID に紐づけており、Cline の安定版とナイトリー版の拡張機能はいずれも同じ ID で公開されていた。カーン氏はその ID を OpenVSX 上で saoudrizwan と特定している。npm では、きめ細かいトークンモデルはパッケージに紐づいており、Cline は安定版とナイトリー版の CLI ビルドを同じ cline パッケージに公開していた。したがって、ナイトリーのジョブ用に発行されたトークンで本番の成果物を公開できてしまい、実際にその8日後にまさにそれが起きた。

Khan自身による影響の捉え方は規模に基づいている。彼はClineがインストール数500万件を超えたと発表したことに言及し、盗まれた認証情報を用いて配信された拡張機能の更新は、エディターが自動更新されるすべての開発者の環境で、その開発者の権限、およびそのマシン上にある鍵、トークン、ソースコードを用いて実行されると指摘している。

実際に何が公開され、それが何をしたのか

公開された成果物は cline 2.3.0 で、小さいものだった。npm レジストリ自身のタイムスタンプでは、2.3.0 は 2026年2月17日 11:26:51 UTC、クリーンな 2.4.0 は同日 19:23:08 UTC と記録されており、Cline のアドバイザリでは、2.3.0 が太平洋時間午前11:30に非推奨化されるまでの約8時間が露出期間とされている。このパッケージの package.json には、npm install -g openclaw@latest を実行する postinstall スクリプトという1行が追加されていた。Cline のアドバイザリ GHSA-9ppg-jx86-fqw7 は、他のパッケージファイルは変更されておらず、dist/cli.mjs は正規の 2.2.3 ビルドとバイト単位で同一であると述べている。

OpenClawは実際のオープンソースAIエージェントフレームワークであり、マルウェアではない。Clineの勧告もそれを明言している。正規のプロジェクトだが、そのインストールは許可されておらず、意図されたものでもなかった。tarballを分析したEndor Labsは、インストールがOpenClawのGatewayデーモンを起動しなかったことを理由に、全体的な影響を低と評価した。StepSecurityの記事はその反対側の側面を測っている。グローバルインストールでは、インストールしたユーザーが持つ資格情報とファイルアクセスの権限のまま、フレームワークがディスク上に残る。そしてOpenClawの設計は、オペレーターAPIを備えた永続的なローカルゲートウェイであり、そこに存在することが高価値な発見対象となる。二つの評価は矛盾していない。一方はその時間枠に何が実行されたかを述べ、他方はその後に何が残されたかを述べている。

件数だけは慎重に扱わなければならない数字だ。StepSecurityは、侵害されたバージョンが非推奨になる前に約4,000回ダウンロードされたと報告し、The Registerもその数字を繰り返した。Endor Labsは、1月19日から2月17日までのclineの月間ダウンロード数を418,545とし、これは悪意あるビルドではなくパッケージの通常のトラフィックを表している。どちらの数字もマシンの台数を数えたものではない。ダウンロード数は影響を受けた開発者の数ではなく、2.3.0のインストールベースを示す数字を公表した関係者もいない。MicrosoftのThreat IntelligenceチームはX上で、The Hacker Newsが報じたように、2月17日にClineのインストールスクリプトに起因するOpenClawインストールの「小さいが目立つ増加」を観測したと述べた。

GHSA-9ppg-jx86-fqw7 に関する GitHub のアドバイザリ記録には CVE も CWE もなく、深刻度は Low です。その評価は無害なペイロードに関するもので、認証情報の窃取に関するものではなく、インシデント自体に対するアーカイブの Critical 評価の隣に置かれると奇妙に映ります。アドバイザリは影響を受けるバージョンとして 2.3.0、修正版として 2.4.0 を記録しています。

Cline が回答しなかった開示

カーン氏の公開前のタイムラインは、この記録の中でモデルについての要素が最も少なく、プロセスについての要素が最も多い部分だ。同氏は2026年1月1日にGitHubの非公開脆弱性報告を通じてGHSAを提出し、同日にClineのトラストページに記載されたセキュリティ連絡先へメールを送った。1月8日にはClineの開発者にフォローアップを送った。1月18日にはXでClineのCEOにダイレクトメッセージを送ろうとした。2月7日にも再度連絡したが、返ってきたのは自動発行のチケット番号だけだった。2月9日に公開した。

Clineは約30分から1時間後、修正（プルリクエスト9211）をマージした。そのPRは3つのワークフローファイル、claude-issue-triage.yml、claude-pr-review.yml、cline-pr-review.ymlを削除し、publish.yml、publish-nightly.yml、npm-nightly.yaml、npm-main.yamlからキャッシュを削除する。合計7ファイルで、依存できるキャッシュヒットがなくなったため、インストール手順は無条件化された。

Khanの投稿で引用された2月10日のClineの公開回答は、この指摘を受け入れ、直ちに講じる緩和策として、問題およびPRのボットレビューワークフローの削除、リリース認証情報を扱うpublishワークフローからのactions/cacheの削除、ボット・プロバイダー・公開トークンを含む関連認証情報のローテーションを列挙した。また、その対応についても「当初の報告への対応時間が許容できないものであったことを認めます。1月1日に提出された報告が、対応されるために2月9日の公開開示を必要とすべきではありませんでした」と認めた。

2月11日、ClineはVSCE_PAT、OVSX_PAT、NPM_RELEASE_TOKENの完全なローテーションを完了したと発表し、2025年12月21日から2026年2月9日までの間に3つの配信チャネルすべてで全リリースを監査した結果、MarketplaceとOpenVSXのすべてのバージョンがタグ付けされたGitHubリリースに紐づいており、npmの41バージョンすべてがソースと整合していたことが判明したと述べた。そして「主張されていた露出期間中」に不正なリリースは公開されなかったと結論づけた。6日後、同社は上記で引用したメッセージの中で記録を訂正し、npmトークンは失効されておらず、2.3.0がそのトークンを使って公開されていたと述べた。

確立済み、帰属済み、未解決

• 確定。ワークフロー設定は公開されており、修正前に公開されていた。Khan はリポジトリのミラー上でプロンプトインジェクションを再現した。Cline は修復をマージし、2.3.0 の公開、追加された postinstall 行、変更されていない CLI バイナリ、8 時間のウィンドウ、トークン障害を確認するアドバイザリを発行した。npm レジストリの 2.3.0 と 2.4.0 のタイムスタンプはアドバイザリの時刻と一致している。アーカイブはこの記録を重大と評価し、信頼度 A、実際の被害が記録され、異議フラグはない。

• 帰属は示されているが、確定していない。2.3.0を誰が公開したのかは、依然として帰属が未確定である。マイケル・バーグリーと、Raptorという自動調査ツールが2月19日に公開したフォレンジック分析記事は、GitHubアカウントglthub-actionsを名指しし、このアカウントがcline/clineをフォークし、2026年1月28日03:51 UTCに注入されたタイトルを付けてIssue 8904を開設し、gistからペイロードを実行するためにフォークのコミットを使用したと、高い信頼度で報告している。Khan氏は、アカウントgcbrunとDev11940518は自分自身のものであり、glthub-actionsはそうではないと確認した。このアカウントは記事の公開時点ですでに削除または停止されており、Clineは誰も名指ししていない。この身元は第三者による調査結果として扱うこと。

• 争点は事実ではなく性質にある。Barguryは、悪意あるキャンペーンではなくセキュリティ研究のデモンストレーションと整合するとこの一件を評価し、無害なペイロードと、New Relicの自動化リポジトリに対する行為者の経歴を根拠に挙げている。Clineはこれを無断公開と呼び、Khanは2.3.0を公開した行為者は「おそらく」キャッシュを汚染したのと同じ人物だと書いている。害を及ぼす意図があったことを示した者はおらず、それがなかったことを示した者もいない。

• 未解決。Khan 自身の公開前の注記は、後の報道がときに単純化してしまうある点について慎重だ。2026年1月31日から2月3日の間、複数の夜間実行が、何も出力しなかった Post Checkout ステップで失敗した。これは Cacheract の侵害指標であり、トリアージワークフローが最も明白な経路ではあるが、それがその活動の侵入点だったとは証明されていない。また、Marketplace または OpenVSX のトークンが使用された証拠を公開した当事者もいない。誰かが提示した唯一のアーティファクトは npm ビルドである。

その後、何が変わりましたか？

修正対応は複数の層に同時に及んでおり、それぞれが障害の異なる部分に応えるものなので、一つずつ明示する価値がある。外部者から到達可能だったワークフローは、範囲を狭めるのではなく削除された。公開用シークレットを保持する4つのリリースワークフローからキャッシュが削除され、リポジトリ全体から削除されたわけではない。これが攻撃のピボットを断ち切る変更である。認証情報はローテーションされ、2月17日の訂正後、正しい npm トークンが失効された。Cline のアドバイザリは、npm 公開が現在 GitHub Actions 経由の OIDC プロベナンスを使用していると述べており、StepSecurity のメタデータ分析はそれがなぜ重要だったかを示している。正規のリリースはすでにプロベナンス証明を伴っており、2.3.0 は人間のアカウントによって公開された外れ値だった。ギャップは、トラステッドパブリッシングと並行して長期有効トークンの経路が開いたままだったことであり、これは Endor Labs がメンテナーは閉じるべきだと主張している具体的な点である。Cline は GHSA-9ppg-jx86-fqw7 を公開し、2.3.0 を「インストールすべきではない」というメッセージ付きで非推奨にし、ユーザーに 2.4.0 以降を案内した。

カーンの構造上の推奨は、実装された内容よりも踏み込んでおり、クラインのものではなく彼自身のものとして記録する価値がある。トリアージのワークフローからBash、Write、Editを外し、ファイル読み取りと必要な特定のGitHub CLI呼び出しだけを残すこと。本番公開シークレットを保持するジョブではキャッシュを復元しないこと。ナイトリリリースには専用のレジストリ名前空間と本番以外専用の公開IDを与え、盗まれたナイトリトークンでは安定版リリースを一切公開できないようにすること。

修正と悪意ある公開の間にある8日間の隔たりこそ、この記録を残す価値があるものにする詳細だ。連鎖の各段階はすべて既知の手法だった。Khanはキャッシュポイズニングツールを公開しており、Aikido Securityの2025年12月のPromptPwnd調査も同じトリアージ設定ミスのパターンを文書化していた。それらをサプライチェーンインシデントに仕立てたのは、見知らぬ他人のテキストがシェルに到達できるワークフロー、リリースキーを持つジョブと共有されたキャッシュ、そして1つの資格情報を逃したトークンローテーションだった。3つの修正はそれぞれ単独で連鎖を断ち切れたはずだが、3つ目は8日遅れて到来した。