themalwareguardian/cve-2026-5281CVE-2026-5281 (Chrome Dawn WebGPU UAF): análisis, herramientas de validación de laboratorio y entorno reproducible para builds vulnerables frente a parcheados.
Esta vulnerabilidad afectó a uno de los clientes a los que prestamos servicios. Este repositorio es nuestra contribución a la investigación original: un punto de partida centralizado para el grupo, de modo que si vuelve a aparecer una vulnerabilidad similar que afecte a este componente, ya tengamos el trabajo base hecho. Reúne la teoría detrás del fallo, un resumen documentado de los hallazgos del investigador original y un conjunto de herramientas prácticas para verificar la exposición en un entorno de laboratorio.
Nota: Me habría gustado compartir más de esta investigación, pero debido a restricciones de la empresa no puedo divulgarla más. Todo lo incluido aquí ha sido revisado y no viola ningún acuerdo al que esté sujeto. Por lo tanto, el repositorio queda archivado en su estado actual.
El 1 de abril de 2026, Google publicó una actualización de seguridad de Chrome que abordaba 21 vulnerabilidades, una de las cuales, CVE-2026-5281, ya estaba siendo explotada activamente en el mundo real en el momento de la divulgación. Tres días después, CISA la añadió al catálogo de Vulnerabilidades Explotadas Conocidas y emitió una directiva operativa vinculante que exigía a las agencias federales aplicar el parche. Para entonces, ya nos había afectado.
Este repositorio existe por una única razón: para que la próxima vez que ocurra algo así, tengamos un punto de partida en lugar de empezar de cero. Reúne:
Cuando quieres entender por qué existe una vulnerabilidad, empiezas por aquello para lo que se construyó el sistema y por los supuestos sobre los que se diseñó.
WebGPU expone una API para realizar operaciones, como renderizado y cómputo, en una Unidad de Procesamiento Gráfico. WebGPU no es un intento de exponer OpenGL u OpenGL ES (Sistemas Embebidos). Es una API nueva construida sobre las ideas de APIs modernas como Direct3D 12, Metal y Vulkan.
WebGPU es el reemplazo moderno de WebGL, la antigua API de GPU que los navegadores han usado durante años. La diferencia clave es que WebGPU fue diseñada desde cero para la seguridad y la gestión explícita de recursos. Tú declaras el ciclo de vida de cada buffer, textura y pipeline. El navegador actúa como una capa de validación entre tu JavaScript y el hardware de la GPU.
Los objetos en el centro de esta vulnerabilidad, en orden de creación:``` 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
La regla que importa aquí es: cada objeto es propiedad del GPUDevice. Destruir un buffer mientras el dispositivo aún tiene comandos en vuelo que lo referencian es explícitamente ilegal según la especificación. Se supone que la implementación de Dawn debe detectar y rechazar eso. CVE-2026-5281 es un caso en el que no lo hizo.
---
---
---
<div id='whatisdawn'/>
## ***⚙️ ¿Qué es Dawn?***
- **[Dawn - Implementación WebGPU de Código Abierto](https://dawn.googlesource.com/dawn)**
> Dawn es una implementación de código abierto y multiplataforma del estándar WebGPU en desarrollo. Expone una API nativa de C++ que refleja el IDL de WebGPU con algunas extensiones.
Dawn es la biblioteca de C++ dentro de Chrome que traduce las llamadas de JavaScript de WebGPU en comandos GPU nativos de la plataforma. En Windows se dirige a D3D12, en macOS a Metal y en Linux a Vulkan. Se sitúa entre el motor de JavaScript de Chrome y el controlador del hardware, y es responsable de cuatro cosas: validar las llamadas a la API, serializar comandos, rastrear los tiempos de vida de los objetos y devolver errores a JavaScript.
CVE-2026-5281 vive en la parte del rastreo de tiempos de vida. Específicamente, en cuánto tiempo Dawn mantiene vivos los objetos de buffer de GPU mientras los comandos que los referencian aún están pendientes de ejecución en la cola del hardware.```
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
Necesitas un modelo mental claro de dónde viven las cosas en la memoria antes de que un Use-After-Free tenga sentido intuitivo.``` 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
Los objetos C++ de Dawn, como el objeto interno que respalda a un GPUBuffer, viven en el montón. Tienen conteo de referencias: un puntero inteligente mantiene un contador de cuántas cosas tienen una referencia al objeto. Cuando ese contador llega a cero, se ejecuta el destructor y la memoria se devuelve al asignador.
Un GPUBuffer tiene dos representaciones al mismo tiempo, una en el lado de la CPU y otra en el de la 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
Cuando JavaScript llama a buffer.destroy(), el comportamiento previsto es: marcar el objeto como destruido, decrementar el contador de referencias, liberar el manejador de hardware y liberar la VRAM. El fallo en CVE-2026-5281 provoca que la VRAM se libere mientras la cola de comandos de la GPU aún mantiene una referencia a ese manejador de hardware, lo que significa que la GPU está leyendo o escribiendo activamente en memoria que ya no le pertenece.
CWE-416: Use After Free (MITRE)
Hacer referencia a memoria que ya ha sido liberada puede provocar que un programa se bloquee, utilice valores inesperados o ejecute código. El uso de memoria previamente liberada puede tener innumerables consecuencias adversas, que van desde la corrupción de datos válidos hasta la ejecución de código arbitrario.
Un Use-After-Free sigue un patrón fijo de tres pasos y es una de las clases de fallos de seguridad de memoria más explotadas de forma constante en la seguridad de los navegadores:```
Después del paso 2, el asignador puede entregar esa misma región de memoria a una asignación completamente diferente. Si un atacante puede controlar lo que se coloca en esa región liberada — una técnica llamada heap grooming —, puede controlar lo que el puntero obsoleto lee. Así es como un fallo de seguridad de memoria se convierte en ejecución de código.
El UAF del lado de la GPU es más difícil de observar que el UAF del lado de la CPU, porque:
- El "asignador" es el asignador de VRAM del controlador de la GPU, no el malloc del sistema.
- El "puntero obsoleto" es un identificador de hardware que todavía está referenciado por la cola de comandos.
- La GPU ejecuta comandos de forma asíncrona; la CPU ya ha seguido adelante mucho antes de que ocurra el fallo.
---
---
---
<div id='thevulnerability'/>
## ***🕳️ La Vulnerabilidad***
---
<div id='thevulnerability-whatweknow'/>
### ***📋 Lo que sabemos de fuentes públicas***
Lo siguiente se basa enteramente en lo que se ha confirmado públicamente.
- **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)**
> Un use-after-free en Dawn de Google Chrome anterior a 146.0.7680.178 permitía a un atacante remoto que hubiera comprometido el proceso de renderizado ejecutar código arbitrario a través de una página HTML manipulada.
- **[The Hacker News: 1 de abril de 2026](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)**
> Google es consciente de que existe un exploit para CVE-2026-5281 en circulación.
- **[Help Net Security: 1 de abril de 2026](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)**
> CVE-2026-5281 fue señalado por un cazador de bugs pseudónimo (86ac1f1587b71893ed2ad792cd7dde32), quien previamente reportó dos vulnerabilidades que se han corregido en la actualización de Chrome lanzada el 23 de marzo de 2026: un desbordamiento de búfer en el heap en WebGL (CVE-2026-4675) y otro bug de use-after-free en Dawn (CVE-2026-4676). El cazador de bugs también reportó un tercer use-after-free en Dawn (CVE-2026-5284) que se ha corregido en esta ocasión.
---
<div id='thevulnerability-executionlayers'/>
### ***🔗 De JavaScript al hardware***
Para entender de dónde puede originarse un UAF en Dawn, conviene ver exactamente cómo viaja una llamada a WebGPU desde una línea de JavaScript hasta el hardware físico:```
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
La tensión fundamental es que queue.submit() y buffer.destroy() son ambas llamadas a la API de JavaScript que devuelven inmediatamente, pero la GPU ejecuta los comandos enviados de forma asíncrona, potencialmente mucho después de que ambas llamadas hayan devuelto. Dawn necesita mantener vivos los objetos buffer durante toda la duración de la ejecución de la GPU, no solo hasta que la llamada de JavaScript devuelve.
Cuando el UAF se dispara, la GPU experimenta lo que D3D12 llama un evento "Device Removed". La secuencia es:```
Esto es también lo que detecta el ejecutor de pruebas automatizado de este repositorio: observa esas señales exactas de consola para determinar si la vulnerabilidad es activable en una versión determinada de Chrome.
---
<div id='thevulnerability-impact'/>
### ***💥 Impacto y requisitos de explotación***
La descripción de NVD es específica sobre una restricción importante: la explotación requiere que el atacante ya haya comprometido el proceso de renderizado. Esto significa que CVE-2026-5281 no es un RCE independiente de un solo clic desde un arranque en frío, sino un escape de sandbox que forma parte de una cadena.
En la práctica, una cadena de ataque completa se vería algo así como:```
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
Este es exactamente el modelo de explotación que hace que los bugs de GPU en el navegador sean de alto valor: una vez que estás dentro del renderizador, Dawn es uno de los siguientes objetivos naturales porque maneja memoria a nivel de hardware con el tipo de complejidad asíncrona que produce estas ventanas de sincronización.
El impacto confirmado en el momento de la divulgación fue la ejecución arbitraria de código, y la base de datos Vulners señala la corrupción de datos y los bloqueos del navegador como efectos adicionales observados.
CVE-2026-5281 no apareció de forma aislada. Fue el cuarto zero-day de Chrome de 2026, un año que ya iba camino de superar el total de ocho zero-days de 2025 antes de que terminara el primer trimestre.
| Fecha | Evento |
|---|---|
| febrero de 2026 | CVE-2026-2441 parcheado, UAF en el componente CSS de Chrome, explotado activamente |
| 10 de marzo de 2026 | CVE-2026-3909 y CVE-2026-3910 parcheados, ambos zero-days explotados activamente |
| 23 de marzo de 2026 | CVE-2026-4675 (desbordamiento de búfer en el heap de WebGL) y CVE-2026-4676 (UAF en Dawn) parcheados, mismo reportador que CVE-2026-5281 |
| 1 de abril de 2026 | Google lanza Chrome 146.0.7680.177/178, 21 vulnerabilidades parcheadas, CVE-2026-5281 confirmado como explotado en la naturaleza |
| 1 de abril de 2026 | CISA añade CVE-2026-5281 al Catálogo de Vulnerabilidades Explotadas Conocidas |
| 3 de abril de 2026 | Google reconoce la explotación activa contra 3500 millones de usuarios de Chrome |
El mismo investigador seudónimo que reportó CVE-2026-5281 también reportó otras tres vulnerabilidades en el mismo período (CVE-2026-4675, CVE-2026-4676, CVE-2026-5284, las dos últimas también UAF en Dawn). Esto sugiere un esfuerzo de investigación centrado y continuo dirigido específicamente a la gestión de memoria de Dawn.
El kit de herramientas de este repositorio se construyó sobre la base de investigación de seguridad original que documenta el comportamiento de la vulnerabilidad en un entorno de laboratorio. A continuación se presenta un resumen de esa investigación, la estrategia utilizada para desencadenar el UAF y los resultados observados.
El enfoque del investigador para desencadenar el UAF fue diseñado para satisfacer simultáneamente las tres condiciones que hacen alcanzable la ventana de carrera: suficiente presión en la cola de la GPU para retrasar la ejecución, un tiempo lo suficientemente ajustado entre destroy y dispatch, y la reasignación de búferes del mismo tamaño para maximizar las posibilidades de corrupción observable.
La estrategia se divide en cinco pasos:
Paso 1 - Volumen y presión: 200 búferes de almacenamiento WebGPU temporales asignados con tamaños aleatorios (todos múltiplos de 4 bytes según lo requiere la especificación de WebGPU). Esto no se trata de llenar la VRAM, sino de crear suficiente trabajo pendiente para que la GPU no pueda ejecutar los comandos de inmediato.
Paso 2 - Saturación de hilos de cómputo: 32 pipelines de cómputo en paralelo encolados con cargas de trabajo pesadas, bucles internos ejecutando 1000 iteraciones y tamaños de dispatch de 4096 grupos de trabajo. El objetivo es mantener la cola de la GPU profundamente atrasada para que la ventana entre el envío y la ejecución permanezca abierta el tiempo suficiente para ejecutar la carrera.
Paso 3 - La trampa: Inmediatamente después de enviar todos los command buffers, se llama a destroy() en los 200 búferes. En este punto, la GPU ha recibido los comandos pero aún no los ha ejecutado. Dawn ya ha superado su validación en el momento del envío. La VRAM se libera.
Paso 4 - El desencadenante: 32 nuevas asignaciones de búferes utilizando exactamente los mismos tamaños que los búferes recién liberados. Si el asignador de VRAM devuelve las mismas direcciones físicas, lo cual suele ocurrir ya que los tamaños coinciden, los comandos pendientes de la GPU ahora tienen un manejador de hardware que apunta a memoria que pertenece a una asignación diferente y activa.
Paso 5 - Reutilizar los comandos enviados: Otra ronda de envíos de command buffers utilizando los búferes recién asignados. En este punto, hay dos conjuntos de comandos en la cola que hacen referencia a lo que antes era la misma memoria, con la GPU todavía procesando el primer conjunto.
El resultado es un UAF clásico en la capa de VRAM: memoria liberada que es leída activamente por la ejecución de shaders en curso.
El investigador ejecutó el PoC tanto en una instalación de Chrome vulnerable como en una parcheada y observó una clara división de comportamiento:
Ejecución vulnerable (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.
El proceso de Chrome objetivo dejó de renderizar por completo. El sistema operativo experimentó una breve congelación visual, consistente con que el controlador de pantalla tuvo que reiniciarse o detener el procesamiento tras el fallo de la GPU. El evento de pérdida del dispositivo se asignó a un error fatal de GPU en lugar de a un error de validación estándar de la API WebGPU, lo que confirma que el diseño de memoria corrupto llegó a la capa de hardware sin ser detectado por el sandboxing del lado de JavaScript de Chrome.
**Ejecución parcheada (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
Sin bloqueos, sin pérdida de dispositivo, sin señales fatales de GPU en todos los intentos. La corrección se mantiene firme.
Las siguientes capturas se tomaron durante las pruebas de laboratorio del kit de herramientas contra una instalación de Chrome for Testing vulnerable y otra parcheada en una máquina Windows con una GPU integrada Intel gen-12lp. Cada herramienta se ejecutó contra ambos objetivos para verificar la división de comportamiento.
01 - Detector de Versión
| Vulnerable (< 146.0.7680.178) | Parcheado (>= 146.0.7680.178) |
|---|
 |  |
02 - Comprobador de Vulnerabilidades
| Vulnerable | Parcheado |
|---|---|
 |  |
03 - Escáner Local
| Vulnerable | Parcheado |
|---|---|
 |  |
04 - Escáner de Flota
| Vulnerable | Parcheado |
|---|---|
 |  |
05 - Desencadenador de UAF
| Chrome | Firefox |
|---|---|
 |  |
Firefox se incluye para comparar. Firefox utiliza su propia implementación de WebGPU y no se ve afectado por esta vulnerabilidad. Completa todos los intentos sin ninguna señal de bloqueo, independientemente de la versión, lo cual es el comportamiento esperado.
06 - Desencadenador de UAF + Ejecutor Automatizado
| Pérdida del Dispositivo GPU |
|---|
 |
Obtener una señal de bloqueo visible no siempre es sencillo. Dependiendo del hardware y del entorno, el desencadenador puede requerir algunos ajustes para producir resultados observables. En nuestro caso, el comportamiento era reproducible, pero no se manifestaba de forma consistente sin ajustar la carga de trabajo.
Reprodujimos con éxito una Denegación de Servicio contra una instalación vulnerable de Chrome en un entorno de laboratorio controlado. El desencadenador de UAF hace que la GPU se sature al 100 % de utilización, ya que la cola de comandos muy acumulada impide que el controlador atienda nuevas solicitudes de gestión de memoria. Durante algunas ejecuciones, el proceso de GPU entró en un estado de fallo irrecuperable, produciendo los siguientes efectos observables:
La saturación de la GPU y la excepción ocasional confirman que la corrupción de memoria está llegando a la capa de hardware: el identificador del búfer liberado es accedido por la ejecución de shaders en vuelo, la GPU falla y el mecanismo TDR de D3D12 lo presenta como un evento de extracción de dispositivo. La versión parcheada completó la misma carga de trabajo sin problemas y sin ninguna señal de bloqueo.
La reproducción del DoS confirma la vulnerabilidad. El trabajo en curso se centra en el análisis a nivel binario del parche, específicamente en comparar la ruta de envío del búfer de comandos de Dawn entre la última compilación vulnerable y la 146.0.7680.178, para entender exactamente dónde y cómo se aplicó la corrección del conteo de referencias.
En cuanto al ejecutor automatizado: el investigador original publicó un script ejecutor junto con su PoC. Nuestra versión requirió modificaciones para funcionar de forma fiable en un contexto de laboratorio local, concretamente el cambio al nuevo modo headless de Chrome y la adición de una opción para permitir que las señales de bloqueo de la GPU se propaguen del proceso de GPU al renderizador. Sin estas dos opciones, Chrome absorbe silenciosamente los bloqueos del proceso de GPU y la división de comportamiento entre las compilaciones vulnerable y parcheada no es observable desde JavaScript.
Dado que el trabajo de ingeniería inversa y de comparación binaria aún está en curso, el ejecutor automatizado no se publica en este repositorio. Se incluirá en una actualización posterior una vez que se complete el análisis del parche.
Úselo únicamente en sistemas que posea o para los que esté explícitamente autorizado a realizar pruebas.