Seis Días Cero en Ocho Meses, una Recompensa de Mil Dólares
El equipo de Chrome de Google publicó las compilaciones 152.0.7977.82 y .83 para Windows y macOS, y 152.0.7977.82 para Linux, el 3 y 4 de septiembre de 2026, corrigiendo CVE-2026-85046, un fallo de confusión de tipos en el motor V8 de JavaScript y WebAssembly que Google confirmó que ya estaba siendo explotado en la práctica. El fallo permite que una página web manipulada engañe al compilador de V8 para que conceda a un atacante acceso de lectura y escritura arbitrario en el heap del navegador, abriendo una vía hacia la ejecución remota de código dentro del sandbox de Chrome. El investigador Salvatore Gulizia reportó el fallo el 4 de agosto de 2026 y recibió una recompensa de 1.000 dólares; Google retuvo los detalles técnicos hasta que la solución alcanzó a la mayoría de los usuarios, práctica habitual ante un fallo explotado activamente. Este es el sexto día cero de Chrome explotado activamente parcheado en 2026, y los seis obtuvieron una puntuación CVSS de 8,8 y requirieron un parche de emergencia fuera del ciclo normal de publicación de Chrome.
| Mes (2026) | CVE | Componente | CVSS |
|---|---|---|---|
| Febrero | CVE-2026-2441 | CSS (use-after-free) | 8,8 |
| Marzo | CVE-2026-3909 | Skia (escritura fuera de límites) | 8,8 |
| Marzo | CVE-2026-3910 | V8 | 8,8 |
| Abril | CVE-2026-5281 | Dawn / WebGPU (use-after-free) | 8,8 |
| Junio | CVE-2026-11645 | V8 (acceso fuera de límites) | 8,8 |
| Septiembre | CVE-2026-85046 | V8 (confusión de tipos) | 8,8 |
Ocho Días Antes de que Empezara a Correr el Reloj
El propio cronograma de Google muestra la brecha que importa: divulgó y parcheó CVE-2026-85046 el 3 y 4 de septiembre, ocho días antes de la fecha de entrada en vigor del artículo de la Ley de Ciberresiliencia de la UE que habría exigido un informe formal de exactamente este tipo de incidente. A partir del 11 de septiembre de 2026, el artículo 14 trata a programas como Chrome como productos con elementos digitales, y en cuanto un proveedor tiene conocimiento de que una vulnerabilidad está siendo explotada activamente, debe enviar una alerta temprana a un punto de contacto nacional y a ENISA, la agencia de ciberseguridad de la UE, en un plazo de 24 horas, una notificación más completa en 72 horas y un informe final en los 14 días siguientes a la disponibilidad de la solución. Si Google hubiera descubierto y divulgado el mismo fallo el 12 de septiembre en lugar del 3, la misma secuencia -un investigador reportando un fallo de V8, Google confirmando la explotación en la práctica y Google publicando un parche de emergencia- se habría convertido en el primer caso de prueba real de la Ley de Ciberresiliencia en lugar de un aviso rutinario. Seis días cero de Chrome explotados a lo largo de ocho meses en 2026 convierten a un séptimo, que llegue una vez que la ley ya tenga dientes, en una cuestión de cuándo y no de si ocurrirá.
La Regla de Decisión para Quien Gestione la Política de Parches
La lección práctica para cualquier empresa de la UE no es esperar a una notificación regulatoria para enterarse del próximo día cero de Chrome, porque las propias notas de la versión de Google indicaban que las compilaciones corregidas seguirían distribuyéndose durante los días y semanas siguientes incluso después de existir el parche, lo que significa que la velocidad de la actualización automática, y no la velocidad de la divulgación, decide cuánto tiempo permanece expuesta una flota de portátiles. Quien gestione la política de dispositivos debería tratar el sexto día cero de este año como una tasa base, no como una anomalía: con seis incidentes que se produjeron aproximadamente cada seis o siete semanas a lo largo de 2026, la postura correcta es un proceso permanente que compare las versiones de Chrome instaladas con la última versión estable de forma semanal, en lugar de confiar en que cada máquina se actualice sola según lo previsto. Una vez que el reloj de la Ley de Ciberresiliencia esté en marcha, un equipo de TI radicado en la UE también gana una nueva señal que vale la pena vigilar: el historial de notificaciones a ENISA de un proveedor se convierte en un indicador aproximado de la frecuencia con la que sus productos son atacados activamente, algo más concreto que una afirmación de marketing sobre seguridad de nivel empresarial, y que merece revisarse antes de una renovación, no después de un incidente.
Leer a continuación: SonicWall SMA1000: fallos ya explotados activamente | Equipos De Seguridad De La UE Sin Voz Sobre Astra
