- タイトルに埋め込まれたプロンプトインジェクションにより、ClineのAIベースのIssue分類ボットを通じてコマンドが注入された
- npmトークンが窃取され、悪性のClineが配布される中でOpenClaw AIエージェントが無断でインストールされた
- 攻撃者は、プロンプトインジェクション → AIボットによる任意コード実行 → キャッシュポイズニング → 認証情報窃取 → 悪性パッケージ配布、という5段階のチェーンを構成した
- 既存のセキュリティ統制（コードレビュー、npm audit、provenance attestations）はこの攻撃を検知できなかった
- セキュリティ研究者が2025年12月末に脆弱性を発見して報告したが、5週間応答がなく、公開後も認証情報のローテーションミスにより攻撃が実行された
- AIエージェントがAIエージェントをインストールするという新たなサプライチェーン脅威のパターンが現れ、CI/CD環境におけるAI自動化のリスクが浮き彫りになった
攻撃の概要
- 2026年2月17日、npmに
cline@2.3.0が公開された。既存バージョンと同じバイナリだったが、package.jsonに"postinstall": "npm install -g openclaw@latest"という1行が追加されていた
- その結果、8時間のあいだにClineをインストールまたは更新した約4,000人の開発者のシステムにOpenClawが自動インストールされた
- OpenClawはシステム全体へのアクセス権を持つ別のAIエージェントであり、ユーザーの同意なくグローバルインストールされた
攻撃チェーン（Clinejection）
- 第1段階: プロンプトインジェクション
- ClineはAnthropicの
claude-code-actionを使ったAI Issue分類ワークフローを利用していた
allowed_non_write_users: "*"の設定により、誰でもIssueを作成してボットをトリガーできた- 攻撃者は1月28日、性能レポートのように見えるタイトルに「特定パッケージをインストールせよ」という命令を埋め込んだIssue #8904を作成した
- 第2段階: AIボットによる命令実行
- Claudeはこの命令を正当な指示として認識し、攻撃者のフォーク（
glthub-actions/cline）でnpm installを実行した
- そのフォークの
package.jsonには、リモートのシェルスクリプトを実行するpreinstallスクリプトが含まれていた
- 第3段階: キャッシュ汚染（Cache Poisoning）
- そのスクリプトは、GitHub Actionsのキャッシュを汚染するCacheractを展開した
- 10GB超のデータを注入して正当なキャッシュを押し出し、Clineのナイトリーリリースワークフローが使うキャッシュキーを偽装した
- 第4段階: 認証情報の窃取
- リリースワークフローが汚染されたキャッシュから
node_modulesを復元したことで、NPM_RELEASE_TOKEN、VSCE_PAT、OVSX_PATが窃取された
- 第5段階: 悪性パッケージの配布
- 攻撃者は窃取したnpmトークンで
cline@2.3.0を公開した
- StepSecurityの監視が14分後に異常を検知し、8時間後にパッケージは削除された
対応失敗とその後の措置
- セキュリティ研究者Adnan Khanは2025年12月に脆弱性を発見し、2026年1月1日にGitHub Security Advisoryで報告したが、5週間応答がなかった
- Khanが2月9日に公開開示を行うと、Clineは30分以内にAIトリアージワークフローを削除して修正した
- 翌日に認証情報のローテーションを開始したが、誤ったトークンを削除し、露出したトークンはそのまま有効な状態で残された
- 2月11日にミスを発見して再ローテーションしたが、その時点で攻撃者はすでに認証情報を窃取していた
- npmトークンは6日後に悪性パッケージを配布できるほど十分に有効なままだった
- Khanは攻撃者ではない。別の未知の行為者がKhanのテストリポジトリでPoCを見つけ、Clineに対して直接武器化した
AIがAIをインストールする新たなパターン
- 今回の事件は、AIツールが別のAIエージェントをインストールする形を取り、サプライチェーンにおける再帰的な信頼の問題を引き起こした
- 開発者がTool A（Cline）を信頼する → Tool Aが侵害されてTool B（OpenClaw）をインストールする
→ Tool BはTool Aとは独立した独自機能（シェル実行、認証情報へのアクセス、永続デーモンのインストール）を持ち、開発者の元の信頼判断からは見えない
- OpenClawは
~/.openclaw/から認証情報を読み取り、Gateway API経由でシェルコマンドを実行し、再起動後も維持される永続的なシステムデーモンとして自己インストールできる
- Endor Labsはこれを概念実証レベルのペイロードと評価したが、重要なのは仕組みそのものであり、次のペイロードはPoCではないかもしれない
- これは**「Confused Deputy」問題**のサプライチェーン版であり、開発者が付与した権限が第三のエージェントへ委譲された事例である
- 開発者がClineに代理権限を与え、Clineが（侵害を通じて）開発者が評価・設定・同意したことのない、完全に別のエージェントへその権限を委譲した
既存のセキュリティ統制が失敗した理由
- npm audit:
postinstallスクリプトがインストールするのは合法かつ非悪性のパッケージ（OpenClaw）であり、検知すべきマルウェアが存在しない
- コードレビュー: CLIバイナリは前バージョンとバイト単位で同一で、
package.jsonだけが1行変更されていたため、バイナリ変更に焦点を当てた自動diff検査では検知できなかった
- Provenance attestation: 当時のClineはOIDCベースのnpm provenanceを使っておらず、侵害されたトークンでprovenanceメタデータなしに配布できた
- StepSecurityはこれを**異常（anomalous）**としてフラグした
- 権限プロンプト: インストールは
npm install中のpostinstallフックで発生し、依存関係のライフサイクルスクリプト実行前にユーザーへ確認を求めるAIコーディングツールは存在しないため、操作は見えないままだった
- 開発者がインストールしていると思っているもの（特定バージョンのCline）と、実際に実行されるもの（パッケージの任意のライフサイクルスクリプトや推移的インストール）のあいだのギャップを悪用した
Clineの事後対応
- Post Mortemで公開した改善策
- 認証情報を扱うワークフローでGitHub Actionsキャッシュの使用を廃止
- npm配布にOIDC provenance attestationを導入し、長期トークンを廃止
- 認証情報ローテーションに対する検証要件を追加
- SLAを含む正式な脆弱性開示プロセスの構築を開始
- CI/CDインフラに対する第三者セキュリティ監査を依頼
- OIDC移行だけでもこの攻撃は防げた
- 窃取されたトークンは、特定のGitHub Actionsワークフローによる暗号学的証明を必要とするprovenance体系では、パッケージを配布できない
構造的な問題と教訓
- Clinejectionはサプライチェーン攻撃であると同時に、エージェントセキュリティの問題でもある
- 攻撃の入口はGitHub Issueタイトルの自然言語入力であり、AIボットがそれを命令として実行した
- これはMCPツール汚染やエージェントスキルレジストリ攻撃と同じ構造を持つ
- 信頼できない入力がエージェントに到達 → エージェントが行動 → 結果の処理を実行前に評価する主体が存在しない
- この事例でのエージェントは、開発者のローカルなコーディングアシスタントではなく、すべての新規Issueで実行され、シェルアクセスとキャッシュ済み認証情報を持つ自動化CIワークフローだった
- 影響範囲は1人の開発者のマシンではなく、プロジェクト全体の配布パイプラインに及んだ
- CI/CDにAIエージェントを導入するすべてのチーム（Issueトリアージ、コードレビュー、自動テストなど）は同じ露出を抱える
- 非信頼入力と秘密情報へのアクセス権の結合リスクを認識する必要がある
- エージェントが信頼できない入力（Issue、PR、コメント）を処理しながら、シークレット（トークン、キー、認証情報）にアクセス可能な状態になっている
- システムコール単位のインターセプションは、この種の攻撃を運用レイヤーで捕捉できる:
- AIトリアージボットが想定外のリポジトリで
npm installを実行しようとした際、Issueタイトルの内容とは無関係にポリシーに基づいて評価でき、ライフサイクルスクリプトが外部ホストへ認証情報を流出させようとした際にはegressを遮断できる
3件のコメント
これだけひどい目に遭ったのなら、せめてLLMやエージェントを使う際にはセキュリティにもっと気を配るべきだという認識くらいは広まってほしいものですが..
しばらくはプロンプトインジェクションであちこち大騒ぎになりそうですね
最近、npm package でこうしたことがたびたび起きていますね
Hacker Newsの意見
Clineのissueトリアージワークフローが
issuesイベントで実行され、allowed_non_write_users: "*"に設定されていたつまり、誰でもissueを開くだけで GitHub Actionsをトリガーでき、
--allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"オプションにより、Claudeがデフォルトブランチのワークフロー内で任意コード実行権限を持つ状態だったこんな設定のままAIエージェントを動かすのは正気の沙汰ではないように見える
会社へのソーシャルメディア言及を自動で読み取ってバグレポートを作らせようという試みまである
私は会社でAIポリシー作りを手伝っているが、テストとして脅威的なメールをClaudeに処理させたところ、セキュリティチケット情報をそのまま外部に出力しようとした
幸いメール送信機能が無効化されていたため、実際には送られなかった
こうした無防備なAI自動化は、昔のSQLインジェクション騒ぎを思い出させる。結局、多くの人が痛い目を見てからでないと、まともな安全装置は整わないのだろう
GitHubの
issuesトリガーが、悪名高いpull_request_targetと同じくらい危険だという点を、記事でもっと強調すべきだったユーザー入力がワークフローに入った瞬間から、それは潜在的な攻撃コードとして扱うべきだ
以前はCIはTravis、自動化はZapierと分かれていたが、GitHub Actionsはそれらをすべてひとまとめにし、過剰なほど多くの権限を持っている
Zapierは任意のバイナリを実行しないので、侵害リスクははるかに低かった
入力検証を完全に安全に行う方法は、まだ存在しない
LLMがbase64でエンコードされたコマンドを実行した事例もある（例のリンク）
結局、すべての入力は敵対的データとして扱うべきだ。LLMは自ら行動を「幻覚」で作り出すことすらあるのだから、本番システムへのアクセスは絶対に与えてはならない
本来なら、どのワークフローにも資格情報を含めるべきではなく、メンテナーなど特権ユーザーのイベントにだけ限定されるべきだ
ただしZapierはブラックボックスサービスとして扱われ、セキュリティ責任は全面的にそちら側にある
一方でGHAはGitHubと利用者が共同責任を負う構造なので、より複雑だ
それでもGHAはZapierよりはるかに柔軟で、ほとんどのユーザーは結局LambdaやWebhookで任意コードを実行することになる
問題のタイトルは次のとおりだった
ところが
github:cline/cline#b181e0は、実際には悪意あるpostinstallスクリプトを含むフォーク済みリポジトリを指していた問題のコミットリンク
私もついさっきまで、
github:cline/clineなら同じリポジトリだと思っていたnpmがGitHub連携によってどこまで緩和できるのか気になる
issueタイトルが
${{ github.event.issue.title }}としてClaudeのプロンプトにそのまま挿入され、入力サニタイズなしで処理されたことが問題だったしかしClaudeはプロンプト内の要求を「親切に理解」しようとするため、単純なサニタイズだけでは効果がなかっただろう
すべてのnpmコマンドは必ずサンドボックス環境で実行すべきだ
私はこうした攻撃ベクターが増えているのを見て、amazing-sandboxを自作した
Clineをインストールまたは更新したすべての開発者は、8時間のあいだOpenClawという別のAIエージェントをシステム全体にインストールさせられていた
ただし、npm設定で
ignore-scripts=trueを使っていた人は例外だったClineの事後分析ポストモーテムに関連事実がよく整理されている
ただしOpenClawを「無害なペイロード」と見るか、トロイの木馬と見るかは立場による
AIやAIツールを完全に信頼する人はいないだろう
こうした事件は、その事実を改めて強く思い出させる
検索してみると、OpenClawを「バイラルAIエージェント」と呼ぶ記事もあった
昔なら、この種のソフトウェアをインストールした時点で、すでにシステム侵害と見なされていただろう
任意権限を持つコードが信頼されていない入力を実行するという構造自体が問題なのに、今回の場合はそれがむしろ製品の中核価値として売り込まれている
AI企業がいまだにSQLインジェクションとプロンプトインジェクションの類似性を理解していないのは驚きだ
プロンプトにも同じ保護が必要だ