CVE-2026-5281: use-after-free в Chrome Dawn

Один исследователь (хеш 86ac1f1587b71893ed2ad792cd7dde32) за март зарепортил четыре бага в GPU-подсистеме Chrome, включая потенциальный sandbox escape. Четыре CVE за месяц от одного человека в одном компоненте - это не случайность, это кто-то целенаправленно копал Dawn и нашёл жилу. Ниже - разбор root cause, модели атаки и реалистичных ограничений по открытым данным: описаниям NVD, CVSS-вектору и хронологии патчей.

Dawn и WebGPU - архитектура уязвимой GPU-подсистемы Chrome​

WebGPU - современный API доступа к GPU из браузера, пришедший на замену WebGL. Принципиальное отличие: WebGPU построен вокруг явного управления жизненным циклом ресурсов. Разработчик сам декларирует создание, использование и уничтожение каждого буфера. Браузер тут - валидационный слой между JavaScript-кодом и GPU-железом. Подробнее - в нашем подробном разборе cve эксплойт разработка.

Dawn - open-source C++ библиотека внутри Chromium, собственно реализация WebGPU. Она валидирует API-вызовы, сериализует команды, отслеживает время жизни объектов и возвращает ошибки в JavaScript. На Windows Dawn транслирует вызовы в D3D12, на macOS - в Metal, на Linux - в Vulkan. Между V8 и GPU-драйвером Dawn - единственный валидатор корректности. Пропустила проверку - всё, приехали.

Иерархия объектов Dawn, релевантная для CVE-2026-5281:

• GPUDevice - логическое соединение с GPU, владеет всеми дочерними объектами
• GPUBuffer - блок GPU-доступной памяти (здесь живёт баг)
• GPUCommandEncoder - записывает последовательность GPU-команд
• GPUQueue - отправляет записанные команды на hardware для исполнения

Правило, которое нарушает CVE-2026-5281: каждый объект принадлежит GPUDevice. Уничтожение буфера пока GPU-очередь исполняет команды с его reference - запрещено спецификацией WebGPU. Dawn обязана это детектировать и отклонить. В этом случае - не отклонила.

Root cause CVE-2026-5281: use-after-free буфера VRAM​

Описание из NVD: «Use after free in Dawn in Google Chrome prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to execute arbitrary code via a crafted HTML page.» Классификация: CWE-416 (Use After Free) - обращение к памяти после её освобождения. По MITRE CWE последствия включают модификацию памяти (Integrity), краш (Availability) и чтение чужих данных (Confidentiality). Likelihood of exploit по CWE-416 - High.

Два уровня UAF: CPU-heap и GPU VRAM​

GPUBuffer существует одновременно в двух представлениях:

CPU-сторона (системная RAM): C++ объект в куче renderer process - метаданные, флаги состояния и hardware handle. На Windows это ID3D12Resource*, на Linux - VkBuffer, на macOS - MTLBuffer. Объект управляется подсчётом ссылок через Ref<T>: счётчик дошёл до нуля - деструктор освобождает память.

GPU-сторона (VRAM): реальная аллокация на видеокарте, доступная через hardware handle из CPU-объекта.

Когда JavaScript вызывает buffer.destroy(), Dawn должна: пометить объект как destroyed, декрементировать счётчик ссылок, освободить hardware handle, вернуть VRAM аллокатору драйвера. Баг CVE-2026-5281 (исходя из описания NVD и класса CWE-416): VRAM освобождается когда GPU command queue всё ещё держит reference на hardware handle. GPU асинхронно обращается к памяти, которая ей уже не принадлежит. Классический race condition на стыке CPU и GPU.

Почему GPU-side UAF сложнее обычного​

Классический CPU-side UAF: malloc → free → обращение через stale pointer. AddressSanitizer ловит это надёжно. GPU-side UAF в Dawn - совсем другой зверь:

• Непрозрачный аллокатор: VRAM управляется драйвером GPU - ASAN его не видит, MSAN тоже бесполезен
• Hardware handle вместо указателя: stale reference - не адрес в RAM, а handle в command queue
• Асинхронность: GPU исполняет команды с задержкой, CPU уже ушёл дальше к моменту проявления бага
• Триаж - боль: crash проявляется в GPU process или драйвере, стандартные crash reporters могут не связать его с конкретным WebGPU-вызовом

Концептуальный паттерн API, демонстрирующий root cause:
Между queue.submit() и фактическим завершением GPU-операций проходит неопределённое время. Вызов buf.destroy() в этом окне - root cause CVE-2026-5281.

CVSS-вектор и модель атакующего​

NVD присвоил CVE-2026-5281 оценку CVSS 8.8 (HIGH) с вектором CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.


Тут важный нюанс в описании NVD: "a remote attacker who had compromised the renderer process". CVE-2026-5281 - не standalone RCE с нуля. Атакующему нужен предварительный компромисс renderer process (через отдельный баг в V8 или другом компоненте). Dawn UAF даёт следующий примитив: надёжное произвольное исполнение кода из уже скомпрометированного renderer.

CVSS PR:N оценивает сценарий с позиции жертвы: ей не нужны привилегии, достаточно открыть страницу. Но для атакующего реальная эксплуатация требует цепочки минимум из двух примитивов: initial renderer compromise + Dawn UAF для стабилизации code execution.

EPSS (вероятность эксплуатации за 30 дней): 0.0494, percentile 0.9165 - Top 10% среди всех CVE. CISA SSVC Decision: Act - exploitation: active, automatable: no, technical impact: total. Вердикт: патчить немедленно.

Бизнес-логика атаки: зачем это атакующему​

Атака через CVE-2026-5281 укладывается в модель Drive-by Compromise (T1189, Initial Access): жертва переходит по ссылке, JavaScript триггерит UAF. В связке с отдельным initial renderer compromise и sandbox escape это может дать полный контроль над системой - без аутентификации, без загрузки файлов. Но сама CVE-2026-5281 требует предварительно скомпрометированный renderer и не тянет на standalone RCE. Сценарии: watering hole (компрометация сайта, посещаемого целевой группой), spear-phishing, malvertising. WebGPU включён по умолчанию - каждый пользователь Chrome потенциально в зоне поражения.

Кластер Dawn-уязвимостей: один исследователь и четыре CVE в Chrome​

Исследователь 86ac1f1587b71893ed2ad792cd7dde32 за март 2026 зарепортил четыре уязвимости в GPU-подсистеме Chrome:


Параллельно Google закрыл ещё три активно эксплуатируемых zero-day Chrome за тот же квартал: CVE-2026-2441 (UAF в CSS, EPSS 0.2238 - Top 5%), CVE-2026-3909 (OOB write в Skia), CVE-2026-3910 (inappropriate implementation в V8). По данным The Hacker News - четыре zero-day с подтверждённой эксплуатацией с начала года.

Гипотеза о цепочке эксплуатации​

CVE-2026-4676 потенциально даёт sandbox escape. CVE-2026-5281 даёт произвольный код при наличии renderer compromise. Теоретически возможна атака: initial renderer bug → CVE-2026-5281 (надёжный code execution в renderer) → CVE-2026-4676 (выход за sandbox → доступ к ОС).

Красивая цепочка. Но это авторская гипотеза, не подтверждённая публичными данными. Контраргументы:

1. Хронология патчей: CVE-2026-4676 пропатчена 23 марта - за восемь дней до CVE-2026-5281 (31 марта). Если бы Google рассматривал их как связанную цепочку, логичнее было бы закрыть RCE-звено первым. Патчи выходят по мере готовности фикса, не в порядке kill chain - но несовпадение хронологии стоит учитывать
2. CISA-ADP: только CVE-2026-5281 имеет статус exploitation: active. Для CVE-2026-4676 - exploitation: none
3. Chromium bug tracker: записи по обоим CVE закрыты, деталей о совместной эксплуатации нет

Совпадение четырёх CVE в одном компоненте от одного исследователя за месяц - факт. Наличие цепочки эксплуатации - спекуляция. Но если бы я собирал kill chain для Chrome - начал бы именно с этих двух.

Техники эксплуатации UAF в renderer process Chrome​

GPU VRAM vs CPU heap. VRAM-аллокатор GPU-драйвера непрозрачен из user space. Heap grooming на стороне VRAM требует создания множества GPU-буферов контролируемого размера в надежде попасть в освобождённый слот - процесс куда менее предсказуемый, чем CPU-side heap spray. WGSL compute-шейдеры могут читать и писать в эти буферы, но контроль над содержимым freed VRAM ограничен архитектурой GPU process isolation.

Ограничения: sandbox и browser sandbox escape​

Даже при успешном UAF атакующий остаётся внутри sandbox renderer process:

• GPU process isolation: GPU-операции исполняются в отдельном процессе, renderer обращается к нему через IPC. Memory corruption в renderer не даёт прямого контроля над GPU process
• Site Isolation: каждый origin обслуживается собственным renderer - компрометация одного не даёт доступ к данным других сайтов
• Sandbox restrictions: renderer не имеет прямого доступа к файловой системе, сети (кроме через browser process IPC) и другим процессам ОС

Именно поэтому NVD указывает prerequisite "who had compromised the renderer process". CVE-2026-5281 усиливает уже существующий renderer compromise, а для полноценной атаки на систему нужен дополнительный sandbox escape - например, баг класса CVE-2026-4676 или эксплуатация IPC-интерфейса между renderer и browser process.

Детектирование и митигация zero-day уязвимости Chrome​

MITRE ATT&CK mapping​

Interim mitigation и endpoint detection​

Если немедленный патч невозможен - отключить Dawn/WebGPU через флаг запуска или enterprise policy:
На момент публикации специальной enterprise-политики для отключения WebGPU в Chrome Enterprise policy list не задокументировано - единственный надёжный метод: флаг --disable-features=WebGPU через managed shortcuts или ADMX-шаблон для дополнительных аргументов командной строки. Это снижает attack surface WebGPU API для веб-контента, но не гарантирует полное отключение Dawn как внутреннего компонента Chrome. И да, ломает web-приложения с WebGPU - только как временная мера.

Сигналы для endpoint мониторинга:

• Аномальные crashes renderer process с Dawn/WebGPU в crash dump
• Нетипичные дочерние процессы из browser process после краша renderer
• Сетевая активность browser process к нехарактерным доменам (потенциальный C2 callback)
• Обращения к chrome://gpu - возможный fingerprinting GPU-подсистемы перед атакой

Затронутые версии и патч​

Уязвимые: Chrome до 146.0.7680.178 (все платформы: Windows, macOS, Linux). Потенциально затронуты другие Chromium-based браузеры: Microsoft Edge (advisory от 2 апреля 2026, по данным MSRC, без указания собственной severity-классификации - наследует Chromium security severity: High), а также Vivaldi, Brave и Opera (статус патчей для этих браузеров не подтверждён в NVD/KEV/MSRC).

Патч: Chrome 146.0.7680.178 и выше. Обновление скачивается в фоне, но требует перезапуска. В enterprise-среде стоит принудительно инициировать relaunch через management tooling и проинвентаризировать все Chromium-based браузеры в парке.


Dawn за первый квартал 2026-го стала самой горячей attack surface Chromium по количеству высокоприоритетных багов. Четыре CVE от одного исследователя, из которых минимум один эксплуатировался in the wild - следствие роста сложности GPU-подсистемы, а не аномалия. WebGPU отдаёт JavaScript явный контроль над жизненным циклом GPU-ресурсов, и каждый пропущенный edge case в валидации Dawn - потенциальный UAF.

Формулировка "who had compromised the renderer process" в описании CVE-2026-5281 показывает, куда движется эксплуатация браузеров в 2026-м. Standalone RCE через один баг - редкость. Реальные цепочки собираются из нескольких примитивов: первый баг для initial renderer compromise, второй для стабильного code execution, третий для sandbox escape. Dawn оказалась компонентом, где два звена из трёх нашлись за один месяц одним исследователем. MiraclePtr и PartitionAlloc усложняют эксплуатацию CPU-side UAF, но на стыке CPU-heap и GPU VRAM эти mitigation-ы работают вслепую - ASAN не видит VRAM, MiraclePtr не покрывает hardware handles. Пока WebGPU спецификация растёт, Dawn останется горячей зоной. Если хочется разобрать UAF-цепочку от memory corruption до контроля исполнения на практике - на HackerLab есть pwn-задачи, где из примитива нужно собрать полную эксплуатацию без подсказок.