本稿では、AIコーディングツールClineのCI/CDパイプラインがプロンプトインジェクションを起点に侵害され、不正版パッケージが約4,000回ダウンロードされてOpenClawが無断でインストールされうる状態となった「Clinejection」事案について、攻撃チェーンの技術的メカニズムと、AIエージェントをCI/CDに組み込む際のリスクについて解説します。
事案の概要：GitHubのIssueタイトルから始まったサプライチェーン攻撃
2026年2月17日午前3時26分（PT）、npmレジストリにCline CLIの不正なバージョン（cline@2.3.0）が公開されました。このバージョンにはpackage.jsonに1行のpostinstallスクリプトが追加されており、インストール時にOpenClawというAIエージェントをグローバルにインストールする動作が含まれていました（The Hacker News、2026年2月報道）。
不正パッケージは約8時間にわたり公開され、その間に約4,000回ダウンロードされました。StepSecurityは、不審な手動公開とプロバナンス（出所証明）の欠如を検知しました。Clineメンテナーはその後、バージョン2.4.0を公開し、2.3.0を非推奨化（deprecate）したうえで、侵害されたトークンを失効させています。
影響を受けたのはnpm経由でCline CLIをインストールしたユーザーのみであり、VS Code MarketplaceおよびJetBrainsプラグインからのインストールは影響を受けていません。
攻撃チェーンの技術的詳細
起点：AIトリアージボットへのプロンプトインジェクション
攻撃の起点は、Clineリポジトリに設定されていたAI駆動のIssueトリアージワークフローにあります。このワークフローは2025年12月21日に導入され、新しいIssueが作成されるたびにClaude（Anthropicのモデル）がIssueを分析・応答する仕組みでした。セキュリティ研究者Adnan Khan氏の技術解説（2026年2月9日公開）によれば、このワークフローには2つの致命的な設定がありました。
まず、allowed_non_write_users: "*"の設定により、GitHubアカウントを持つ誰でもIssueを作成するだけでワークフローをトリガーできました。加えて、--allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"の設定によって、Claudeにシェルコマンドの実行を含む広範なツールアクセスが付与されていました。
Issueタイトルはそのままプロンプトに補間されるため、攻撃者はタイトルにClaudeへの指示を含めることができます。Khan氏がテストで使用した例では、「npm install github:cline/cline#aaaaaaaa」を実行するよう指示する文字列をタイトルに埋め込んでいます。リンク先をフォーク上の悪意あるpackage.jsonを含むコミットに向ければ、preinstallスクリプトを通じてCI環境上で任意のコードが実行されます。Khan氏がClineのミラーリポジトリで行ったテストでは、Claudeはすべての試行でペイロードを実行しました。
横展開：GitHub Actionsキャッシュポイズニング
プロンプトインジェクション単体では、トリアージワークフローのランナー上でコードが実行されるだけです。このワークフローのGITHUB_TOKENは権限が制限されており、公開用のシークレットへの直接アクセスはありませんでした。リリースパイプラインに到達するには、別の手法が必要でした。
ここで利用された手法が、GitHub Actionsのキャッシュポイズニングです。GitHub Actionsには、デフォルトブランチで実行されるすべてのワークフローが共有のキャッシュスコープを読み書きできるという仕様が存在します。明示的にキャッシュを使用していないワークフローであっても、キャッシュキーとバージョンを操作できます。
低権限のトリアージワークフローと、公開用シークレット（VSCE_PAT、OVSX_PAT、NPM_RELEASE_TOKEN）を持つ高権限のナイトリーリリースワークフローは、同一のキャッシュスコープを共有していました。
GitHub Actionsでは、リポジトリごとに既定で10GBのキャッシュ上限があり、超過時には古いキャッシュがLRU（Least Recently Used）方式で退避されます。Khan氏は、2025年後半のGitHubによるキャッシュポリシーの運用変更により、この手法が単一のワークフロー実行で成立しやすくなったと分析しています。攻撃者はトリアージワークフローから10GB以上のジャンクデータでキャッシュを埋めて正規のエントリを強制的に退避させ、空いたキーに汚染されたエントリを設置できます。Khan氏が開発したオープンソースツール「Cacheract」は、このプロセスを自動化するものです。
最終段階：npmトークンの窃取と不正パッケージの公開
汚染されたキャッシュエントリはナイトリーリリースワークフローのnode_modulesを乗っ取り、実行時にnpmの公開用トークンを窃取しました。Khan氏によれば、ナイトリー用の資格情報は本番公開にも到達しうる設計であり、理論上はVS Code MarketplaceやOpenVSXにも波及しえました。ただし、実際に不正公開が確認されたのはnpmのみです。
Khan氏は2026年2月9日に脆弱性を公開開示しました。Clineは約30分後にAIトリアージワークフローを削除するPRをマージしています。しかし、その後のトークンローテーションが不完全で、誤ったトークンが削除されました。正しいトークンの失効は2月11日に行われましたが、攻撃者は既にクレデンシャルを窃取しており、2月17日に不正パッケージを公開しました。
Khan氏自身は攻撃者ではありません。Khan氏がClineのミラーリポジトリでPoCを作成・公開した後、別の人物がそのPoCを発見し、Clineに対して直接悪用したとKhan氏は明言しています。
ペイロード：「AIエージェントがAIエージェントをインストールする」
不正パッケージcline@2.3.0がインストールしたのは、OpenClawというオープンソースのAIエージェントでした。OpenClawはコマンド実行、ファイルシステムアクセス、Webブラウジングの機能を持つ汎用ツールであり、それ自体はマルウェアではありません。Endor Labsの分析によれば、OpenClawにはGatewayデーモンのインストールや起動は含まれておらず、直接的な悪意ある動作は確認されていません。
ただし、将来的なリスクとして研究者が懸念しているのは、こうしたAIエージェントがポストエクスプロイト資産として利用される可能性です。セキュリティ研究者Yuval Zacharia氏はSnykの分析記事（Snyk、2026年2月）で引用され、「攻撃者がリモートからプロンプトを送信できるなら、それはマルウェアではなくC2の次の進化形だ」と述べています。自然言語を解釈し、コード実行やファイルアクセスの機能を備えたAIエージェントは、エンドポイント検出ツールからは正規の開発者ソフトウェアとして認識されます。攻撃者が任意のペイロードを選択できる立場にあった以上、「今回がOpenClawだっただけで、次はマルウェアかもしれない」（Socket社の分析）という点が見逃せません。
Microsoftの脅威インテリジェンスチームは、2月17日にOpenClawのインストール数に小幅だが明確な増加を観測したとXで報告しています。
なぜ従来の防御が機能しなかったか
grith.aiの分析（2026年3月5日）は、複数の防御レイヤーがこの攻撃で無効化された理由を整理しています。
コードレビュー：CLIバイナリは前バージョンとバイト単位で同一でした。変更されたのはpackage.jsonの1行のみであり、バイナリ差分に焦点を当てた自動チェックでは検出できません。
プロバナンス証明：通常の正規リリースではOIDCベースのTrusted Publishingが使われていましたが、長寿命のnpm publish tokenも残っていたため、攻撃者はそのトークンを使ってプロバナンスなしの不正公開を行えました。StepSecurityはプロバナンスメタデータの欠如を異常として検出しましたが、公開自体を防止する仕組みではありませんでした。
権限プロンプト：今回のようなnpmのpostinstallは標準的なインストールフローの中で自動実行されうるため、ユーザーが気づかないまま処理が進みます。開発者が意図してインストールしたパッケージのライフサイクルスクリプトが、裏で別のパッケージをグローバルに追加する動作は、通常の操作からは見えません。
実務視点での考察：AIエージェントがCI/CDの新たな攻撃面を生む
構造的な問題：信頼されていない入力がエージェント経由でパイプラインに到達する
Clinejectionを構成する個々の攻撃手法（プロンプトインジェクション、キャッシュポイズニング、クレデンシャル窃取）自体はいずれも既知の技術であり、この点はKhan氏自身も明言しています。真の問題は、これらが連鎖した点にあります。AIエージェントが広範なツールアクセスを持つことで、従来はコード貢献やメンテナーアカウントの侵害を経由しなければ到達できなかったCI/CDパイプラインに、自然言語テキスト1行でアクセスできる低摩擦なエントリポイントが生まれました。
GitHubのIssueタイトル、PRの説明文、コメントは攻撃者が制御可能な入力です。これらを読み取り、シェルアクセスを持つAIエージェントは、eval()にユーザー入力を渡すのと本質的に同じリスクを持ちます。
Cline固有ではなく、同様の構成全般に当てはまる問題
grith.aiが指摘する通り、Issueトリアージ、コードレビュー、自動テスト、その他のワークフローでAIエージェントをCI/CDにデプロイしているすべてのチームが同種のリスクを抱えています。攻撃のエントリポイントはClineに固有のものではなく、「信頼されていない入力を読み取り、ツールアクセスを持つAIエージェントがCI環境で実行される」という構成がリスクの本体です。
本サイトでも以前Clineのサプライチェーン攻撃について解説しましたが、今回の事案はその延長線上にある問題であると同時に、攻撃面が「ユーザーのローカル環境」から「CI/CDパイプライン全体」にスケールしたことを示しています。Vibe Coding記事で取り上げたLovable/Supabaseの事案やGoogle Cloud APIキーの問題も含め、「AIサービスの導入が既存のセキュリティ境界を予期せず拡張する」というパターンが繰り返されています。
具体的な防御策
Clineのポストモーテムおよびセキュリティ研究者が推奨する対策を以下に整理します。
AIエージェントの権限を最小化する：Issueトリアージボットにシェル実行（Bash）、ファイル書き込み（Write）、編集（Edit）の権限は不要です。--allowedToolsを必要最小限のスコープに制限する必要があります。Issueタイトルやコメントといった攻撃者が制御可能な入力は、eval()に渡すユーザー入力と同等に扱うべきです。
CI/CDのキャッシュスコープを分離する：低権限ワークフロー（トリアージ）と高権限ワークフロー（リリース）が同一のキャッシュスコープを共有しないよう、ワークフローごとにキャッシュキーを分離するか、リリースワークフローでキャッシュの使用を避ける構成を検討します。
公開用クレデンシャルを分離する：ナイトリーと本番の公開用トークンを分離し、異なるスコープ・異なるパブリッシャーIDを使用します。Clineはインシデント後にOIDCベースのnpmプロバナンスに一本化しました。短命トークン（分単位で失効）を使用すれば、ランナーが侵害されてもクレデンシャルの有効期間を大幅に制限できます。
npmプロバナンス証明を活用する：OIDC経由のnpmプロバナンスにより、パッケージがソースリポジトリとビルドパイプラインに暗号的に紐づけられます。長寿命トークンによる手動公開経路を廃止することで、プロバナンスメタデータの欠如を異常として検出しやすくなります。
参考情報
- Adnan Khan ― “Clinejection — Compromising Cline’s Production Releases just by Prompting an Issue Triager”（2026年2月9日、発見者による技術解説）
- grith.ai ― “A GitHub Issue Title Compromised 4,000 Developer Machines”（2026年3月5日）
- Snyk ― “How ‘Clinejection’ Turned an AI Bot into a Supply Chain Attack”（2026年2月）
- The Hacker News ― “Cline CLI 2.3.0 Supply Chain Attack Installed OpenClaw on Developer Systems”（2026年2月）
- Socket ― “Cline CLI npm Package Compromised via Suspected Cache Poisoning Attack”（2026年2月）
コメント