この脆弱性は、私たちがサービスを提供しているクライアントの一つに影響を及ぼしました。このリポジトリは、オリジナル研究への私たちの貢献です。グループのための一元化された出発点であり、このコンポーネントに影響する類似の脆弱性が再び出現した場合に備えて、すでに基盤が整っているようにするためのものです。ここには、バグの背後にある理論、元の研究者による発見を文書化した概要、そしてラボ環境で影響の有無を検証するための実用的なツール一式がまとめられています。
注記：この研究についてもっと共有できればよかったのですが、会社の制約により、これ以上開示することはできません。ここに含まれるすべての内容はレビュー済みであり、私が拘束されるいかなる契約にも違反していません。そのため、このリポジトリは現在の状態でアーカイブされています。
2026年4月1日、Googleは21件の脆弱性に対処するChromeのセキュリティアップデートを公開しました。そのうちの1つであるCVE-2026-5281は、開示時点で既に実環境において活発に悪用されていました。3日後、CISAはこの脆弱性を既知の悪用済み脆弱性（KEV）カタログに追加し、連邦政府機関に対してパッチ適用を義務付ける拘束力のある運用指令を発出しました。その時点で、この脆弱性はすでに私たちにも影響を及ぼしていました。
このリポジトリが存在する理由はただ一つ、次に同じようなことが起きたときに、ゼロから始めるのではなく、拠り所となる出発点を確保するためです。ここには次のものがまとめられています：
脆弱性がなぜ存在するのかを理解したいとき、まずそのシステムが何を目的に作られ、どのような前提で設計されたのかに立ち返ります。
WebGPUは、Graphics Processing Unit（GPU）上でレンダリングや計算などの操作を実行するためのAPIを公開します。WebGPUは、OpenGLやOpenGL ES（Embedded Systems）を公開しようとする試みではありません。Direct3D 12、Metal、Vulkanなどの最新APIのアイデアに基づいて構築された新しいAPIです。
WebGPUは、ブラウザが長年にわたって使用してきた従来のGPU APIであるWebGLに代わる、現代的な後継です。重要な違いは、WebGPUが安全性と明示的なリソース管理を前提にゼロから設計されていることです。すべてのバッファ、テクスチャ、パイプラインのライフサイクルを自分で宣言します。ブラウザは、JavaScriptとGPUハードウェアの間の検証レイヤーとして機能します。
この脆弱性の中心となるオブジェクト（生成順）：``` GPUAdapter ← represents a physical GPU or software fallback └─ GPUDevice ← your logical connection to the adapter; owns everything ├─ GPUBuffer ← a chunk of GPU-accessible memory ├─ GPUShaderModule ← a compiled WGSL shader program ├─ GPUComputePipeline ← a shader wired to a pipeline layout ├─ GPUBindGroup ← binds buffers as inputs to a pipeline ├─ GPUCommandEncoder ← records a sequence of GPU commands └─ GPUQueue ← submits recorded commands to hardware
ここで重要となるルールは、すべてのオブジェクトはGPUDeviceによって所有されているという点です。デバイスが、そのバッファを参照するコマンドをまだ実行中に持っている状態でバッファを破棄することは、仕様上、明示的に禁止されています。Dawnの実装はそれを検出して拒否することになっています。CVE-2026-5281は、そうしなかったケースです。
---
---
---
<div id='whatisdawn'/>
## ***⚙️ Dawnとは？***
- **[Dawn - オープンソースWebGPU実装](https://dawn.googlesource.com/dawn)**
> Dawnは、開発中のWebGPU標準のオープンソースかつクロスプラットフォームな実装です。いくつかの拡張を備えた、WebGPU IDLをミラーリングするネイティブC++ APIを提供します。
DawnはChrome内部のC++ライブラリであり、WebGPUのJavaScript呼び出しをプラットフォームネイティブのGPUコマンドに変換します。WindowsではD3D12、macOSではMetal、LinuxではVulkanをターゲットとしています。ChromeのJavaScriptエンジンとハードウェアドライバの間に位置し、API呼び出しの検証、コマンドのシリアライズ、オブジェクトのライフタイム追跡、JavaScriptへのエラー通知という4つの役割を担っています。
CVE-2026-5281はライフタイム追跡部分に存在します。具体的には、それらを参照するコマンドがまだハードウェアキュー上で実行待機中である間、DawnがGPUバッファオブジェクトをどれだけ長く保持するかという点にあります。```
JavaScript (V8)
│ WebGPU API calls
▼
Dawn (C++) - validates, serializes, tracks lifetimes, reports errors
│
▼
D3D12 (Windows) - Metal (macOS) - Vulkan (Linux)
│
▼
GPU hardware driver
│
▼
Physical GPU - shader cores, VRAM
Use-After-Free を直感的に理解するには、メモリ上のどこに何が存在するのか、明確なメンタルモデルが必要です。``` High addresses ┌────────────────────────────────────┐ │ Kernel space │ The OS and drivers live here. │ │ User-mode code cannot touch it. ├────────────────────────────────────┤ │ Stack │ Function call frames. Fast. │ (grows downward) │ Freed automatically when the │ │ function returns. ├────────────────────────────────────┤ │ Heap │ Dynamic allocations - malloc, new, │ (grows upward) │ smart pointers like Ref. │ │ Freed only when you say so. ├────────────────────────────────────┤ │ BSS / Data / Text │ Globals, constants, compiled code. └────────────────────────────────────┘ Low addresses
Dawn の C++ オブジェクト（GPUBuffer を支える内部オブジェクトなど）は、ヒープ上に存在します。これらは参照カウント方式です。スマートポインタが、オブジェクトへの参照を保持している数のカウントを管理します。そのカウントがゼロになると、デストラクタが実行され、メモリはアロケータに返還されます。
GPUBuffer は、CPU 側と GPU 側の両方に、同時に2つの表現を持ちます。```
CPU side (Dawn, system RAM)
└─ C++ object - metadata, state flags, and a hardware handle
│
│ handle: ID3D12Resource* (D3D12) - MTLBuffer (Metal) - VkBuffer (Vulkan)
▼
GPU side (driver, VRAM)
└─ Actual memory allocation on the graphics card
JavaScriptがbuffer.destroy()を呼び出したときの意図された動作は、オブジェクトを破棄済みとしてマークし、参照カウントを減らし、ハードウェアハンドルを解放して、VRAMを解放することです。CVE-2026-5281のバグにより、GPUコマンドキューがそのハードウェアハンドルへの参照を保持している間にVRAMが解放され、GPUがもはや自分に属さないメモリに対してアクティブに読み取りまたは書き込みを行っていることになります。
CWE-416: Use After Free (MITRE)
解放されたメモリを参照すると、プログラムのクラッシュ、予期しない値の使用、またはコードの実行を引き起こす可能性があります。以前に解放されたメモリの使用は、有効なデータの破壊から任意のコードの実行まで、さまざまな悪影響を及ぼす可能性があります。
Use-After-Freeは、固定された3ステップのパターンに従い、ブラウザセキュリティにおいて最も一貫して悪用されるメモリ安全性バグのクラスの1つです：```
ステップ2の後、アロケータはその同じメモリ領域を完全に別の割り当てに渡すことができます。攻撃者が解放された領域に何が配置されるかを制御できる場合（ヒープグルーミングと呼ばれる技術）、失効したポインタが読み戻す内容を制御できます。これが、メモリ安全性のバグがコード実行に変わる仕組みです。
GPU側のUAFはCPU側のUAFよりも観測が困難です。その理由は次のとおりです。
- 「アロケータ」はシステムのmallocではなく、GPUドライバのVRAMアロケータです。
- 「失効したポインタ」は、コマンドキューによってまだ参照されているハードウェアハンドルです。
- GPUはコマンドを非同期に実行するため、クラッシュが発生するずっと前にCPUは次の処理に進んでいます。
---
---
---
<div id='thevulnerability'/>
## ***🕳️ 脆弱性***
---
<div id='thevulnerability-whatweknow'/>
### ***📋 公開情報からわかっていること***
以下は、公に確認された事実のみに基づいています。
- **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)**
> Google Chrome 146.0.7680.178より前のDawnにおけるuse-after-freeにより、レンダラープロセスを侵害したリモートの攻撃者が、細工されたHTMLページを介して任意のコードを実行できる可能性がありました。
- **[The Hacker News: 2026年4月1日](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)**
> Googleは、CVE-2026-5281のエクスプロイトが実環境で存在することを認識しています。
- **[Help Net Security: 2026年4月1日](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)**
> CVE-2026-5281は、仮名のバグハンター（86ac1f1587b71893ed2ad792cd7dde32）によって報告されました。この人物は以前、2026年3月23日にリリースされたChromeアップデートで修正された2つの脆弱性を報告していました：WebGLのヒープバッファオーバーフロー（CVE-2026-4675）と、Dawnのもう1つのuse-after-freeバグ（CVE-2026-4676）です。このバグハンターはまた、今回修正されたDawnの3つ目のuse-after-free（CVE-2026-5284）も報告しました。
---
<div id='thevulnerability-executionlayers'/>
### ***🔗 JavaScriptからハードウェアまで***
DawnにおけるUAFがどこから発生するかを理解するには、WebGPU呼び出しがJavaScriptの1行から物理ハードウェアに到達するまでの正確な流れを確認すると役立ちます。```
JavaScript
↓ navigator.gpu → adapter → device → buffer / pipeline / encoder
↓ queue.submit([commandBuffer]) ← validation happens here
↓ buffer.destroy() ← if this races GPU execution, UAF
Dawn (C++) - validates API calls, serializes commands, tracks lifetimes
↓ translates WebGPU calls to platform-native API calls
D3D12 (Windows)
↓ ID3D12CommandQueue::ExecuteCommandLists()
↓ hardware handle for the buffer passed to the driver
GPU hardware
↓ shader cores execute the queued commands
↓ if the buffer was freed prematurely → they access freed VRAM ← UAF
The fundamental tension is that queue.submit() and buffer.destroy() are both JavaScript API calls that return immediately, but the GPU executes the submitted commands asynchronously, potentially long after both calls have returned. Dawn needs to keep buffer objects alive for the entire duration of GPU execution, not just until the JavaScript call returns.
UAF が発火すると、GPU は D3D12 が「Device Removed」イベントと呼ぶものに遭遇します。そのシーケンスは次のとおりです:```
これは、このリポジトリの自動テストランナーが検出する内容でもあります。特定のChromeバージョンで脆弱性がトリガー可能かどうかを判断するために、テストランナーはそれらの正確なコンソールシグナルを監視します。
---
<div id='thevulnerability-impact'/>
### ***💥 影響と悪用の要件***
NVDの説明は、1つの重要な制約について具体的に述べています。悪用には、攻撃者がすでにレンダラープロセスを侵害している必要があります。つまり、CVE-2026-5281は、コールドスタートから単独で成立するワンクリックRCEではなく、チェーンの一部となるサンドボックスエスケープです。
実際には、完全な攻撃チェーンは次のようになります：```
Initial access ← some other vulnerability gets code running in the renderer
↓
CVE-2026-5281 ← UAF in Dawn used to escape the renderer sandbox
↓
Arbitrary code ← execution in a higher-privilege Chrome process or OS context
This is exactly the exploitation model that makes browser GPU bugs high value: once you are in the renderer, Dawn is one of the natural next targets because it handles hardware-level memory with the kind of asynchronous complexity that produces these timing windows.
The confirmed impact at the time of disclosure was arbitrary code execution and the Vulners database notes data corruption and browser crashes as additional observed effects.
CVE-2026-5281は単独で出現したわけではありません。これは2026年の4件目のChromeゼロデイであり、その年は第1四半期が終わる前に、2025年の合計8件というゼロデイ数を超えるペースにすでになっていました。
CVE-2026-5281を報告した同じ仮名の研究者は、その前後の期間に他の3件の脆弱性（CVE-2026-4675、CVE-2026-4676、CVE-2026-5284。最後の2件もDawnのUAF）も報告しています。これは、Dawnのメモリ管理を特に標的とした、焦点を絞った継続的な研究努力を示唆しています。
このリポジトリのツールキットは、ラボ環境での脆弱性の挙動を記録した独自のセキュリティ研究の上に構築されています。以下は、その研究の要約、つまりUAFをトリガーするために使用された戦略と観察された結果です。
研究者がUAFをトリガーするために取ったアプローチは、レースウィンドウを到達可能にする3つの条件を同時に満たすよう設計されていました。すなわち、実行を遅延させるのに十分なGPUキュー負荷、destroyとdispatchの間の十分にタイトなタイミング、そして観測可能な破損の可能性を最大化するための同サイズのバッファ再割り当てです。
この戦略は5つのステップに分かれます:
ステップ1 - 量と負荷: ランダム化されたサイズ（WebGPU仕様で要求される4バイトの倍数）で200個の一時WebGPUストレージバッファを割り当てます。これはVRAMを埋めることが目的ではなく、GPUがコマンドをすぐに実行できないほどの十分な未処理作業を作り出すことが目的です。
ステップ2 - コンピュートスレッドの飽和: 重いワークロードを持つ32個の並列コンピュートパイプラインをキューに入れ、内側ループは1000反復、ディスパッチサイズは4096ワークグループです。目標はGPUキューを深く滞留させ、送信と実行の間のウィンドウをレースできるだけ長く開いたままにすることです。
ステップ3 - 罠: すべてのコマンドバッファを送信した直後に、200個すべてのバッファでdestroy()を呼び出します。この時点でGPUはコマンドを受け取っているがまだ実行していません。Dawnはすでにサブミット時の検証を通過しています。VRAMは解放されます。
ステップ4 - トリガー: 解放されたばかりのバッファとまったく同じサイズを使用して32個の新しいバッファを割り当てます。サイズが一致するためVRAMアロケータが同じ物理アドレスを返すことがよくあります。その場合、GPUの未処理コマンドは、別の生存している割り当てに属するメモリを指すハードウェアハンドルを持つことになります。
ステップ5 - 送信されたコマンドの再利用: 新しく割り当てられたバッファを使用して、もう一ラウンドのコマンドバッファ送信を行います。この時点で、キューにはかつて同じメモリを参照していた2セットのコマンドがあり、GPUはまだ最初のセットを処理中です。
その結果は、VRAMレイヤーでの古典的なUAFです。実行中のシェーダー実行によって解放されたメモリが積極的に読み取られます。
研究者はPoCを、脆弱なChromeインストールとパッチ適用済みのChromeインストールの両方で実行し、明確な挙動の分離を観察しました:
脆弱な実行環境（Chrome < 146.0.7680.178）:``` [INFO] CVE-2026-5281 AGGRESSIVE PoC Loaded [INFO] Initializing WebGPU context... [INFO] WebGPU device initialized [INFO] Starting aggressive UAF attacks... [ERROR] UNCAUGHT GPU ERROR: device lost due to internal error [CRASH] GPU DEVICE LOST: destroyed [CRASH] [!!!] CRASH DETECTED! Check console for details.
| 日付 | イベント |
|---|
| 2026年2月 | CVE-2026-2441がパッチ適用済み、ChromeのCSSコンポーネントのUAF、実際に悪用された |
| 2026年3月10日 | CVE-2026-3909 と CVE-2026-3910 がパッチ適用済み、いずれも実際に悪用されたゼロデイ |
| 2026年3月23日 | CVE-2026-4675（WebGLヒープバッファオーバーフロー）とCVE-2026-4676（DawnのUAF）がパッチ適用済み、CVE-2026-5281と同じ報告者 |
| 2026年4月1日 | GoogleがChrome 146.0.7680.177/178をリリース、21件の脆弱性がパッチ適用済み、CVE-2026-5281の実環境での悪用が確認された |
| 2026年4月1日 | CISAがCVE-2026-5281を既知の悪用済み脆弱性カタログに追加 |
| 2026年4月3日 | Googleが35億人のChromeユーザーに対する実際の悪用を認めた |
対象のChromeプロセスはレンダリングを完全に停止しました。OSは短い視覚的なフリーズを経験しましたが、これはGPU障害後にディスプレイドライバーがリセットまたは処理を停止しなければならなかったことと一致しています。デバイス喪失イベントは標準のWebGPU API検証エラーではなく致命的なGPUエラーにマッピングされました。これは、破損したメモリレイアウトがChromeのJavaScript側サンドボックスで捕捉されることなくハードウェア層に到達したことを裏付けています。
**パッチ適用後の実行 (Chrome >= 146.0.7680.178):**```
[INFO] CVE-2026-5281 AGGRESSIVE PoC Loaded
[INFO] Initializing WebGPU context...
[INFO] WebGPU device initialized
[INFO] Starting aggressive UAF attacks...
[INFO] Max attempts reached without crash
[INFO] Either browser is patched or target build not affected
すべての試行でクラッシュなし、デバイス損失なし、致命的なGPUシグナルなし。修正は有効です。
以下は、Intel gen-12lp内蔵GPUを搭載したWindowsマシン上で、脆弱なChrome for Testingとパッチ適用済みChrome for Testingの両方を対象にツールキットのラボテストを実施した際のキャプチャです。各ツールは両方のターゲットに対して実行され、動作の差を検証しました。
01 - バージョン検出器
| 脆弱（< 146.0.7680.178） | パッチ適用済み（>= 146.0.7680.178） |
|---|---|
 |  |
02 - 脆弱性チェッカー
| 脆弱 | パッチ適用済み |
|---|---|
 |  |
03 - ローカルスキャナー
| 脆弱 | パッチ適用済み |
|---|---|
 |  |
04 - フリートスキャナー
| 脆弱 | パッチ適用済み |
|---|---|
 |  |
05 - UAFトリガー
| Chrome | Firefox |
|---|---|
 |  |
比較のためにFirefoxも含めています。Firefoxは独自のWebGPU実装を使用しており、この脆弱性の影響を受けません。バージョンに関係なく、クラッシュシグナルなしですべての試行を完了します。これが期待される動作です。
06 - UAFトリガー + 自動ランナー
| GPUデバイス喪失 |
|---|
 |
目に見えるクラッシュシグナルを得るのは、必ずしも簡単ではありません。ハードウェアと環境によっては、観測可能な結果を生み出すためにトリガーの調整が必要な場合があります。私たちのケースでは、動作は再現可能でしたが、ワークロードを調整しないと一貫して顕在化しませんでした。
管理されたラボ環境において、脆弱なChromeインストールに対するサービス拒否（DoS）の再現に成功しました。UAFトリガーにより、コマンドキューが大幅に滞留し、ドライバーが新しいメモリ管理要求を処理できなくなるため、GPUは100%使用率に飽和します。一部の実行では、GPUプロセスが回復不能な障害状態に入り、以下の観測可能な影響が発生しました：
GPUの飽和と断続的な例外は、メモリ破壊がハードウェア層に到達していることを裏付けています。解放されたバッファハンドルが実行中のシェーダーによってアクセスされ、GPUがフォールトし、D3D12のTDRメカニズムがそれをデバイス削除イベントとして表面化させます。パッチ適用済みバージョンは、同じワークロードをいかなるクラッシュシグナルもなく正常に完了しました。
DoSの再現により、この脆弱性が確認されました。現在進行中の作業は、パッチのバイナリレベル分析に焦点を当てています。具体的には、最後の脆弱なビルドと146.0.7680.178の間でDawnのコマンドバッファ送信パスを差分比較し、参照カウントの修正が正確にどこでどのように適用されたかを理解します。
自動ランナーについて：元の研究者はPoCとともにランナースクリプトを公開しました。私たちのバージョンは、ローカルラボ環境で確実に動作するように修正が必要でした。具体的には、Chromeの新しいヘッドレスモードへの切り替えと、GPUプロセスからレンダラーへのGPUクラッシュシグナルの伝播を許可するオプションの追加です。この2つのフラグがないと、ChromeはGPUプロセスのクラッシュを静かに吸収し、脆弱なビルドとパッチ適用済みビルドの動作の差をJavaScriptから観測できません。
リバースエンジニアリングとバイナリ差分の作業はまだ進行中であるため、自動ランナーはこのリポジトリには公開されていません。パッチ分析が完了したら、フォローアップアップデートに含められます。
所有しているシステム、または明示的にテストを許可されたシステムでのみ使用してください。