DeepSeek Harness CVE-2026-82533：サンドボックス内のエージェントがコマンド1つで自身のサンドボックスを無効化する

VulnCheckは2026年9月8日にCVE-2026-82533を公開した。これは、AIコーディングエージェントが1つのシェルコマンドで自身のサンドボックスを無効化できてしまう重大な認証バイパスである。該当ソフトウェアは、DeepSeekのコーディングエージェント向けオープンソースローカルランタイムであるDeepSeek Harnessで、Cloud Security Allianceによると数週間で約215,000個のGitHubスターを集めた。0.1.2-alpha.1より前のすべてのバージョンが影響を受ける。呼び出し元がローカルかどうかを呼び出し元自身のHostヘッダーで判断していたため、リクエストがループバックであると主張できた。そのサンドボックスはファイル書き込みを制限していたがループバックネットワークは制限していなかったため、制限されたエージェントがポート3080上のハーネスの認証不要の制御APIを呼び出し、承認をオフにしたままセッションをdanger-full-accessに切り替えることができた。VulnCheckはこれを9.4、重大と評価している。実環境での悪用は主張されていない。この記録はAIインシデントの公開データセットの1エントリであり、Orca AI Incident Archiveには、各エントリの日付、重大度評価、情報源を含む完全な記録セットが収められている。

リクエストにそれが何なのかを尋ねたチェック

脆弱なコンポーネントは、ハーネスのローカルエージェント制御APIです。これは、Webインターフェースとコマンドラインが実行中のセッションを操作するために使用する小規模なHTTPサービスです。脆弱性を発見した企業であるOX Securityの記事に基づく、2026年9月10日のCloud Security Allianceの調査ノートによると、そのサービスはデフォルトで127.0.0.1のポート3080で待ち受け、信頼判断を、ノートがisTrustedApiRequestと名付けた関数内で行っていました。この関数はHTTP Hostヘッダーを読み取り、その値がlocalhostや127.0.0.1などのループバック名と一致した場合にアクセスを許可しました。Hostヘッダーはクライアントが書き込むメタデータであり、TCP接続がどこから来たかについては何も示しません。The Hacker Newsは、2026年9月9日に影響を受けたソースを引用し、このチェックが接続元を一切確認しておらず、同じファイル内のコメントにチェックは「認証層ではない」と書かれていると報じています。

それが CWE-807 の全体像であり、セキュリティ上の意思決定において信頼できない入力に依存することであり、VulnCheck の公開記録が説明しているのはまさにそれです。つまり、実際の TCP 接続元を検証する代わりに、クライアントが供給したループバック Host ヘッダーを受け入れてしまうということです。

不十分なチェックを脱出経路に変えたのは、ハーネスがエージェントに自身の鍵を渡していたことだった。Hacker Newsによると、ハーネスは制御インターフェースのアドレスと現在のセッションの識別子をエージェントのシェルに渡すため、コマンドはどちらも自力で見つける必要がない。一方、サンドボックスは一方のチャネルだけを覆い、もう一方は覆っていなかった。影響を受けるリリースのコマンドラインリファレンスには、デフォルト設定では書き込みがワークスペースと一時フォルダー内にとどまる一方、読み取りとネットワークアクセスは制限されないと記されている。

なぜ承認プロンプトはそれを止められなかったのか

そのハーネスには確かに承認プロンプトがあったが、それらは回避されたというより、そもそも適用外だった。Hacker Newsは、影響を受けたリリースでは、コマンドがそのセッションがすでに持っている権限より広いアクセスを求めようとした場合にのみ承認が要求されていたと報じている。エスカレーション呼び出しはそのようなものを何も求めておらず、セッションの設定を変更した。それを実行したエージェントは、OX Securityがdanger-full-accessと呼ぶモードに移行し、承認プロンプトはneverに設定され、ハーネスを起動したユーザーとして、サンドボックスの完全に外側で実行を続けた。

OX Securityによるこの境界の証拠は、対照的なペアを用いたものだった。The Hacker Newsによると、同社は同一のデフォルト設定で2つのセッションを実行し、両方に同じコマンドを与えた。呼び出しを行ったセッションはワークスペース外のフォルダーに書き込み、もう一方はブロックされた。

第二の道、そしてそれが必要とした前提条件

同じく欠落していたチェックにより、ハーネスは、そもそもサンドボックス内に一度も入ったことのない呼び出し元にもさらされたが、それはデフォルト設定が生み出さなかった条件下でのみだった。コマンドラインはAPIをすべてのネットワークインターフェースにバインドすることを拒否したため、ポートが他の場所から到達可能だったのは、ユーザーがすでにそれを転送していた場合に限られた——The Hacker Newsによれば、トンネル、リバースプロキシ、SSHフォワード、またはエディター自身のポート転送機能を通じてであり、Cloud Security Allianceの注記も同じ組み合わせを挙げている。VulnCheckのアドバイザリによれば、その前提条件が満たされる場合、認証情報のない呼び出し元がセッションを作成し、任意のコマンドを実行し、保存された会話のトランスクリプトを外部に持ち出せた。The Hacker Newsはさらに、同じインターフェースが、セッションのログ全体をダウンロードするリクエストを処理していたと付け加えている。

サンドボックス化された経路には別の前提条件が必要だ。それはエージェントが読み取って行動するテキストだ。Cloud Security Allianceの注記は、コードコメント、READMEファイル、またはissueテキストに埋め込まれた攻撃者提供のプロンプトを扱う、閉じ込められたエージェントについて説明している。どちらの経路も盗まれた鍵を必要とせず、この注記は、ポートが公開された後はリモート経路がモデルとのやり取りをまったく必要としないと指摘している。

したがって、影響を受ける可能性のある集団とは、デフォルト設定でハーネスを0.1.1-rc.2以前に実行したすべての人のことであり、スター数はその集合をうかがわせるにすぎない。The Hacker Newsは2026年9月9日に216,000を超えるスターを数え、スターはインストールではなくブックマークであると注意を促した。

何が確立されており、何が確立されていないのか

CVEレコード自体から確認できる点は次のとおりです。VulnCheckが採番機関であり、2026年8月29日に識別子を予約し、9月8日16:59 UTCにレコードを公開しました。脆弱性はCWE-807です。影響範囲は0.1.2-alpha.1より前のすべてのバージョンです。クレジットはNir ZadokとMoshe Siman Tov Bustanに帰属します。このレコードに記載された2つのスコア、CVSS 4.0での9.4とCVSS 3.1での9.6は、第二の独立した採点者によるものではなくVulnCheckによるものです。NVDは両方のメトリクスをVulnCheckを出典として掲載しています。したがって、これらは2つのフレームワークで表現された1つの評価であり、一致した2つの評価ではありません。

リポジトリから確認できたこと：修正コミット 3e24087 は「fix(web): authenticate the browser Host API」というタイトルで、日付は 2026年8月24日であり、GitHub API によれば、ブラウザ認証モジュールを追加するとともに、この新しいフロー向けのエンドツーエンドテストを210行追加している。その後、タグ dsh-v0.1.2-alpha.1 のリリースが 8月27日 17:06 UTC に続いた。

未確認：利用。CVEレコード、VulnCheckのアドバイザリ、DeepSeekのリリースノートのいずれも、現実の悪用を説明しておらず、NVDは悪用成熟度を未定義として記録している。FIRSTのEPSSモデルは、2026年10月27日付のフィードにおいて、この脆弱性に今後30日間で悪用される確率1.24%、68.9パーセンタイルを与えた。アーカイブはこの項目について現実世界での被害を記録しておらず、信頼度A（十分に文書化）と評価しており、一次情報源も一致している。

最初に届いた2件の報告を含む日付

2人の開発者は、指し示すべきCVEが存在する前に同じ結論に達していた。The Hacker Newsは、2026年8月13日にプロジェクト自身のディスカッションボードへ投稿された、サンドボックスに依然として閉じ込められたプロセスがローカルインターフェースに到達し、セッションをdanger-full-accessに切り替えたことをテスト出力とともに示す投稿を報じている。また、8月14日の2件目の投稿では、そのインターフェースが認証情報なしで受け入れたリクエストが列挙されていた。2件目の投稿はさらに、プロジェクトにセキュリティポリシーファイルがなく、脆弱性を報告するための非公開の経路もないことを指摘していた。The Hacker Newsが9月9日に確認したところ、セキュリティポリシーファイルは依然として存在しなかった。

OX Securityのタイムラインでは、VulnCheckへの報告は2026年8月24日とされている — GitHubが修正コミットについて記録しているのと同じ日付だ。コミットメッセージには報告について何も書かれておらず、The Hacker Newsが伝えるところのOX Securityの公開説明にも、それ以前のコミュニティ投稿には言及がない。8月24日の二つの出来事が関連していたかどうかは公開記録が示すことではなく、本記事はそれを前提としない。

修正から公開までの隔たりは珍しいことではない。Cloud Security Allianceの注記には、OX Securityが8月30日に修正を確認したと記録されており、それはVulnCheckがCVEを公開する9日前のことだった。

修正が反映された箇所と、そうでない箇所

GitHub のタグとパッケージレジストリは連動しておらず、ハーネスをその指示に従ってインストールした人なら知っておく価値があるのはまさにこの点だ。コマンドラインパッケージ @deepseek-ai/dsh は2026年8月21日に0.1.1-rc.2を公開し、その後は8月30日の0.1.2-alpha.2まで何もなかった。CVEが修正版として挙げているバージョン0.1.2-alpha.1はレジストリにまったく存在しないため、最初にインストール可能な修正版は修正から3日遅れた。本記事のためにnpmレジストリのメタデータを参照したのは2026年10月28日であり、The Hacker Newsは9月9日に同じ隔たりを報じた。

リリースノートはそれをセキュリティリリースとして位置づけていなかった。定例の変更の中に、Webインターフェースがネットワークアクセスにワンタイムトークン認証を要求するようになったことが挙げられているが、CVEへの言及もセキュリティ通知もなく、The Hacker Newsは9月9日時点でリポジトリのアドバイザリ一覧にセキュリティアドバイザリを確認できなかった。この仕組みは、Cloud Security Allianceが説明するように、ハーネスが起動時にワンタイムトークンを出力し、ブラウザがそのトークンを署名付きCookieと交換し、以降のすべての呼び出しがそのCookieを提示しなければならないというもので、信頼は、主張されたネットワーク上のオリジンではなく、プロセス開始時に発行された秘密に結び付けられる。

サードパーティ製ビルドが未解決の部分だ。デスクトップラッパーはハーネスの独自コピーを同梱しているため、ユーザーがどのバージョンを実行しているかはラッパーのメンテナーの選択になる。The Hacker Newsは、8月下旬に0.1.1-rc.2に固定されていたWindowsビルドの1つが、修正を含む0.1.3-alpha.1へ9月6日に移行したのを確認した。

サンドボックス自体は変わっていない。0.1.2-rc.1 のコマンドラインリファレンスを読むと、The Hacker News は、読み取りとネットワークアクセスが制限されていないという同じ記述を見つけ、エージェントのシェルが依然としてインターフェースアドレスを受け取ることも確認した。その報道の中のどの情報源も、ワークスペース内で作業するエージェントが新しい方式の下で依然として有効なセッションを取得できるかどうかについては述べておらず、これはパッチ自体のドキュメントが未解決のままにしている疑問である。

記録の情報源が推奨する内容

• 0.1.1-rc.2 以前のインストールは、どのようにパッケージ化されていても、デスクトップラッパーに埋め込まれたコピーも含めて、影響を受けるものとして扱ってください。

• npm から 0.1.2-alpha.2 以降をインストールしてください。2026年10月27日時点でレジストリ上の最新バージョンは 0.2.2-alpha.2 でした。

・アップグレードできない場合は、Webインターフェースを使用していないときに停止し、ポート3080に到達するトンネル、プロキシ、ポート転送をすべて削除してください。

• ポート3080がループバック以外の任意の場所から到達可能かどうかを確認してください。コンテナのポート転送、リバースプロキシ、SSHトンネルも含みます。

• 特権昇格と承認モードの変更をハーネスレベルで記録する。なぜなら、その攻撃は、許可されていない昇格を通常の活動に見せかけることで成立したからである。

5件はすべてCloud Security Allianceの注記とThe Hacker Newsの報道に由来しており、CVEレコード自体には修正済みバージョン以外の修復ガイダンスは記載されていません。

クラウドセキュリティアライアンスがなぜそれをパターンとして読み取るのか

Cloud Security Allianceの注記は、このCVEを、同組織が2026年に記録した他の2件のコーディングエージェント封じ込め失敗と並べている。すなわち、7月1日のGuardFall——11の主要なオープンソースコーディングエージェントのうち10が、ガードレールが阻止するよう作られていたシェルコマンドを実行させられ得た——と、7月22日の信頼の引き渡しに関する調査結果——隔離されたエージェントが書き込んだファイルを、後になってサンドボックス外の信頼済みコンポーネントが実行した——である。この注記は、3件すべてが市場の網羅的調査ではなく同組織自身の研究に由来すること、およびそのパターンが調査対象のエージェントを超えて一般化するかどうかは確立されていないことを明言している。同注記が主張するのは、これらの失敗が異なる層——コマンドガードレール、下流の信頼、そして今はコントロールプレーン認証——に位置するということであり、だからこそサンドボックスアーキテクチャを、満たされた要件ではなく調達上の問題として扱うよう勧めている。

DeepSeek自身の安全性ドキュメントは、その解釈と矛盾しない。リポジトリのSAFETY.mdには、このソフトウェアは「セキュリティ監査を受けておらず、安全または本番運用可能なものとして扱ってはならない」とあり、サンドボックス化、承認プロンプト、権限管理は「分離を保証したり、損害を防いだりするものではない」と記載されている。制御API経由でエージェントが抜け出せた認証の穴は、現在のビルドでは塞がれている。その脱出を短時間で済ませた非対称性——書き込みには境界があるが、ネットワークには何もない——は、パッチが修正しようとした欠陥ではなく、サンドボックスの明示された制限として残っている。