2026年5月、セキュリティ研究企業Socket.devが検出した「TrapDoor」キャンペーンは、サプライチェーン攻撃の構造を根本から変えた。npm・PyPI・Crates.ioの3レジストリに34パッケージ・384バージョンを同時展開し、さらにCursorの.cursorrulesやClaude CodeのCLAUDE.mdにゼロ幅Unicode文字で隠蔽した悪性プロンプトを注入する──これは単なるマルウェア配布ではなく、AI開発者のワークフロー全体を攻撃面に変える産業構造の転換点である。従来のLiteLLM侵害やShai-Hulud連鎖攻撃が単一エコシステム内の侵害にとどまったのに対し、TrapDoorは言語境界を超えた同時展開と、AI IDEの信頼モデルそのものの悪用という二重の構造的脅威を提示した。本稿では、TrapDoorの技術的全貌を解剖し、多層防御の実装標準を定義する。

TrapDoor キャンペーンの全体構造 ── 34パッケージ384バージョン3エコシステム同時展開の手法

TrapDoorキャンペーンの最も特異な点は、npm・PyPI・Crates.ioという3つの異なるパッケージレジストリに対する同時攻撃を単一のキャンペーンとして統合した点にある。Socket.devの調査によれば、キャンペーンの最初期の活動は2026年5月19日に検出され、攻撃者はGitHubアカウント「ddjidd564」を起点として、複数のエコシステムに標的パッケージを展開した。

npm向けにはpostinstallフックを悪用し、npm install完了直後にtrap-core.jsと呼ばれる1,149行・48,485バイトのクレデンシャルハーベスターを実行する。このスクリプトはSSH鍵、AWS認証情報、GitHubトークン、ブラウザのログインデータベース、暗号通貨ウォレット拡張のデータ、環境変数、APIキーを網羅的にスキャンする。特筆すべきは、窃取した認証情報をAWSおよびGitHub APIに対してリアルタイムで検証し、高価値トークンのみをフィルタリングする「選別型」の窃取手法を採用している点である。これにより、ノイズの多い低価値データを除外し、攻撃者のオペレーション効率を最大化する。

PyPI向けにはインポート時実行（import-time execution）を採用した。eth-security-auditor、cryptowallet-safety、defi-risk-scanner、env-loader-cliといったパッケージ名は、暗号通貨開発者やセキュリティツール利用者を明確にターゲットとしている。これらのパッケージはインポート時に攻撃者が管理するGitHub Pagesドメイン（ddjidd564.github.io）からJavaScriptペイロードをダウンロードし、node -eコマンドで実行する。ペイロードをレジストリ内のパッケージ本体から分離することで、静的解析ツールの検出を回避しつつ、新バージョンを公開せずにペイロードを動的に更新できる構造を実現した。

Crates.io（Rust）向けにはbuild.rsスクリプトを悪用し、cargo build時に実行される仕組みを構築した。move-analyzer-buildやsui-framework-helpersといったパッケージ名はSui・Solana・Aptosなどのブロックチェーン開発者を標的としており、ローカルのキーストアを検索し、ハードコードされたXORキー「cargo-build-helper-2026」でデータを暗号化した上でGitHub Gistsに送信する。Rustエコシステムがサプライチェーン攻撃の主要標的として選定されたのは初めてであり、Crates.ioのセキュリティモデルに対する新たな脅威カテゴリの出現を意味する。

3エコシステム同時展開の戦略的意図は明確である。JavaScript・Python・Rustという現代のソフトウェア開発を支える3言語を同時に攻撃することで、攻撃面を最大化し、いずれかのレジストリが迅速に対応しても残りのレジストリで攻撃を持続できる耐障害性を確保した。筆者の経験では、脆弱性診断やペネトレーションテストの実務において、単一の攻撃ベクトルだけを想定した防御体制がいかに脆弱であるかを幾度となく目の当たりにしてきたが、TrapDoorはまさにその盲点を組織的に突いた攻撃である。

.cursorrules ゼロ幅Unicode隠蔽 ── AI IDEの信頼モデルを逆転させる攻撃手法

TrapDoorキャンペーンが従来のサプライチェーン攻撃と決定的に異なるのは、パッケージレジストリの汚染に加えて、AI IDEの設定ファイルを攻撃ベクトルとして利用した点である。具体的には、Cursorの.cursorrulesファイルとClaude CodeのCLAUDE.mdファイルに、ゼロ幅Unicode文字を使って人間には不可視だがLLMトークナイザーには完全に可視な悪性プロンプトを埋め込む手法が確認された。

使用されたゼロ幅Unicode文字は4種類である。U+200B（ゼロ幅スペース）、U+200C（ゼロ幅非接合子）、U+200D（ゼロ幅接合子）、U+FEFF（バイトオーダーマーク、テキスト中間での使用）。これらの文字は標準的なテキストエディタでは完全に不可視であり、開発者がファイルを目視確認しても異常を検出できない。一方、LLMのトークナイザーはこれらの文字を正常にトークン化するため、AIアシスタントは隠蔽されたプロンプトを「正規の開発指示」として解釈し実行する。

攻撃者は隠蔽プロンプトを通じて、AIアシスタントに「セキュリティスキャン」と称した偽のワークフローを実行させる。具体的には、プロジェクト内の.envファイル、SSH鍵、API認証情報をAIアシスタントの権限で読み取り、外部サーバーに送信させる。開発者の視点からは、AIアシスタントが通常のコード生成やレビューを行っているようにしか見えず、バックグラウンドでの認証情報窃取に気づくことは極めて困難である。

この攻撃の配布メカニズムも巧妙である。攻撃者はLangChain、MetaGPT、OpenHands、browser-use、langflow-aiといった著名なAI/MLプロジェクトに対して、悪意ある.cursorrulesファイルを含むプルリクエストを提出した。これらのPRは一見すると「プロジェクトのAIアシスタント設定を最適化する」正当な貢献に見えるため、コードレビューで見落とされるリスクが高い。GitHubは後にこれらのファイルに「隠蔽されたまたは双方向Unicodeテキストを含む」という警告フラグを追加したが、攻撃が発覚した時点で複数のPRがマージされていた可能性がある。

この手法が示す構造的脅威は、MCP 20万脆弱性インスタンスの構造的欠陥と同根の問題を突いている。AI IDEの設計思想は「開発者の指示を忠実に実行する」ことを前提としており、設定ファイルに書かれた内容が悪意あるものかどうかを判別する機構が存在しない。つまり、AI IDEの「信頼モデル」そのものが攻撃面となっている。従来のIDEはコードを表示するだけだったが、AI IDEはコードを解釈し実行する──この能力の差が、攻撃者にとってまったく新しい攻撃カテゴリを生み出した。

さらに懸念されるのは、ゼロ幅Unicode隠蔽がプロンプトインジェクションの「ステルス化」を可能にしたことである。従来のプロンプトインジェクション攻撃は、悪意あるテキストが可視状態で存在するためコードレビューで検出できた。しかしゼロ幅文字による隠蔽は、人間のレビュアーを完全にバイパスし、LLMだけが読み取れる「不可視チャネル」を確立する。これはステガノグラフィ（情報隠蔽術）の概念をプロンプトインジェクションに応用した初の大規模実用例であり、AIセキュリティにおけるパラダイムシフトである。

AI開発者が最優先攻撃対象となった産業構造転換 ── 「開発環境＝本番侵害」の等式

TrapDoorが暴露した最も深刻な構造的問題は、AI開発者の開発環境が事実上の「本番環境への直通路」となっている現実である。AI開発者の作業環境には、クラウドサービスのAPIキー、データベース接続文字列、暗号通貨ウォレットの秘密鍵、CI/CDパイプラインの認証トークンなど、本番環境に直結する認証情報が集中している。npm installやpip installの一回の実行が、これらの認証情報すべてを攻撃者に渡す契機となる。

TrapDoorのtrap-core.jsは、窃取した認証情報の永続化（persistence）にも注力している。Git hooks、シェルフック、systemdサービス、cronジョブ、SSH鍵を使った横展開（lateral movement）の5つの永続化メカニズムを同時に設置する。つまり、一度のnpm installで攻撃者は開発者のマシンに複数の足場を確保し、パッケージが削除された後も侵害状態を維持できる。これは、従来の「パッケージを削除すれば解決」という想定を完全に覆す。

この構造転換の背景には、AI開発ワークフローの変化がある。2025年から2026年にかけて、Cursor、Claude Code、GitHub Copilot Workspaceなどの「AIエージェント型」開発環境が急速に普及した。これらの環境では、AIが自律的にファイルシステムにアクセスし、コマンドを実行し、外部APIと通信する。攻撃者にとって、AIエージェントは完璧な「内部協力者」である──正規の権限を持ち、正規のプロセスとして動作し、セキュリティツールからは正常な開発活動として認識される。

Socket.devの検出データは、この脅威の規模を数値で示している。TrapDoorのパッケージは公開から平均5分56秒で検出され、最速では58秒で検出されたにもかかわらず、その短い時間枠でも複数のインストールが記録された。これは、自動依存関係解決やCI/CDパイプラインの自動ビルドが、人間の判断を介さずに悪意あるパッケージをインストールしてしまう現実を示している。

もう一つの重要な構造変化は、TrapDoorに関連するCVEが「ゼロ件」という事実である。従来の脆弱性スキャナーはCVEデータベースに登録された既知の脆弱性を検出するが、サプライチェーン攻撃のコードは既知の脆弱性を悪用するのではなく、攻撃者自身が書いた悪性コードをパッケージ内に配置する。したがって、従来の脆弱性スキャナーは検出率がゼロであり、AI自律脆弱性ハンティングの産業化が進む中でも、サプライチェーン攻撃は脆弱性管理の「死角」に位置し続けている。

筆者がSOC構築・運用の現場で繰り返し確認してきたのは、SOCの価値はツールではなく、アラートから判断までの人間のプロセスにあるという事実である。TrapDoorのようなAI IDE標的型攻撃は、まさにその人間のプロセスをバイパスする設計であり、従来のSOCモデルでは検知・対応が構造的に困難である。開発環境を監視対象に含めたDevSecOps統合型のSOCモデルが、もはや選択肢ではなく必須要件となっている。

LiteLLM/Shai-Hulud攻撃との構造比較 ── TrapDoorが示す脅威の進化段階

TrapDoorの構造的脅威を正確に把握するには、2026年に相次いで発覚したAI標的型サプライチェーン攻撃の進化系譜を理解する必要がある。npm/PyPI AI標的型サプライチェーン攻撃として分析されたLiteLLM侵害やShai-Hulud AIエージェント埋込ワーム、Ethereum C2などの先行攻撃と比較すると、TrapDoorは複数の次元で脅威が進化している。

第一の進化は「エコシステム横断性」である。LiteLLM侵害はPyPIのlitellm-proxyパッケージを標的とした単一エコシステム攻撃であり、Shai-Hulud連鎖攻撃もnpmとPyPIの2エコシステムにとどまった。TrapDoorはnpm・PyPI・Crates.ioの3エコシステムを同時に攻撃した初のキャンペーンであり、攻撃者が複数の言語エコシステムに精通したチームを編成していることを示唆する。Rustエコシステム（Crates.io）が大規模サプライチェーン攻撃の標的となったのは初めてであり、Rustの「メモリ安全性」という技術的優位性がサプライチェーン攻撃に対しては無力であることを証明した。

第二の進化は「AI IDE標的型」という新たな攻撃カテゴリの確立である。LiteLLM侵害やTanStack 404悪性版攻撃は、パッケージそのものにバックドアを仕込む従来型の手法だった。TrapDoorは、パッケージの汚染に加えて.cursorrules/CLAUDE.mdのゼロ幅Unicode隠蔽プロンプトという「AIの知覚と人間の知覚のギャップ」を攻撃面として利用した。これは、AI IDEが開発の主流となった2026年の技術環境を正確に反映した攻撃設計であり、攻撃者がDefense-in-Depthの新しい層──AIアシスタント層──を標的に加えたことを意味する。

第三の進化は「認証情報の選別と検証」である。従来の攻撃は窃取したデータを一括送信するのが一般的だったが、TrapDoorのtrap-core.jsは窃取した認証情報をリアルタイムでAWSとGitHubのAPIに問い合わせて有効性を検証し、高価値トークンのみを抽出する。このオペレーショナルな洗練は、攻撃者が大量の低品質データを処理するコストを削減し、侵害後の横展開効率を最大化する意図を示している。

第四の進化は「ペイロードの外部ホスティング」である。PyPIパッケージはGitHub Pagesに実行コードをホストし、パッケージ本体からペイロードを分離した。これにより、レジストリの静的解析を回避しつつ、パッケージの新バージョンを公開することなくペイロードの更新・変更が可能となる。この手法はEchoLeakゼロクリック・プロンプトインジェクションで実証された「外部制御チャネル」の概念をサプライチェーン攻撃に適用したものと位置づけられる。

これらの進化を総合すると、サプライチェーン攻撃は「パッケージの汚染」から「開発ワークフロー全体の汚染」へと攻撃面を拡大している。TrapDoorは、この構造転換を示す最初の完全な実装例であり、今後の攻撃がさらに高度化する方向性を明確に示している。

多層防御の実装標準 ── TrapDoor級攻撃に対抗する5つの防御層

TrapDoorが示した攻撃面の拡大に対応するには、パッケージレジストリの信頼性に依存する単一防御モデルから、開発ワークフロー全体を保護する多層防御アーキテクチャへの転換が必要である。以下に、防御の5つの層を定義する。

第1層: パッケージインストール時の動的解析。npm install、pip install、cargo buildのいずれにおいても、インストール前にパッケージのpostinstallフック、インポート時コード、build.rsスクリプトを動的解析する仕組みを導入する。Socket.devのようなリアルタイム検出サービスの導入が第一歩であり、CI/CDパイプラインでの--ignore-scriptsフラグの適用（npm）や--no-buildオプション（pip）の活用も有効である。ただし、--ignore-scriptsは正規パッケージの機能も無効化するため、ホワイトリスト方式との併用が必須である。

第2層: AI IDE設定ファイルの不可視文字検証。プロジェクトの.cursorrules、CLAUDE.md、.github/copilot-instructions.mdなどのAI IDE設定ファイルに対して、ゼロ幅Unicode文字（U+200B、U+200C、U+200D、U+FEFF）の自動検出を実装する。Gitのpre-commitフックに不可視文字検出スクリプトを組み込むことで、リポジトリに混入する前に阻止できる。また、PRレビュープロセスにおいてAI IDE設定ファイルの変更を自動的にフラグ付けするCI/CDルールの導入が推奨される。

第3層: 開発環境の認証情報隔離。開発マシン上の認証情報を最小権限原則に基づいて隔離する。AWS認証情報はIAM Identity Centerの一時トークン方式に移行し、永続的なアクセスキーをローカルに保存しない。SSHキーはハードウェアセキュリティキー（YubiKey等）に格納する。環境変数は.envファイルではなく、HashiCorp VaultやAWS Secrets Manager等のシークレット管理サービスから実行時に取得する運用に移行する。暗号通貨ウォレットの秘密鍵は、開発マシンとは物理的に分離されたハードウェアウォレットに保管する。

第4層: ネットワーク層でのexfiltration検知。開発環境からのアウトバウンド通信を監視し、未知のドメイン（特にGitHub Pages、Gist、その他のコード共有サービス）への異常なデータ送信を検出する。DNS queryログの分析、TLS SNIベースのフィルタリング、および開発コンテナ内でのネットワーク名前空間の分離が有効である。TrapDoorがGitHub PagesやGitHub Gistsを外部送信先として使用したことは、正規サービスを悪用するliving-off-the-land手法がサプライチェーン攻撃にも浸透していることを示す。

第5層: AIアシスタントの実行権限制限。AI IDEのアシスタントがアクセスできるファイルシステム範囲、ネットワーク通信先、実行可能なコマンドを明示的に制限する。OWASP・NSA・DoD共同ガイダンスが定義するサンドボックス設計の原則を、AI IDEの実行環境にも適用することが求められる。具体的には、.envファイルや~/.sshディレクトリへのAIアシスタントのアクセスを明示的に禁止し、外部ネットワーク通信にはホワイトリスト方式を採用する。

筆者がセキュリティ設計・戦略策定の実務で繰り返し痛感してきたのは、セキュリティ戦略はビジネスの制約を理解した上でないと絵に描いた餅になるという現実である。上記5層のすべてを即座に導入するのは非現実的であり、まずは第2層（不可視文字検証）と第3層（認証情報隔離）から着手し、段階的に防御深度を拡大するアプローチが実務的に有効である。

FAQ

TrapDoor攻撃とは何か？

TrapDoorは2026年5月に発覚したサプライチェーン攻撃キャンペーンである。npm・PyPI・Crates.ioの3つのパッケージレジストリに34パッケージ・384バージョンを同時展開し、SSH鍵・AWS認証情報・暗号通貨ウォレットのキーストアなどを窃取する。加えて、AI IDEの設定ファイルにゼロ幅Unicode文字で隠蔽したプロンプトを注入する手法が初めて実運用レベルで確認された。

.cursorrules のゼロ幅Unicode攻撃はどう検出するか？

Gitのpre-commitフックでU+200B・U+200C・U+200D・U+FEFFの4文字をパターンマッチングで検出するのが最も実用的である。専用のリンターで.cursorrules、CLAUDE.md等のAI IDE設定ファイルを自動スキャンし、不可視文字が含まれるコミットをブロックする運用が推奨される。

なぜ従来の脆弱性スキャナーではTrapDoorを検出できないか？

TrapDoorに関連するCVEはゼロ件である。従来のスキャナーはCVEデータベースの既知脆弱性と照合するが、サプライチェーン攻撃は攻撃者が自ら書いた悪性コードを配置するため、既知の脆弱性パターンに合致しない。動的解析やパッケージ挙動の異常検知など、CVEに依存しないセキュリティ手法が必要である。

Crates.io（Rust）がサプライチェーン攻撃の標的になったのは初めてか？

大規模なキャンペーンとしては初めてである。Rustのメモリ安全性はコード実行時のバグ防止に有効だが、ビルドスクリプト（build.rs）が任意コードを実行できる仕様はnpmのpostinstallフックと同様の攻撃面を持つ。TrapDoorはこの構造的弱点を実証し、Rustエコシステムも例外ではないことを示した。

TrapDoor攻撃から開発環境を守るための最優先対策は？

まず開発マシン上の永続的認証情報を排除する（一時トークン方式への移行）。次にAI IDE設定ファイルのゼロ幅文字検証をpre-commitフックに追加する。この2つの対策で、TrapDoorの主要攻撃ベクトル（認証情報窃取とAIプロンプト操作）の両方に対して基本的な防御を確立できる。

AI IDEを使い続けても安全か？

AI IDEの利用を中止する必要はないが、AI IDEが「信頼された実行環境」ではなく「追加の攻撃面」であるという認識に改める必要がある。ChatGPT Code Interpreterサンドボックス脱出攻撃が示すように、AIコーディング環境の構造的脆弱性は複数存在する。設定ファイルの検証、権限の最小化、ネットワーク監視を組み合わせた運用が前提となる。

参考文献