DeepSeekの最新AIモデルが、Google Chromeのセキュリティ機構「V8 Sandbox」を突破するエクスプロイト（脆弱性を悪用する攻撃コード）を、わずか12時間で自律生成したという投稿が注目を集めている。対象とされたのは「DeepSeek-V4.1-Flash-1017」で、メモリ破壊を利用してプロセス全体の読み書きを可能にしたと主張されている。一部のテックメディアはこれをChromeのサンドボックス突破として報じたが、現時点で再現可能なコードや対象バージョン、CVE識別番号などは公開されておらず、第三者による検証も確認できない。
一方、AIを利用したサイバー攻撃が現実の脅威になっていることも確かだ。Microsoftは2026年10月21日、中国と関連する脅威アクターがAIエージェントを利用し、大規模な侵入活動を自動化していたと報告した。また、カーネギーメロン大学の研究では、最先端AIモデルが実際のブラウザ脆弱性を悪用する能力について、具体的な検証結果が示されている。重要なのは、未検証の成功報告と、独立した研究や実際の攻撃で確認された能力を区別することだ。DeepSeekの報告について何が分かっており、現実のAI攻撃はどこまで進んでいるのかを整理する。
DeepSeekが12時間でChromeを突破？ 投稿に欠けている技術的証拠
発端となったのは、Xのアカウント「@Exocija」による2026年10月22日の投稿だ。投稿者は、DeepSeek-V4.1-Flash-1017にChromeのV8 Sandboxを脱出するエクスプロイトの構築を指示したところ、約12時間後にプロセス全体のメモリを読み書きできる「多段階のメモリ破壊エクスプロイト」を生成したと主張した。Wccftechが同日公開した記事もこの投稿を引用し、DeepSeekがChromeのサンドボックスを突破したと見出しで伝えている。
ただし、まず区別すべきなのは、今回の投稿が対象とする「V8 Sandbox」と、一般にChromeのサンドボックスと呼ばれる保護機構の違いだ。V8 Sandboxは、JavaScriptエンジン内部で発生するメモリ破壊の影響を限定するための仕組みである。これに対し、ChromeのOSレベルのサンドボックスは、レンダラープロセスを隔離し、システムコールやファイルシステムなどへのアクセスを制限する。両者は保護対象もセキュリティ境界も異なり、V8 Sandboxの突破が、そのままChromeのOSレベルのサンドボックス脱出を意味するわけではない。
さらに重要なのは、今回の主張を裏付ける技術的な証拠が公開されていないことだ。確認できるのは、モデルとの対話を示すとされるスクリーンショットと、投稿者による成功報告に限られる。エクスプロイトのソースコード、対象となったChromeやV8のバージョン、実行環境、再現手順、関連するCVE識別番号などは示されていない。第三者が同じ条件で実行し、結果を検証したという報告も確認できない。
投稿者のアカウントには、DeepSeekやAnthropicのAIモデルに対するジェイルブレイク手法のメモや、SamsungのGPUドライバーにおけるUse-After-Free（解放済みメモリの不正利用）脆弱性の発見を主張する投稿も見られる。しかし、こうした発信は個人による報告であり、メーカーによるセキュリティアドバイザリや、独立した検証結果とは区別する必要がある。今回のDeepSeekによるV8 Sandbox突破についても、現段階では単一の投稿者による未検証の主張という位置づけにとどまる。
V8 Sandboxは何を守るのか――メモリの読み書きだけでは突破にならない
今回の主張を正しく評価するには、V8 Sandboxがどのような攻撃を防ぐために設計されているかを理解する必要がある。V8プロジェクトの公式設計文書によると、V8 Sandboxはプロセス内部に設けられたソフトウェアベースの保護領域であり、JavaScriptエンジンの脆弱性によるメモリ破壊が、プロセス内の重要なデータに波及することを防ぐ。
通常の64ビット環境では、約1TBの仮想アドレス空間を確保し、その領域内に信頼できないV8のヒープオブジェクトを配置する。サンドボックス内のオブジェクトから外部メモリへの生ポインタを直接保持する代わりに、領域内の相対オフセットや、外部のポインタテーブルを参照するインデックスを使用する仕組みだ。これにより、攻撃者がヒープ内のデータを改ざんできても、その影響がサンドボックス外の重要なメモリへ容易に及ばないようにしている。
注目すべきなのは、V8 Sandboxの設計が、攻撃者による領域内のメモリ操作を最初から想定している点だ。V8セキュリティチームの技術解説では、攻撃者がサンドボックス内部の任意のメモリを読み書きできることを前提としている。さらに、サイドチャネルなどを通じてサンドボックス外のメモリを読み取れる可能性も脅威モデルに含まれている。つまり、サンドボックス内部の任意読み書きを達成しただけでは、この保護機構を突破したことにはならない。
V8 Sandboxが防ごうとしているのは、サンドボックス外のメモリに対する不正な書き込みと、それによる重要なデータの破壊だ。公式文書では、保護されていない領域への書き込みによってサンドボックス外のメモリが破壊される状態を、原則として「Sandbox Violation」と位置づけている。したがって、実際の突破を主張するには、単にV8のメモリ破壊バグを利用するだけでなく、ポインタや参照先の検証を回避し、保護領域外への不正な書き込みに成功したことを示す必要がある。
もう一つ確認すべきなのが、エクスプロイトを実行した環境だ。V8には開発・検証用として、v8_enable_memory_corruption_apiというビルドフラグや、--sandbox-testing、--sandbox-fuzzingといった実行時フラグが用意されている。これらを組み合わせて検証機能を有効にすると、JavaScriptからSandboxオブジェクトを通じてサンドボックス内のメモリを直接操作できる。これは実際の脆弱性を利用せずにメモリ破壊の状態を再現し、サンドボックスの保護機能を検証するための仕組みだ。
こうした検証用APIを利用すれば、メモリ破壊の起点となる脆弱性を新たに発見しなくても、サンドボックス回避を狙うコードの動作を試せる。そのため、実験用のV8ビルドで保護機構の一部を回避できたことと、一般ユーザーが利用するChromeの本番環境で攻撃が成立することは同じではない。今回の投稿では使用した環境や有効だった保護機能が明らかにされておらず、主張された成果がどの程度の技術的な突破に当たるのか判断できない。
ExploitBenchの実測結果、公開AIモデルと非公開モデルには大きな能力差
AIモデルが複雑な脆弱性を悪用する能力については、個人の成功報告とは別に、学術研究による定量的な検証が進んでいる。カーネギーメロン大学のSeunghyun Lee氏とDavid Brumley氏が2026年5月に発表した論文「ExploitBench: A Capability Ladder Benchmark for LLM Cybersecurity Agents」（arXiv:2605.14153）は、その代表的な研究の一つだ。
ExploitBenchは、エクスプロイトの成功を単純な二択で評価するのではなく、脆弱性の悪用に必要な能力を16の指標に分けて測定する。脆弱なコードへの到達やクラッシュの発生から始まり、攻撃に利用できるメモリ操作の確立、任意アドレスの読み書き、制御フローの乗っ取り、最終的な任意コード実行（ACE：Arbitrary Code Execution）まで、各段階の到達状況を検証する仕組みだ。評価には、実際に存在した41件のV8脆弱性と、V8のセキュリティサンドボックスを有効にした本番相当の実行環境が使用された。
研究チームが公開している評価基盤では、一般に提供されている最先端モデル8種類に加え、非公開の研究用モデルも検証されている。その結果、脆弱なコードに到達してクラッシュを引き起こすことは多くの公開モデルで達成された一方、サンドボックスの保護を越えた任意コード実行は、はるかに難しいことが明らかになった。クラッシュを再現できる能力と、攻撃に必要なメモリ操作を組み合わせて実際にコードを実行する能力には、大きな隔たりがある。
論文で報告された主要な評価条件では、一般公開モデルのうち、V8 Sandboxの保護境界を越えて制御フローの乗っ取りに到達したのはGPT-5.5のみだった。成功したのも、特定のWebAssembly関連の脆弱性1件に限られる。同じ脆弱性については、モデル提供元のCLI環境を用いた別の評価で任意コード実行まで到達したが、他の公開モデルと脆弱性の組み合わせでは、任意コード実行は確認されなかった。なお、研究チームの公開サイトには追加の実行条件を含む評価結果も掲載されているため、結果を比較する際には、論文の主要評価と追加実験を区別する必要がある。
これに対し、Anthropicの非公開研究プレビューモデル「Mythos Preview」は、41件の脆弱性のうち18件で任意コード実行に成功した。これはモデル提供元独自の補助ツールを使用しない主要評価条件で得られた結果であり、研究チームは公開された実行記録を検証している。複雑な脆弱性を悪用する能力が、一部の先端モデルではすでに高い水準に達していることを示す結果だ。
ただし、ExploitBenchはゼロデイ脆弱性を一から発見する能力を測ったものではない。モデルには既知の脆弱性（N-day）に関する情報と、その修正パッチがあらかじめ与えられている。したがって、未知の脆弱性を発見し、攻撃コードを完成させる作業とは条件が異なる。また、今回話題となったDeepSeek-V4.1-Flash-1017は評価対象に含まれていない。ExploitBenchはAIによる攻撃コード生成能力を評価する重要な基準だが、今回のDeepSeekに関する投稿の真偽を直接証明するものではない。
DeepSeek-V4.1-Flash-1017の実際の仕様と、混同される未検証の数字
今回の話題の中心となったDeepSeek-V4.1-Flash-1017は、2026年10月17日に公開されたモデルだ。その基盤となる「DeepSeek-V4.1-Flash」は同年9月10日に発表されており、DeepSeekが公開した技術報告書（arXiv:2609.19969）では、推論時のメモリ使用量と処理負荷を抑えるための設計が詳しく説明されている。
DeepSeek-V4.1-Flashは、総パラメータ数5520億（552B）のバックボーンを持つMixture-of-Experts（MoE）モデルで、Causal Encoder-Decoder（CED）アーキテクチャを採用している。入力処理時には80億（8B）、出力生成時には160億（16B）のパラメータをアクティブにする設計で、最大100万トークンのコンテキストに対応する。画像などの視覚情報も扱えるマルチモーダルモデルだ。
技術報告書で特に強調されているのは、Key-Value（KV）キャッシュに必要なメモリの削減である。DeepSeekによると、高帯域メモリ（HBM）上に常駐するKVキャッシュの容量を、1トークン当たり890バイトまで抑えている。さらに、Sliding Window Attention（SWA）Bounded Replayと呼ばれる技術により、SSDやホストメモリに保持するKVキャッシュの容量も削減したという。これらは長い入力を扱うAIエージェントの推論費用を抑えるための技術であり、それ自体が新しい脆弱性を発見する能力を裏付けるものではない。
10月17日に公開されたDeepSeek-V4.1-Flash-1017のモデルカードでは、今回の更新を従来モデルのマイナーアップデートと位置づけている。推論、コーディング、エージェント処理、視覚情報を扱うベンチマークでの性能向上に加え、タスク実行時間と出力トークン数の削減を改善点として挙げている。モデルの重みはMITライセンスで公開されており、公式APIのdeepseek-flashもV4.1-Flash-1017を利用する構成になっている。エージェント処理に適したモデルであることは確かだが、V8 Sandboxを自律的に突破できるとする公式の実証結果は示されていない。
一方、今回の報道では、DeepSeekの財務や推論基盤に関する数字も取り上げられている。Wccftechは、同社が過去4か月間に220億ドル以上の新規資金を調達したと記述しているが、この数字を裏付ける公式の財務資料は確認できない。また、GPU時間当たり38ドルの売上から、約82%の粗利益率を見込めるという説明もあるが、これはGPUの利用費用を1時間当たり約7ドルと仮定した試算であり、同社が公表した利益率ではない。
ただし、推論エンジン「DeepInfer」に関する数字は、こうした外部の推測と区別する必要がある。DeepSeekがGitHubで公開している公式の運用Q&Aには、単一クラスタで1日当たり155兆トークンを処理し、オフピーク料金ベースでGPU時間当たり38ドルの売上を得ていると明記されている。これはDeepSeek自身が公表した運用実績の主張であり、個人アカウントの推測に由来する数字ではない。ただし、クラスタのGPU構成や測定期間などは十分に開示されておらず、第三者による独立した検証結果でもない。売上と利益を混同せず、企業が公表した数値と外部の推計を分けて評価する必要がある。
Microsoftが確認した実際の攻撃、Storm-0940によるARTEXの悪用
DeepSeekによるV8 Sandbox突破の報告が未検証である一方、AIエージェントを利用した実際のサイバー攻撃については、具体的な調査結果が公表されている。Microsoft Threat Intelligenceが2026年10月21日に公開した報告書は、中国と関連する脅威アクター「Storm-0940」が、AIを利用した侵入テストフレームワーク「ARTEX」を攻撃に悪用していた実態を明らかにした。
Storm-0940は少なくとも2021年から活動が確認されている脅威アクターで、Microsoftによると、2026年9月にはARTEXを利用した攻撃の自動化を始めていた。標的となったのは、航空宇宙、防衛、自動車、化学、エネルギー、金融、政府、半導体、ソフトウェアなど、幅広い業種の組織だ。Microsoftは、IT管理ソフトウェアを手がけるConnectWiseのマルチテナント型クラウドバックアップ環境で発生したサプライチェーン侵害にも、Storm-0940が関与していたと分析している。
この攻撃では、侵害されたクラウドアプリケーションの認証情報が悪用された。攻撃者はARTEXを使い、2250以上の顧客テナントに対して不正なアクセスを試みたという。特に問題となったのは、すでに顧客環境へのアクセス権を持っていたアプリケーションの認証情報を利用することで、通常のユーザーによる対話的なサインインを経ずにクラウド環境へ接続できた点だ。Microsoftは、複数の被害環境でMicrosoft Graphを通じた情報収集やアプリケーション認証情報の変更、権限操作などの活動を確認している。
攻撃の規模と速度は、Microsoftが収集したテレメトリにも表れている。2026年10月10日から14日にかけて、攻撃者のインフラであるIPアドレス144.172.64[.]99から、8組織に属する327アカウントに対して自動化されたパスワードスプレー攻撃が実行された。この期間に記録された認証失敗は15万1000件以上に上り、10月11日のピーク時には毎分2900件に達した。ただし、この特定のパスワードスプレー攻撃について、Microsoftは認証成功やトークン発行、Microsoft Graphの呼び出し、ディレクトリ変更を確認していない。
一方、Storm-0940による別のARTEXを利用した攻撃では、標的の選定からクラウド基盤の特権アクセス取得までが3時間未満で完了した事例も確認されている。AIエージェントが攻撃手順を自動化することで、従来は人間が段階的に進めていた情報収集や認証情報の悪用、権限操作を短時間で実行できるようになっている。ただし、Microsoftは、影響を受けたアプリケーションが存在することや、認証に一時的に成功したことだけでは、顧客データの窃取や外部流出が起きたとは判断できないとも説明している。
ConnectWiseは10月16日に最初のセキュリティアドバイザリを公開し、その後、影響を受けたクラウドバックアップアプリケーションへのアクセスを遮断した。公表された侵害指標（IoC）には、攻撃元IPアドレス144.172.64.128や、攻撃ツールで使用されたユーザーエージェント文字列Python-urllib/3.12、python-requests/2.31などが含まれている。こうした具体的な通信情報や認証ログが存在する点で、今回の攻撃活動は、スクリーンショットだけを根拠とするDeepSeekの成功報告とは証拠の性質が大きく異なる。
ARTEXはDeepSeek専用ツールではなく、複数のAIモデルを利用できる攻撃基盤
今回の攻撃で使われたARTEXは、特定のAIモデルそのものではなく、複数のモデルやセキュリティツールを組み合わせて作業を自動化するエージェントフレームワークだ。Go言語によるバックエンドとNext.jsによるフロントエンドで構成され、2026年7月26日にGitHub上で公開されたオープンソースプロジェクトである。公開版にはAGPL-3.0ライセンスが適用されており、外部の大規模言語モデルをAPI経由で呼び出しながら、情報収集から脆弱性の検証までを自律的に進める設計となっている。
ARTEXはAnthropic、OpenAI、DeepSeekなど、複数のAIモデルを切り替えて利用できる。そのため、Storm-0940がARTEXを使用したという事実だけでは、個々の攻撃でどのモデルが使われたのかは特定できない。また、ARTEXを利用した攻撃が確認されたことと、DeepSeek-V4.1-Flash-1017がChromeのV8 Sandboxを突破したという投稿にも、直接的な関連性はない。
なお、ARTEXの開発者は2026年10月8日、オープンソース版の更新を停止し、クローズドソースへ移行する方針を表明している。公開されていたコードは現在も一部のリポジトリに保存されているが、開発方針は変更された。ARTEXはDeepSeekが開発した製品ではなく、今回の調査でも、特定の国家プロジェクトとして開発されたツールであるとは示されていない。
Microsoftの報告から読み取れるのは、汎用的なAIエージェント基盤が、盗み出された認証情報や既存システムの弱点と組み合わされることで、攻撃の速度と規模を大きく引き上げ得るということだ。問題の中心にあるのは、必ずしもAIによる未知の脆弱性の発見ではない。すでに知られている攻撃手法を自動化し、複数の標的に対して短時間で実行できることが、現実の脅威となっている。
未検証のChrome脱出、実際の侵入活動、PHPの重大脆弱性を区別する
AIとサイバーセキュリティを巡る最近の報道では、性質も証拠の確かさも異なる出来事が、一つの大きな脅威としてまとめられる傾向がある。しかし、防御側が適切な対策を選ぶには、確認済みの攻撃、再現可能な脆弱性、未検証の成功報告を区別しなければならない。今回のDeepSeekに関する投稿、Microsoftが報告したStorm-0940の活動、そしてPHPの重大脆弱性を比較すると、その違いが明確になる。
| 対象 | 主な情報源 | 報告・確認された内容 | 証拠の状況 | 防御側に求められる対応 |
|---|---|---|---|---|
| DeepSeekによるChrome脱出 | Xの個人投稿（@Exocija） | V4.1-Flash-1017が12時間でV8 Sandboxを回避するエクスプロイトを生成したとの主張 | 未検証。コード、対象環境、CVE、第三者検証が公開されていない | 公式発表を監視。今回の投稿だけを根拠とする特別な設定変更は不要 |
| Storm-0940による侵入自動化 | Microsoft Threat Intelligence | ARTEXを悪用し、2250以上のテナントへのアクセスを試行 | Microsoftのテレメトリや認証ログ、IoCに基づく調査結果 | サービスプリンシパルの監査、認証情報の確認、ConnectWiseの対応指針の適用 |
| PHPコアの重大脆弱性 | PHP開発チーム、CERT-EU | メモリ不足時の破損と古いグローバル状態に起因する遠隔コード実行の脆弱性 | 公式アドバイザリ、CVE識別番号、修正版、PoCが存在 | PHP 8.5.12、8.4.27、8.3.36、8.2.35以降の修正版へ速やかに更新 |
このうち、PHPの問題はAIによる攻撃コード生成の報告とは独立した、実際に修正が必要なセキュリティ上の欠陥だ。PHP開発チームが2026年10月21日に公開したセキュリティアドバイザリでは、CVE-2026-109618とCVE-2026-109619という2件の重大な脆弱性が修正された。前者はメモリ不足（OOM）の処理中に内部データが不完全な状態となり、メモリ破壊につながる問題である。後者は、すでに解放されたメモリに関連する古いグローバル状態が残り、後続のリクエストで不正に利用される問題だ。どちらも認証を必要としない遠隔コード実行につながる可能性がある。
両脆弱性のCVSS v4.0スコアは9.2で、PHP 8.2から8.5系列の修正前バージョンが影響を受ける。すでにサポートが終了しているPHP 8.1以前の系列も影響を受ける可能性があり、PHPプロジェクトから修正版は提供されない。CERT-EUのセキュリティアドバイザリ2026-018によると、技術的な詳細の公開に加えて概念実証（PoC）コードも流通し始めており、悪用される危険性が高まっている。PHP開発チームは完全な緩和策は存在せず、安全を確保するには更新が必要だと説明している。
修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35として公開されている。対象となるのはPHP-FPMやApacheのmod_php、php-cgiなどを使うWebサーバーであり、開発チームは特にmod_phpのリスクが高いとしている。また、PHP 8.2は2026年12月31日に公式サポートが終了するため、今回の修正を適用するだけでなく、継続してサポートされる系列への移行も検討する必要がある。古いPHPを使用する組織は、ディストリビューションや長期サポート提供元による修正の有無も確認しなければならない。
防御担当者が優先すべきなのは、こうした再現可能な脆弱性への対応と、実際に観測された不正アクセスの調査だ。Microsoftは、クラウド環境におけるサービスプリンシパルのサインイン履歴を調べ、不審なアプリケーション認証情報の追加や権限変更がないか確認するよう推奨している。ConnectWiseの対象サービスを利用している組織では、公開された侵害指標と対応指針に基づき、関連ログの調査、証拠保全、アクセス権限の見直しを進める必要がある。PHPを運用する組織については、稼働バージョンを確認し、修正版を速やかに適用することが最優先となる。
一方、DeepSeekによるV8 Sandbox突破の投稿については、現時点で特別な防御措置を求めるだけの技術的根拠は示されていない。ChromeやV8の通常のセキュリティ更新を継続しつつ、ChromiumやV8の開発チームによる公式発表、関連するCVEの公開、再現可能なエクスプロイトや独立した検証結果が出るかを注視するのが妥当だ。
AIによる攻撃の自動化は現実、だが未検証の成功報告とは分けて考える必要がある
ExploitBenchの研究は、AIモデルが脆弱性の再現だけでなく、保護機構の回避や任意コード実行に必要な複雑な処理まで進める可能性を示している。一方、Microsoftが確認したStorm-0940の活動は、既存の攻撃手法と認証情報の悪用をAIエージェントで自動化するだけでも、攻撃の速度と規模が大きく変わることを明らかにした。どちらも、AIがサイバーセキュリティの脅威環境を変えつつあることを示す重要な事例だ。
ただし、それらの成果を根拠に、DeepSeek-V4.1-Flash-1017がChromeの保護機構を突破したと結論づけることはできない。今回の投稿で欠けているのは、モデルの性能を評価する以前に必要となる、実行環境と再現可能な技術的証拠である。また、確認済みのAI悪用事例から、オープンウェイトモデル全体の禁止が必要だという結論が直接導かれるわけでもない。
今後の焦点は、V8チームによる公式の脆弱性報告が出るか、そして独立した研究によってDeepSeek-V4.1-Flash-1017のエクスプロイト生成能力が再現性のある条件で測定されるかにある。AIの攻撃能力が高まりつつあることを警戒する必要はあるが、実証された能力と未検証の主張を混同すれば、防御側が本当に対応すべき脅威を見誤ることになる。
