themalwareguardian/cve-2026-5281CVE-2026-5281 (Chrome Dawn WebGPU UAF): анализ, лабораторные инструменты валидации и воспроизводимая среда для уязвимых и пропатченных сборок.
Эта уязвимость затронула одного из клиентов, которым мы оказываем услуги. Этот репозиторий — наш вклад в оригинальное исследование: централизованная отправная точка для группы, чтобы, если подобная уязвимость, затрагивающая этот компонент, появится снова, у нас уже была готовая основа. Он объединяет теорию, стоящую за ошибкой, документированное резюме результатов оригинального исследователя и набор практических инструментов для проверки подверженности в лабораторных условиях.
Примечание: я хотел бы поделиться большей частью этого исследования, но из-за ограничений компании не могу раскрывать его дальше. Всё, что включено сюда, проверено и не нарушает никаких соглашений, которым я подчинён. Поэтому репозиторий заархивирован в текущем состоянии.
1 апреля 2026 года Google выпустила обновление безопасности Chrome, устраняющее 21 уязвимость, одна из которых, CVE-2026-5281, уже активно эксплуатировалась в реальных атаках на момент раскрытия. Три дня спустя CISA добавила её в каталог Known Exploited Vulnerabilities и издала обязательную оперативную директиву, требующую от федеральных агентств установить исправление. К тому моменту она уже затронула нас.
Этот репозиторий существует по одной причине: чтобы в следующий раз, когда случится что-то подобное, у нас была отправная точка, а не необходимость начинать с нуля. Он объединяет:
Когда хочешь понять, почему существует уязвимость, нужно начать с того, для чего была создана система и на каких допущениях она построена.
WebGPU предоставляет API для выполнения операций, таких как рендеринг и вычисления, на графическом процессоре. WebGPU не является попыткой предоставить OpenGL или OpenGL ES (встраиваемые системы). Это новый API, построенный на идеях современных API, таких как Direct3D 12, Metal и Vulkan.
WebGPU — современная замена WebGL, старого GPU API, который браузеры использовали годами. Ключевое отличие в том, что 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. Она предоставляет нативный C++ API, который повторяет WebGPU IDL с некоторыми расширениями.
Dawn — это C++-библиотека внутри Chrome, которая преобразует вызовы WebGPU JavaScript в нативные для платформы команды GPU. В Windows она использует D3D12, в macOS — Metal, а в Linux — Vulkan. Она находится между JavaScript-движком Chrome и драйвером оборудования и отвечает за четыре вещи: проверку вызовов API, сериализацию команд, отслеживание времени жизни объектов и возврат ошибок в JavaScript.
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
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
Объекты C++ в Dawn, такие как внутренний объект, лежащий в основе GPUBuffer, живут в куче. Они используют подсчёт ссылок: умный указатель ведёт счётчик того, сколько сущностей удерживают ссылку на объект. Когда этот счётчик достигает нуля, запускается деструктор, и память возвращается аллокатору.
GPUBuffer имеет два представления одновременно: одно на стороне CPU и одно на стороне GPU:```
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 приводит к тому, что VRAM освобождается, пока очередь команд GPU всё ещё удерживает ссылку на этот аппаратный дескриптор, то есть GPU активно читает или записывает память, которая ему больше не принадлежит.
CWE-416: Использование после освобождения (MITRE)
Обращение к памяти после её освобождения может привести к сбою программы, использованию непредвиденных значений или выполнению кода. Использование ранее освобождённой памяти может иметь любые неблагоприятные последствия — от повреждения корректных данных до выполнения произвольного кода.
Use-After-Free следует фиксированному трёхэтапному шаблону и относится к одному из наиболее стабильно эксплуатируемых классов ошибок безопасности памяти в безопасности браузеров:```
После шага 2 аллокатор может передать ту же область памяти совершенно другому выделению. Если злоумышленник может контролировать, что попадёт в эту освобождённую область, — техника, называемая heap grooming (подготовка кучи), — он может контролировать, что прочитает висячий указатель. Именно так ошибка безопасности памяти превращается в выполнение кода.
UAF на стороне GPU наблюдать сложнее, чем UAF на стороне CPU, потому что:
- «Аллокатор» — это аллокатор видеопамяти драйвера GPU, а не системный malloc.
- «Висячий указатель» — это аппаратный дескриптор, на который всё ещё ссылается очередь команд.
- GPU выполняет команды асинхронно; CPU уже давно ушёл вперёд к моменту краха.
---
---
---
<div id='thevulnerability'/>
## ***🕳️ Уязвимость***
---
<div id='thevulnerability-whatweknow'/>
### ***📋 Что мы знаем из публичных источников***
Ниже изложено исключительно то, что было подтверждено публично.
- **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)**
> Use-after-free в Dawn в Google Chrome до версии 146.0.7680.178 позволял удалённому атакующему, скомпрометировавшему процесс рендерера, выполнить произвольный код через специально созданную HTML-страницу.
- **[The Hacker News: 1 апреля 2026](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)**
> Google известно, что эксплойт для CVE-2026-5281 существует в дикой природе.
- **[Help Net Security: 1 апреля 2026](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)**
> CVE-2026-5281 был отмечен псевдонимным охотником за багами (86ac1f1587b71893ed2ad792cd7dde32), который ранее сообщил о двух уязвимостях, исправленных в обновлении Chrome, выпущенном 23 марта 2026 года: переполнение буфера в куче в WebGL (CVE-2026-4675) и ещё одна ошибка use-after-free в Dawn (CVE-2026-4676). Этот же охотник за багами сообщил и о третьей ошибке use-after-free в Dawn (CVE-2026-5284), которая была исправлена на этот раз.
---
<div id='thevulnerability-executionlayers'/>
### ***🔗 От JavaScript к оборудованию***
Чтобы понять, откуда может возникнуть UAF в Dawn, полезно увидеть, как именно вызов WebGPU проходит путь от строки JavaScript до физического оборудования:```
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
Фундаментальное противоречие заключается в том, что queue.submit() и buffer.destroy() — это вызовы JavaScript API, которые возвращаются немедленно, но GPU выполняет отправленные команды асинхронно, возможно, спустя долгое время после того, как оба вызова уже вернулись. Dawn должен сохранять объекты буферов живыми на протяжении всего времени выполнения GPU, а не только до момента возврата JavaScript-вызова.
Когда срабатывает UAF, GPU сталкивается с событием, которое D3D12 называет "Device Removed". Последовательность такова:```
Именно это также обнаруживает автоматический тестовый раннер в этом репозитории: он отслеживает эти точные консольные сигналы, чтобы определить, воспроизводима ли уязвимость в конкретной версии Chrome.
---
<div id='thevulnerability-impact'/>
### ***💥 Воздействие и требования к эксплуатации***
Описание NVD конкретно указывает на одно важное ограничение: для эксплуатации требуется, чтобы атакующий уже скомпрометировал процесс рендеринга. Это означает, что 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
Это именно та модель эксплуатации, которая делает GPU-ошибки браузера высокоценными: оказавшись в рендерере, Dawn становится одной из естественных следующих целей, поскольку она работает с памятью на уровне оборудования с той асинхронной сложностью, которая и создаёт такие временные окна.
Подтверждённое воздействие на момент раскрытия включало произвольное выполнение кода, а база данных Vulners отмечает повреждение данных и краши браузера как дополнительные наблюдаемые эффекты.
CVE-2026-5281 не появился изолированно. Это был четвёртый нулевой день Chrome в 2026 году, который уже шёл к превышению общего количества восьми нулевых дней за 2025 год ещё до конца первого квартала.
| Дата | Событие |
|---|---|
| Февраль 2026 | CVE-2026-2441 исправлен, UAF в CSS-компоненте Chrome, активно эксплуатировался |
| 10 марта 2026 | CVE-2026-3909 и CVE-2026-3910 исправлены, оба активно эксплуатировавшихся нулевых дня |
| 23 марта 2026 | CVE-2026-4675 (переполнение буфера в куче WebGL) и CVE-2026-4676 (UAF в Dawn) исправлены, тот же исследователь, что сообщил о CVE-2026-5281 |
| 1 апреля 2026 | Google выпускает Chrome 146.0.7680.177/178, исправлена 21 уязвимость, CVE-2026-5281 подтверждён как эксплуатируемый в реальных условиях |
| 1 апреля 2026 | CISA добавляет CVE-2026-5281 в каталог Known Exploited Vulnerabilities |
| 3 апреля 2026 | Google подтверждает активную эксплуатацию против 3,5 млрд пользователей Chrome |
Тот же псевдонимный исследователь, сообщивший о CVE-2026-5281, сообщил также о трёх других уязвимостях в соседнем временном окне (CVE-2026-4675, CVE-2026-4676, CVE-2026-5284, последние две также UAF в Dawn). Это говорит о целенаправленных и продолжающихся исследованиях, нацеленных именно на управление памятью в Dawn.
Инструментарий в этом репозитории построен на основе оригинального исследования безопасности, в котором документируется поведение уязвимости в лабораторных условиях. Ниже приведена сводка этого исследования, стратегия, использованная для срабатывания UAF, и наблюдаемые результаты.
Подход исследователя к срабатыванию UAF был разработан так, чтобы одновременно удовлетворить три условия, делающие гоночное окно достижимым: достаточное давление на очередь GPU, чтобы задержать выполнение, достаточно точное время между destroy и dispatch, и перераспределение буферов того же размера, чтобы максимизировать шанс наблюдаемого повреждения.
Стратегия разбивается на пять шагов:
Шаг 1 — Объём и давление: 200 временных буферов хранения WebGPU выделяются со случайными размерами (все кратны 4 байтам, как требует спецификация WebGPU). Дело не в заполнении видеопамяти, а в создании достаточного объёма отложенной работы, чтобы GPU не мог выполнить команды немедленно.
Шаг 2 — Насыщение вычислительных потоков: 32 параллельных вычислительных конвейера поставлены в очередь с тяжёлой нагрузкой, внутренние циклы выполняют 1000 итераций, а размеры dispatch — 4096 рабочих групп. Цель — держать очередь GPU глубоко перегруженной, чтобы окно между submit и выполнением оставалось открытым достаточно долго для гонки.
Шаг 3 — Ловушка: Сразу после отправки всех буферов команд вызывается destroy() для всех 200 буферов. В этот момент GPU получил команды, но ещё не выполнил их. Dawn уже прошёл свою проверку на этапе submit. Видеопамять освобождена.
Шаг 4 — Триггер: 32 новых выделения буферов с точно такими же размерами, как у только что освобождённых. Если аллокатор видеопамяти вернёт те же физические адреса, что часто происходит, поскольку размеры совпадают, ожидающие команды GPU теперь имеют аппаратный дескриптор, указывающий на память, принадлежащую другому, живому выделению.
Шаг 5 — Повторное использование отправленных команд: Ещё один раунд отправки буферов команд с использованием вновь выделенных буферов. В этот момент в очереди находятся два набора команд, ссылающихся на одну и ту же память, а GPU всё ещё обрабатывает первый набор.
Результат — классический UAF на уровне видеопамяти: освобождённая память активно читается выполняемыми шейдерами.
Исследователь запустил PoC как на уязвимой, так и на исправленной установке 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.
Целевой процесс Chrome полностью прекратил рендеринг. ОС испытала кратковременное визуальное зависание, что согласуется со сбросом или остановкой обработки драйвером дисплея после сбоя GPU. Событие потери устройства было сопоставлено с фатальной ошибкой GPU, а не со стандартной ошибкой валидации WebGPU API, что подтверждает: повреждённая компоновка памяти достигла аппаратного уровня, не будучи перехваченной песочницей 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 за все попытки. Исправление работает.
Следующие снимки были сделаны во время лабораторного тестирования набора инструментов как против уязвимой, так и против пропатченной установки Chrome for Testing на машине с Windows и интегрированным GPU Intel gen-12lp. Каждый инструмент запускался против обеих целей для проверки расхождения в поведении.
01 - Version Detector
| Уязвимая (< 146.0.7680.178) | Пропатченная (>= 146.0.7680.178) |
|---|---|
 |  |
02 - Vulnerability Checker
| Уязвимая | Пропатченная |
|---|
 |  |
03 - Local Scanner
| Уязвимая | Пропатченная |
|---|---|
 |  |
04 - Fleet Scanner
| Уязвимая | Пропатченная |
|---|---|
 |  |
05 - UAF Trigger
| Chrome | Firefox |
|---|---|
 |  |
Firefox включён для сравнения. Firefox использует собственную реализацию WebGPU и не подвержен этой уязвимости. Он выполняет все попытки без каких-либо сигналов о сбое независимо от версии, что является ожидаемым поведением.
06 - UAF Trigger + Automated Runner
| Потеря устройства GPU |
|---|
 |
Получить видимый сигнал о сбое не всегда просто. В зависимости от оборудования и окружения триггеру может потребоваться настройка для получения наблюдаемых результатов. В нашем случае поведение воспроизводилось, но не всегда проявлялось без корректировки рабочей нагрузки.
Мы успешно воспроизвели отказ в обслуживании против уязвимой установки Chrome в контролируемой лабораторной среде. Триггер UAF приводит к насыщению GPU до 100% загрузки, поскольку сильно перегруженная очередь команд не позволяет драйверу обслуживать новые запросы управления памятью. Во время некоторых запусков процесс GPU переходил в невосстановимое состояние сбоя, что приводило к следующим наблюдаемым эффектам:
Насыщение GPU и периодические исключения подтверждают, что повреждение памяти достигает аппаратного уровня: к дескриптору освобождённого буфера обращается выполняющийся в данный момент шейдер, GPU даёт сбой, и механизм TDR в D3D12 выявляет это как событие удаления устройства. Пропатченная версия выполнила ту же рабочую нагрузку чисто, без каких-либо сигналов о сбое.
Воспроизведение DoS подтверждает уязвимость. Текущая работа сосредоточена на анализе патча на бинарном уровне, а именно на сравнении пути отправки командных буферов Dawn между последней уязвимой сборкой и 146.0.7680.178, чтобы понять, где именно и как было применено исправление подсчёта ссылок.
Что касается автоматического раннера: оригинальный исследователь опубликовал скрипт раннера вместе со своим PoC. Наша версия потребовала модификаций для надёжной работы в локальной лабораторной среде, а именно переключения на новый headless-режим Chrome и добавления опции, позволяющей сигналам о сбое GPU распространяться от процесса GPU к рендереру. Без этих двух флагов Chrome молча поглощает сбои процесса GPU, и расхождение в поведении между уязвимой и пропатченной сборками не наблюдается из JavaScript.
Пока работа по реверс-инжинирингу и бинарному сравнению ещё продолжается, автоматический раннер не публикуется в этом репозитории. Он будет включён в последующее обновление после завершения анализа патча.
Используйте только на системах, которыми вы владеете или которые вам явно разрешено тестировать.