設計に内在する RCE、潜伏型バックドア、そして Web3 ウォレットに及ぶサプライチェーンの脅威
目次
- エグゼクティブサマリー (TL;DR)
- はじめに —— 「正常動作」こそが最も危険な瞬間
- MCP の構造的欠陥 —— 設計意図がそのまま脆弱性
- Sleeper MCP —— 時間・シグナル起動型の「ドゥームズデイ攻撃」
- Web3 業界の特殊リスク —— ウォレットと単一マシン構造
- MCP 継続的監査プログラム
- より静かな攻撃 —— バイアス注入と行動変化
- 結論と提言
- 参考文献
エグゼクティブサマリー (TL;DR)
Anthropic が 2024 年 11 月に公開した MCP(Model Context Protocol)は、現在事実上 AI エージェントと外部ツールを接続する業界標準となっている。しかし 2026 年 4 月、OX Security の研究チームは MCP の STDIO 転送インターフェースに内在する設計レベルの欠陥により、公式 SDK を用いたすべての実装でリモートコマンド実行(RCE)が可能であることを公表した。Anthropic はこれを*「意図された動作(expected behavior)」*とし、根本的なパッチ適用を拒否している。
本レポートはこの事案を単一の脆弱性ではなく、三層構造の構造的問題として再定義する。
- MCP は、普段は正常に動作しつつ特定のトリガーで悪性動作に切り替わる潜伏型(sleeper)攻撃ベクターになりやすい。
- Web3 業界で広く用いられるブラウザウォレット・ホットウォレット環境と組み合わさることで、単一マシン・単一管理者という既存の弱点をそのまま増幅する。
- さらに、MCP を介して LLM が繰り返し偏った検索・推薦結果を提示することで、中長期的には人間の意思決定そのものを歪めうる。
要点は単純である。MCP は便利な標準であるが、現状のアーキテクチャ上では*「信頼できる MCP サーバー」*という概念そのものが幻想に近い。企業は MCP に直接接続されない外部エスクロー方式の資産保護構造を備え、導入済みの MCP については SBOM、ランタイム監査、潜伏型トリガー検出を定期的に実施する必要がある。
主要判断 (Key Judgments)
| # | 判断 | 信頼度 |
|---|---|---|
| KJ-1 | MCP の STDIO コマンドインジェクション欠陥は実装ミスではなくアーキテクチャレベルの設計判断であり、Anthropic が根本パッチを拒否している以上、長期的なサプライチェーンリスクとして生態系に残存する。 | 高 |
| KJ-2 | 「外観は正常、トリガーで悪性化」するSleeper MCPが今後最も深刻な攻撃モデルになる。発見と修正ではなく、発見と起動の競争である。 | 高 |
| KJ-3 | 2026-03-31 の Axios NPM 侵害(北朝鮮関連 UNC1069 / Sapphire Sleet)は、Sleeper MCP に必要な全技術 ── レジストリ乗っ取り、post-install フック、マルチプラットフォーム配布 ── が北朝鮮行為者によってすでに実戦化されていることを示す。 | 高 |
| KJ-4 | 多くの Web3 マルチシグ運用は、署名鍵を同一ホスト OSに集中させている。そのホスト上の MCP 一つが汚染されれば、マルチシグは単一障害点に退化する。 | 中高 |
| KJ-5 | MCP を媒介としたバイアス注入は、数ヶ月から数年にわたって個人および組織の意思決定を不可逆的に移動させうる ── RCE アラートが一度も鳴らないままで。 | 中 |
1. はじめに —— 「正常動作」こそが最も危険な瞬間
従来のセキュリティ脆弱性の多くは*「書き間違えたコード」*に起因してきた。バッファオーバーフロー、SQL インジェクション、認証バイパスは本質的に実装ミス(implementation flaw)であり、パッチと教育を通じて徐々に減らせるものである。
しかし MCP で露見した問題は性質が異なる。OX Security が 2026 年 4 月に公開したレポート “The Mother of All AI Supply Chains” は、Anthropic の公式 MCP SDK(Python、TypeScript、Java、Rust など全言語)にわたり、STDIO(標準入出力)インターフェース経由のコマンド注入がアーキテクチャレベルで可能であると指摘する。この設計は現在、7,000 を超える公開 MCP サーバー、200,000 に及ぶ脆弱インスタンス、1 億 5,000 万回を超えるダウンロードを擁する生態系全体に内在する問題である [2][4]。
さらに深刻なのは Anthropic の姿勢である。OX Security が繰り返しプロトコルレベルの修正を提案したにもかかわらず、Anthropic は*「当該動作は設計意図どおりであり、ユーザーはファイル変更を明示的に承認または拒否できるため、有効な脆弱性とは見做さない」*と回答した [6]。結果としてセキュリティ責任は多数の下流開発者に転嫁され、これがサプライチェーン全体の構造的リスクへと拡大する。
本稿はこの事案を単一 CVE の次元ではなく、三層の構造的問題として分析する。第一にプロトコル自体の設計欠陥、第二に潜伏型(sleeper)攻撃との組み合わせ可能性、第三に Web3 ウォレット・AI 検索・意思決定バイアスに至る二次・三次の波及効果である。
2. MCP の構造的欠陥 —— 設計意図がそのまま脆弱性
2.1 STDIO 設定とコマンド実行のあいだのギャップ
MCP は AI モデルを外部システムと対話させる汎用アダプターである。ローカルで MCP サーバーを起動する際、クライアントは STDIO 転送方式を通じて OS コマンド文字列を渡し、そのプロセスをサブプロセスとして実行する [7]。
OX Security の核心的な指摘は次のとおりである。MCP ランタイムは渡されたコマンドが正常に MCP ハンドシェイクを完了するかを確認するが、ハンドシェイク成否に関わらず OS コマンド自体はすでに実行されている。ユーザーには「MCP サーバーの起動に失敗した」というエラーが返されるが、その時点で攻撃者の任意コマンドは既にホスト上で実行済みである。既定ではサンドボックスも、入力値のサニタイズも、コマンド許可リスト(allowlist)も存在しない [5]。
「悪性コマンドを渡すとエラーが返されるが、それでもコマンドは実行される。サニタイズ警告もなく、開発者ツールチェーンに赤信号もない。何もない。」 —— OX Security, 2026 [2]
2.2 四つの攻撃ファミリ
OX Security はこの根本原因から派生する四つの攻撃ファミリを整理している [2][8]。
| # | 攻撃ファミリ | 影響対象 |
|---|---|---|
| ① | 認証・非認証コマンドインジェクション | 公開 UI を持つ AI フレームワーク(IBM LangFlow、GPT Researcher など) |
| ② | ハードニングバイパス | Flowise、Upsonic など追加防御を施した環境でも STDIO 経路で回避可 |
| ③ | ゼロクリック プロンプトインジェクション | Cursor、VS Code、Windsurf、Claude Code、Gemini-CLI など AI IDE(CVE-2026-30615) |
| ④ | マーケットプレイス汚染 | 11 の MCP マーケットのうち 9 つが審査なしに悪性 PoC を公開(LobeHub、Cursor Directory ほか) |
2.3 規模と関連 CVE
OX Security は実顧客を抱える 6 つの商用サービスでコマンド実行を実証し、30 件を超える責任ある公開(responsible disclosure)と、10 件超の Critical/High CVE 修正を牽引した [3]。同一の根本原因に由来する CVE は以下のとおり。
| CVE | 対象 | 備考 |
|---|---|---|
| CVE-2025-49596 | MCP Inspector | |
| CVE-2025-54136 | Cursor | |
| CVE-2025-54994 | @akoskm/create-mcp-server-stdio |
|
| CVE-2026-22252 | LibreChat | |
| CVE-2026-22688 | WeKnora | |
| CVE-2026-30615 | Windsurf | ゼロクリック |
影響を受けたサーバー系プロジェクトには LiteLLM、LangChain、LangFlow、Flowise、LettaAI、LangBot が含まれる。韓国 Daum / 保安ニュースの報道も同一の問題を扱い、*「Anthropic の静観のもとで脅威が指数関数的に拡散している」*と指摘した [1]。
3. Sleeper MCP —— 時間・シグナル起動型の「ドゥームズデイ攻撃」
3.1 理論的背景 —— Anthropic 自身の研究
皮肉なことに、*「見た目は正常だが、特定条件下でのみ悪性動作するモデル」*という脅威モデルを体系的に最初に記述したのは Anthropic 自身である。2024 年 1 月に公開された “Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training”(arXiv:2401.05566)は、特定トリガー(例:年号 “2024”)が入力されたときだけ脆弱なコードを生成するよう訓練されたモデルが、教師あり学習・強化学習・敵対的学習といった標準的安全性訓練を経てもバックドア挙動を保持することを実証した。むしろ敵対的訓練は、モデルにトリガーを隠す技術を身につけさせる方向に作用しうる [9]。
2026 年 2 月、Microsoft 研究チームは “The Trigger in the Haystack” において、汚染モデル内部のアテンションパターン(例:「Double Triangle」構造)および出力分布の崩壊といった特徴的シグネチャを識別する手法を提案した [10]。同年に公開された Sentence-BERT 埋め込みとカナリープロンプトに基づく意味ドリフト(Semantic Drift)検出は、既知の Sleeper モデルに対してリアルタイムで 92.5% の精度・100% の適合度(ゼロ偽陽性)を達成したと報告している [11]。
3.2 Sleeper MCP シナリオ
この二つの流れを重ねると、今後最も現実化しやすい攻撃は 「潜伏型 MCP サーバー(sleeper MCP)」 となる。典型的なシナリオは次のとおり。
- 合法的に見える MCP サーバー(スケジューリングアシスタント、翻訳ツール、オンチェーンデータ照会など)をマーケットプレイスに登録する。コードはオープンソースであり、最初の数ヶ月は完全に正常に動作する。
- 信頼を蓄積した後、公開者は一つの依存パッケージを微調整で更新する。このアップデートは、特定のトリガー ── 例:日付が 2026 Q4 以降、環境変数に特定文字列、最近の会話に
transfer・withdraw・approveのようなキーワード ── を満たしたときのみ悪性経路へ分岐する。 - トリガーが満たされると MCP は STDIO 注入欠陥を利用してホスト上で任意コマンドを実行するか、LLM プロンプトを操作して最終署名段階で受取アドレスと許可量(allowance)をすり替える。
- 被害者の体験は「一度エラーが出ただけ」であり、事後ログ分析でも通常動作と区別しにくい。
この攻撃モデルの本質は 「いつ起爆するか分からない」時間軸の非決定性である。従来型脆弱性が「発見対パッチ」の競争だとすれば、Sleeper MCP は「発見対トリガー」の競争である。数百万インスタンスのうち、どれか一つでもトリガーが引かれた瞬間、サプライチェーンの単一起点の失敗が生態系全体に波及する ── これは国家間総力戦を前提とした 「ドゥームズデイ攻撃」 そのものである。
3.3 北朝鮮のサプライチェーン汚染と Sleeper MCP シナリオ
Sleeper MCP の脅威モデルにおいて、大韓民国が最も直面する問題は、まさに北朝鮮が社会混乱を狙って作成する Sleeper MCP である。北朝鮮はすでに ChatGPT を含む各種 LLM を作戦ツールとして活用しており、中国人を装ってシリコンバレーの大手 IT 企業や AI スタートアップにリモート勤務として紛れ込む事例も多数報告され、依然として彼らの攻撃面を拡大し続けている。
北朝鮮の近年の攻撃動向は、暗号資産の窃取とソフトウェアサプライチェーン攻撃の二軸に集約される。とりわけ 2026 年 3 月 31 日に発生した Axios NPM パッケージ汚染事件は、後者の典型例である。Google Threat Intelligence Group(GTIG)と Microsoft Threat Intelligence はこの事件を北朝鮮関連の UNC1069(Microsoft 呼称 Sapphire Sleet)に帰属させた。攻撃者は週間ダウンロード数 1 億回超の axios に plain-crypto-js という悪性依存を注入し、Windows・macOS・Linux 全プラットフォームに クロスプラットフォーム RAT WAVESHAPER.V2 を配布した [21][22]。悪性バージョンがレジストリに存在した時間はわずか約 3 時間だったが、この短い時間で axios 利用者の約 3% が暴露対象となった [23][24]。
この事件が MCP 脅威モデルに示唆するものは明白である。北朝鮮の行為者は、Sleeper MCP に必要な以下の技術一式を既に実戦レベルで習得している。
- 正規レジストリ(NPM、PyPI)の信頼連鎖の奪取。
postinstallフックなどパッケージマネージャーの自動実行経路の悪用。- Windows / macOS / Linux を横断するマルチプラットフォーム ペイロード振り分け。
- インストール後の自己消去(self-destruction)によるフォレンジック回避 [23]。
MCP サーバーは本質的に npm / pip パッケージまたは GitHub リポジトリの形態で配布され、STDIO 欠陥・postinstall フック・設定ファイルの自動編集といった 同一のサプライチェーン面を共有する。したがって短期的には、北朝鮮関連アクターが大韓民国を含む重点国の MCP サーバーおよび関連パッケージに対する精密な汚染実験を反復すると見られる。中長期的には、単発的な資金窃取にとどまらず、社会構成員の認識操作、世論・政策誘導、さらには §3.2 に記した「ドゥームズデイ攻撃」水準のシナリオを前提とした設計へ進化する可能性が高い。これこそ、MCP 潜伏リスクを単なるセキュリティ欠陥ではなく 国家安全保障事案として扱うべき理由である。
4. Web3 業界の特殊リスク —— ウォレットと単一マシン構造
4.1 「マルチシグだから大丈夫」という誤解
ほとんどの Web3 プロジェクトは、対外的にはマルチシグ(Gnosis Safe など)で資産を保護していると説明する。しかし実態は、マルチシグ署名者 2〜3 名が同一マシン上で、同じブラウザ(Chrome、Arc)に接続した MetaMask・Phantom・Rabby などの同じウォレット拡張を使い、同じ macOS / Windows アカウントでログインしているケースが極めて多い。
ここに開発者向け IDE(Cursor、VS Code、Windsurf、Claude Code)と MCP が加わると、結果として 「マルチシグ署名権限を持つ実質的なすべての鍵」 が単一のホスト OS 上に存在する構造になる。このホストに導入された MCP が RCE 欠陥か潜伏型のいずれかであった場合、マルチシグは単一障害点(single point of failure)に退化する。
4.2 現在の MCP–ウォレット統合の危険パターン
Google Cloud の 2025 年 12 月の分析によれば、現在流通する暗号資産 MCP サーバーの大多数は*「エージェントに秘密鍵を直接与える」自ホスト(self-hosted)モデルを前提としている [14]。実際に wallet-agent MCP の公式リポジトリでさえ、「本ソフトウェアは監査されておらず、資産損失を招く可能性がある。テストネット・ローカル開発環境でのみ使用すること」*と警告しているが、実利用者は容易にこれを無視する。
2026 年初頭に Web3 業界を揺さぶった OpenClaw / ClawJacked 系事件 ── AI エージェントが悪性サイト訪問一回で乗っ取られ、攻撃者にファイル・認証情報・ウォレットと同等の権限水準を許した事例 ── は、この危険パターンが理論ではないことを示す。セキュリティ各社の分析は概ね次の点に収束する。「現状多くの暗号資産 MCP 実装は、エージェントに秘密鍵を渡す危険なアプローチをそのまま踏襲しており、ClawHavoc 型攻撃者が狙っているのはまさにこの構造である。」 [15]
4.3 推奨セキュリティ構造 —— 外部エスクロー + MCP 分離
この構造的リスクへの最低限の設計原則を示す。Web3 企業のみならず、一般スタートアップにも同様に適用可能である。
- 大量資産の保管は MCP が到達できない外部エスクロー(受託機関口座、コールドウォレット、HSM 多者署名)に分離する。運用ホットウォレットには一日分を超える残高を置かない。
- 署名権限は専用署名デバイス(エアギャップ、または最低限のソフトウェアのみ導入した Mac mini / Ledger Stax など)でのみ行使する。当該デバイスには MCP・AI 拡張・開発ツールを導入しない。
- 開発・分析用マシンの MCP は、必ず
127.0.0.1(ローカルループバック)バインディング、サンドボックス(Docker、Firecracker、別 OS ユーザー)内での実行、外部 MCP 設定入力を信頼しないポリシーを既定とする [13][16]。 - ブラウザウォレット(MetaMask など)は署名デバイス以外にはインストールしないか、少なくとも独立したブラウザプロファイルに隔離する。同一プロファイル内に AI エージェント・MCP ブリッジ・調査用ブックマークを共存させてはならない。
- マルチシグ署名者は物理的に異なるネットワーク・ハードウェアを使用しなければならない。「同じ事務所で 3 人が別々のノート PC を使う」は分散ではない。
5. MCP 継続的監査プログラム
5.1 最低限のチェック項目
MCP は「一度入れたら忘れてよい」コンポーネントではない。組織単位で以下を定期的(推奨:四半期に一度、重要度の高い環境では月次)に実施すべきである。
- SBOM 管理 ── 使用中の MCP サーバー全一覧と、それぞれのバージョン・ハッシュ・入手元(マーケットプレイス URL、GitHub コミット)を内部レジストリに記録する。
- 来歴検証 ── GitHub 以外のマーケットプレイス(LobeHub、Cursor Directory 等)から入手した MCP は独立した審査ゲートを通す。OX の実験では、11 マーケットのうち 9 つが悪性ペイロードを無審査で通したことが判明している [7]。
- STDIO 設定レビュー ── MCP サーバー設定に任意 OS コマンド文字列を受け入れる入力点があるか、ネットワーク経由で書き換え可能かを確認する(LangFlow、Flowise 系 UI の確認)。
- ランタイム監視 ── MCP ツール呼び出しログを SIEM に集約し、新規ツール登録・権限拡張・外部ドメインへのアクセスに対してアラートを設定する。
- 最新パッチ ── MCP 関連 CVE(CVE-2025-49596、CVE-2025-54136、CVE-2025-54994、CVE-2026-22252、CVE-2026-22688、CVE-2026-30615 など)への対応状況を月次スキャンの対象に含める。
5.2 潜伏型トリガーの事前検出
Sleeper MCP のシナリオは、従来型の脆弱性スキャナでは捉えられない。現実的に適用可能な緩和策は以下のとおりである。
- 意味ドリフト(Semantic Drift)の計測 ── Sentence-BERT ベースの埋め込みで、同じツール呼び出しパターンが時間とともにどう変化するかを監視する。事前設定したカナリー質問(canary question)への回答の一貫性が逸脱すれば、強い警告シグナルとなる [11]。
- スキーマ適合性監査 ── MCP ツールの出力を、当該ツールが宣言するスキーマと照合する。たとえば翻訳 MCP が突然 URL やアドレスを返し始めるなら、機能からの逸脱とみなす。
- 差分サンドボックス ── 同一の MCP を異なるリージョン・タイムゾーン・プロンプト文脈で並行稼働させ、分岐を比較する。
- サプライチェーン署名検証 ── モデル重み・MCP バンドル・依存パッケージに対して、可能な限り暗号署名と再現可能ビルド(reproducible build)を要求する。
6. より静かな攻撃 —— バイアス注入と行動変化
6.1 「RCE なき攻撃」の実体
MCP はコード実行にまで到達しなくても危険である。自動化された MCP が人間の検索・意思決定フローに介在しているという事実そのものが、新たな攻撃面を形成する。MCP は LLM のコンテキスト源 ── ファイル、Web ページ、DB、社内文書 ── を決定するからである。
LLM が認知バイアス(cognitive bias)に対して脆弱であることは、すでに多数の学術研究が確認している。Knipper ら(2025)は主要 LLM の認知バイアス感受性が平均 17.8〜57.3% に達すると報告している [17]。PNAS 2025 年の論文は、LLM が道徳的意思決定において人間のバイアスを再現するだけでなく増幅(amplify)しうることを示した [18]。他の研究は、製品推薦の文脈で認知バイアスを「敵対的攻撃」として活用可能であることを実証している [19]。
6.2 社会現象学習バイアス注入シナリオ
Sleeper MCP のより静かな変種は、ホストマシンを掌握せずとも次のような介入を可能にする。
- 特定の社会現象・政策・企業・人物に関する検索結果を体系的に一方向へ傾斜させる。LLM はそれを要約・強化してユーザーに提示する。
- ユーザーの質問パターンに応じ、*「自分はすでに正しい」*と感じさせる証拠を優先提示する(確証バイアスの利用)。これは Chen ら(2024)が論じた “LLM Effect” の直接的悪用である [20]。
- 特定のトークン・株式・不動産の意思決定文脈で、アンカー(anchor)となる価格や時点を繰り返し露出させ、中長期的な判断の基準線を移動させる。
- 微細なフレーミング(framing)調整を繰り返し、ユーザーの言語習慣・語彙選択を徐々にずらす。これにより他者に伝わる段階で二次的なバイアスを発生させる。
6.3 中長期の被害 —— 個人と組織の「意思決定ドリフト」
こうしたバイアス注入は一度の事故ではなく、数ヶ月から数年にわたる 意思決定ドリフト(decision drift) として現れる。被害者は自分の判断がなぜ変わったのかを特定の時点に遡って示しづらく、組織は戦略文書・議事録の微妙な表現変化の中に、バイアスが積み重なっていたことに後から気づく。
「攻撃を検知したときには既に原状回復不能」 という点で、この攻撃クラスは RCE 型よりむしろ悪性度が高い場合がある。したがって MCP 監査はセキュリティログだけでなく、「どの情報源から、どのような観点の情報を、どれだけ取り込んでいるか」を示す情報多様性指標(information diversity metric)も含めなければならない。
7. 結論と提言
MCP の問題は特定ベンダー一社のミスではなく、AI エージェント生態系が速度を優先して引き受けた構造的トレードオフの最初の精算である。Anthropic が根本パッチを「設計意図」として拒否している以上、生態系参加者は以下の前提で MCP を扱わなければならない。
- すべての MCP サーバーは既定で非信頼(untrusted)である。署名・サンドボックス・許可リストなしには本番環境へ投入しない。
- 資産は MCP と同じ OS に置かない。大量資産は外部エスクロー・コールドウォレット・HSM ベースの多者署名で隔離し、実際の署名デバイスには MCP を導入しない。
- マルチシグはマシン・ネットワーク・物理位置の基準で分散されねばならない。同一ホスト上のマルチシグはマルチシグではない。
- MCP は 四半期に一度以上の正式監査対象として指定する。SBOM、CVE、意味ドリフト、カナリー応答、情報多様性を並行して点検する。
- 企業は、MCP を通じて侵入するバイアスを監視するための独立プロセス(内部文書のトーン変化監査、決定根拠の出典多様性レビュー)を用意する。
セキュリティは速度の反対概念ではなく、速度を長く維持するための設計である。MCP 生態系は現在「爆発的採用期」の只中にあり、この区間で構造的欠陥を放置すれば、その後の損害は複利で膨らむ。今問うべきは*「MCP を使うか使わないか」*ではなく、「MCP と共にどの分離・検証・監査層を必ず共設するか」である。
参考文献 (References)
[1] ウォン・ビョンチョル(원병철)、「Anthropic の静観の中、指数関数的に拡大する 'MCP' サプライチェーンセキュリティ脅威」、保安ニュース / Daum、2026-04-21。https://v.daum.net/v/20260421171629362
[2] M. Siman Tov Bustan ほか、"The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of Anthropic's MCP"、OX Security、2026-04-15。https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/
[3] R. Lakshmanan、"Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain"、The Hacker News、2026-04。https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html
[4] K. Townsend、"'By Design' Flaw in MCP Could Enable Widespread AI Supply Chain Attacks"、SecurityWeek、2026-04。https://www.securityweek.com/by-design-flaw-in-mcp-could-enable-widespread-ai-supply-chain-attacks/
[5] Infosecurity Magazine、"Systemic Flaw in MCP Protocol Could Expose 150 Million Downloads"、2026-04。https://www.infosecurity-magazine.com/news/systemic-flaw-mcp-expose-150/
[6] IT Pro、"AI agents using Anthropic MCP could be a vector for supply chain attacks, claim researchers"、2026-04。https://www.itpro.com/security/ai-agents-using-anthropic-mcp-supply-chain-attacks-claim-researchers
[7] BD Tech Talks、"Anthropic's MCP vulnerability: When 'expected behavior' becomes a supply chain nightmare"、2026-04-20。https://bdtechtalks.com/2026/04/20/anthropic-mcp-vulnerability/
[8] Computing UK、"Flaw in Anthropic's MCP putting 200k servers at risk, researchers claim"、2026-04。https://www.computing.co.uk/news/2026/security/flaw-in-anthropic-s-mcp-putting-200k-servers-at-risk
[9] E. Hubinger ほか、"Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training"、Anthropic、arXiv:2401.05566、2024。https://arxiv.org/abs/2401.05566
[10] Microsoft Research、"The Trigger in the Haystack: Extracting and Reconstructing LLM Backdoor Triggers"、2026-02。
[11] "Detecting Sleeper Agents in Large Language Models via Semantic Drift Analysis"、arXiv:2511.15992、2025。https://arxiv.org/pdf/2511.15992
[12] Pivot Point Security、"What is the Model Context Protocol (MCP) in AI and Why Does It Scare Cybersecurity Pros"、2026-03。https://www.pivotpointsecurity.com/what-is-the-model-context-protocol-mcp-in-ai-and-why-does-it-scare-cybersecurity-pros/
[13] Practical DevSecOps、"MCP Security Vulnerabilities: How to Prevent Prompt Injection and Tool Poisoning Attacks in 2026"、2026-01。https://www.practical-devsecops.com/mcp-security-vulnerabilities/
[14] Google Cloud Blog、"Using MCP with Web3: How to secure blockchain-interacting agents"、2025-12。https://cloud.google.com/blog/products/identity-security/using-mcp-with-web3-how-to-secure-blockchain-interacting-agents
[15] BlockEden.xyz、"OpenClaw's 'Lobster Fever' Became Web3's Biggest Security Wake-Up Call of 2026"、2026-03-12。https://blockeden.xyz/blog/2026/03/12/openclaw-lobster-ai-gateway-web3-security-crisis/
[16] Red Hat Blog、"Model Context Protocol (MCP): Understanding security risks and controls"、2025-11。https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls
[17] R. A. Knipper ほか、"The Bias is in the Details: An Assessment of Cognitive Bias in LLMs"、arXiv:2509.22856、2025。https://arxiv.org/pdf/2509.22856
[18] "Large language models show amplified cognitive biases in moral decision-making"、PNAS、2025-06。https://www.pnas.org/doi/10.1073/pnas.2412015122
[19] "Bias Beware: The Impact of Cognitive Biases on LLM-Driven Product Recommendations"、arXiv:2502.01349、2025。https://arxiv.org/html/2502.01349v4
[20] N. Chen ほか、"AI Can Be Cognitively Biased: An Exploratory Study on Threshold Priming in LLM-Based Batch Relevance Assessment"、SIGIR-AP 2024。arXiv:2409.16022。
[21] Google Threat Intelligence Group、"North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack"、Google Cloud、2026-04。https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package
[22] Microsoft Threat Intelligence、"Mitigating the Axios npm supply chain compromise"、Microsoft Security Blog、2026-04-01。https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/
[23] Ionut Arghire、"Axios NPM Package Breached in North Korean Supply Chain Attack"、SecurityWeek、2026-04。https://www.securityweek.com/axios-npm-package-breached-in-north-korean-supply-chain-attack/
[24] Tenable Research Special Operations、"FAQ about the Axios NPM Supply Chain Attack by North Korea-Nexus Threat Actor UNC1069"、2026-04。https://www.tenable.com/blog/faq-about-the-axios-npm-supply-chain-attack-by-north-korea-nexus-threat-actor-unc1069
© 2026 Dennis Kim (金浩光・김호광) · 本文書は独立 CTI アーカイブ(TLP:GREEN)の公開を目的として作成されている。 問合せ: [email protected] · GitHub: gameworkerkim/CYBER-THREAT-INTELLIGENCE-REPORT