- Google lanzó una actualización del canal estable de Chrome para escritorio, que incluye una vulnerabilidad zero-day relacionada con CSS identificada como CVE-2026-2441
- Google confirmó que esta vulnerabilidad está siendo explotada en ataques reales (in the wild), y los usuarios deben actualizar de inmediato a la versión más reciente para minimizar el riesgo de seguridad
- La actualización se está desplegando de forma gradual para Chrome en Windows, macOS y Linux
Resumen de la actualización del canal estable de Chrome
- Google anunció una actualización del canal estable (Stable Channel) de Chrome para escritorio
- En Windows/macOS es la 145.0.7632.75/76, y en Linux la 144.0.7559.75
- La actualización se distribuye en las plataformas Windows, macOS y Linux
- Se aplicará gradualmente mediante actualización automática
Vulnerabilidad de seguridad CVE-2026-2441
- Esta versión incluye una vulnerabilidad de seguridad designada como CVE-2026-2441
- Se confirmó que es una vulnerabilidad zero-day que ocurre durante el procesamiento de CSS
- Google indicó explícitamente que esta vulnerabilidad está siendo explotada en ataques reales
Acciones recomendadas para los usuarios
- Google recomienda a todos los usuarios actualizar Chrome de inmediato a la versión más reciente
- Si la actualización automática aún no se ha completado, es posible actualizar manualmente
- Al aplicar la versión más reciente, es posible quedar protegido frente a esta vulnerabilidad
Despliegue y soporte
- La actualización se está desplegando de manera gradual a través del canal estable
- Para algunos usuarios, la actualización puede tardar en llegar
- El equipo de Chrome continúa trabajando en mejoras adicionales de seguridad y estabilidad
2 comentarios
Lo actualicé, pero en Mac la versión ya subió hasta la 145.0.7632.110.
Es una vulnerabilidad en la que ocurre un Use-After-Free al procesar fuentes dentro de CSS y se sigue usando una dirección invalidada, lo que puede llegar incluso a permitir el control total del sistema, así que basta con abrir un sitio web para quedar expuesto. Incluso dicen que ya hubo lugares donde se estaba explotando esta vulnerabilidad.
Opiniones de Hacker News
Se descubrió una vulnerabilidad use-after-free en CSS de Google Chromium
Es un problema por el cual un atacante remoto puede provocar corrupción del heap mediante una página HTML maliciosa, y podría afectar no solo a Chrome sino también a navegadores basados en Chromium como Edge y Opera
Parece ser un problema bastante serio, y da curiosidad saber cuánto fue el bug bounty que recibió el investigador
Considerando el esfuerzo que implica encontrar una vulnerabilidad grave y crear un exploit reproducible, da la impresión de que la recompensa es demasiado baja
Porque la mayoría dejan fija una versión de Chrome (version pinning)
Pero que diga “detectado en the wild” también podría significar que ya existe una cadena de ataque que incluye incluso el sandbox escape
Es vergonzoso que en los lenguajes de sistemas del siglo XXI todavía no se puedan eliminar este tipo de bugs
En los rincones oscuros del codebase de Chromium/Blink seguramente todavía hay bugs de este tipo escondidos
En un proyecto tan central como este, debería haber personal dedicado a verificar continuamente todo el código
Me parece una inversión mucho más valiosa reforzar la seguridad que agregar funciones como integración con refrigeradores inteligentes
Si el fuzzer es lo bastante potente, casi no debería haber áreas a las que no llegue
La frase “Use after free in CSS” da un poco de risa
No me queda muy claro cuál es el impacto real de esta vulnerabilidad
Si no hay escape del sandbox o XSS, parece casi inofensiva, pero al ver el código PoC
dicen que permite varios ataques dentro del proceso del renderer, como ejecución arbitraria de código, filtración de información, robo de cookies y sesión, manipulación del DOM, keylogging, etc.
Primero se obtiene ejecución arbitraria de código dentro del sandbox mediante un bug del renderer, y después se consigue control total del sistema con un sandbox escape
Esta vulnerabilidad corresponde a esa primera etapa, y si ya se usó en ataques reales, es muy probable que también exista la segunda etapa
Sigue sorprendiendo que todavía aparezcan este tipo de vulnerabilidades de memoria
Uno pensaría que ya existen herramientas para crear binarios verificados como en los lenguajes memory-safe
CSS también se ha vuelto más complejo, con variables, scopes y funciones de preprocesador, así que quizá hasta haría falta una extensión tipo “no-style”, como “no-script”
Me pregunto si este reporte fue un simple error o parte de una cadena de ataque de múltiples etapas
El problema es la cobertura de pruebas. El codebase es tan grande que es difícil lograr cobertura completa, y en esos huecos es donde aparecen vulnerabilidades como esta
CSS es parte central de la web, y si lo quitas casi todos los sitios se rompen
En cambio, la ejecución aislada (isolation) podría ser una alternativa
Si la sesión del navegador se transmite desde un servidor remoto, incluso si explota un zero-day, solo se ve afectada la instancia remota y no la máquina local
No es perfecto, pero es una estrategia de defensa en profundidad para reducir la superficie de ataque
En la lista de herramientas de seguridad que usa el equipo de Chromium se mencionaron AddressSanitizer, MemorySanitizer, libFuzzer y otras, pero llama la atención que no aparezca OSS-Fuzz
Quiero ver el código PoC después de que se publique el parche
Salió la broma de que habría que reescribir Chromium en Rust
Busqué el CVE y existe una página del issue, pero
aparece como “Access is denied”
Parece estar en estado privado y solo accesible con inicio de sesión