Exploits zero-day: por qué tu navegador es vulnerable

Qué es una vulnerabilidad zero-day

Imagina una puerta con un pestillo defectuoso. Alguien descubre el fallo antes de que su dueño pueda sustituirlo. En seguridad, zero-day designa una vulnerabilidad que los atacantes aprovechan antes de que exista un parche público. El fabricante puede conocerla ya o no. Si se explota después de publicarse un parche, suele hablarse de una vulnerabilidad «n-day».

Los navegadores procesan contenido web complejo y no fiable. Cuentan con varias capas para limitar las consecuencias de un fallo. Una vulnerabilidad en el proceso de renderizado es grave, pero no da por sí sola el control del sistema operativo. Según el navegador, la plataforma y el objetivo, el atacante puede necesitar además salir del entorno aislado o elevar privilegios. El diseño de aislamiento de sitios de Chromium describe una capa que restringe un proceso de renderizado comprometido.

La ventaja para el atacante es que aún no hay un parche para ese fallo concreto. Eso no lo vuelve invisible: el análisis del comportamiento, el aislamiento de sitios, el entorno aislado del navegador y una investigación pueden detectar o limitar el ataque. Además, hace falta una vía para llegar a un sistema afectado, como una página maliciosa o contenido manipulado.

El ciclo de vida de un zero-day

Esta secuencia simplificada distingue un fallo aún sin parche de otro que sigue siendo peligroso después de publicarse una solución.

1. 1

   Descubrimiento

   Un investigador, el fabricante o un atacante descubre la vulnerabilidad. Puede comunicarla de forma privada, hallarla durante una investigación o mantenerla en secreto. No hay un calendario único para estos casos.
2. 2

   Desarrollo del exploit

   El atacante averigua cómo activar el fallo en el entorno objetivo. A veces basta con un error; otras veces hay que combinar un fallo del proceso de renderizado con una salida del entorno aislado u otra debilidad. No se consigue automáticamente el control completo del equipo.
3. 3

   Explotación en entornos reales

   Puede llegar mediante una página maliciosa, un sitio comprometido o un enlace dirigido a una víctima. Aunque quizá no exista una firma para ese exploit concreto, las defensas del navegador y las herramientas que analizan el comportamiento pueden bloquear o revelar partes del ataque.
4. 4

   Parche y divulgación

   El fabricante investiga, prepara una corrección y publica un aviso cuando está listo. Los plazos de divulgación e instalación varían. Una vez disponible, instalar pronto el parche cierra ese fallo conocido en los sistemas afectados.
5. 5

   Explotación como n-day

   Los sistemas que aún no han instalado el parche pueden seguir expuestos. A veces los atacantes adaptan los detalles públicos o código existente para atacarlos. La reutilización es posible, pero no implica que siempre aparezca un kit de exploits ni que esta fase tenga una duración fija. El análisis de Google sobre exploits reutilizados muestra por qué es importante instalar una corrección publicada.

Un exploit solo es zero-day mientras no hay un parche público. Después, el riesgo se desplaza hacia los equipos que aún no se han actualizado. Identifica las versiones afectadas, aplica las correcciones pronto y mantén activas las defensas del navegador y del equipo durante todo el proceso.

Dónde aparecen las demoras al actualizar

Las pruebas de compatibilidad, las políticas de los equipos gestionados o dejar el navegador abierto pueden retrasar una actualización. Es una fase distinta del periodo anterior a la publicación de un parche. Ambas requieren defensas por capas, pero solo la actualización corrige un fallo conocido en la versión afectada.

Antes del parche. El software afectado aún no tiene una corrección específica. Qué equipos son vulnerables depende de la versión, el sistema operativo, la configuración y las condiciones necesarias para explotar el fallo. El fabricante puede reservarse detalles técnicos mientras prepara el arreglo.

Parche disponible, pero sin instalar. Una flota gestionada puede necesitar pruebas y coordinar el despliegue. Durante ese tiempo, los atacantes pueden dirigirse a las versiones sin actualizar. El parche no protege a un navegador afectado hasta que se reinicia con la versión corregida.

Equipos que se quedan atrás. Los ordenadores compartidos, los sistemas operativos sin soporte y los navegadores no gestionados pueden perderse la actualización. Un inventario y la comprobación de versiones permiten encontrarlos sin dar por hecho que toda la flota está al día.

Demoras excepcionales. Si hay que aplazar una actualización, limita el acceso a contenidos de riesgo, utiliza las defensas del navegador gestionado y documenta cuándo se instalará la versión corregida. Navegar en remoto puede reducir la exposición local al código de una web, pero no justifica retrasar parches ni elimina el riesgo para las cuentas usadas en esa sesión.

Qué muestran los datos

Google Threat Intelligence Group registró 75 vulnerabilidades zero-day explotadas y divulgadas en 2024 en diversas categorías de productos, no 75 fallos de navegador. Su análisis de 2024 cuenta casos detectados y divulgados, no todos los ataques.

En ese conjunto de datos, los zero-days de navegador bajaron de 17 en 2023 a 11 en 2024. Estas cifras no indican cuánto tarda en instalarse un parche en general ni la probabilidad de que ataquen a una persona cualquiera. Sí recuerdan por qué conviene identificar versiones afectadas, instalar las correcciones disponibles y mantener defensas durante el periodo sin parche.

Casos documentados en navegadores

Los avisos de seguridad del fabricante documentan el fallo y su corrección, pero suelen contar poco sobre las víctimas o la cadena completa de ataque. Estos cuatro casos muestran por qué importa ese límite.

Chrome CVE-2023-2033. El aviso de Google de abril de 2023 describe una confusión de tipos en V8 e indica que existía un exploit activo. No identifica cómo se entregó ni confirma que se comprometiera por completo el equipo.

Firefox CVE-2024-9680. El aviso de Mozilla de octubre de 2024 informa de un fallo de uso tras liberación en las líneas de tiempo de animación y de su explotación activa. No describe ninguna campaña, salida del entorno aislado ni instalación de spyware.

Safari 18.1.1. El aviso de seguridad de Apple incluye la CVE-2024-44308 en JavaScriptCore y la CVE-2024-44309 en WebKit. Apple indica que ambas podrían haberse explotado en Macs con procesador Intel. No precisa la vía de ataque ni una campaña posterior.

Chrome CVE-2025-2783. El aviso de Google de marzo de 2025 confirmó que la vulnerabilidad se estaba explotando y anunció una actualización de escritorio. No indica cómo se entregó el ataque ni cuánto tardaron los despliegues.

Explotar un navegador y robar una cuenta con la sesión iniciada son resultados distintos. Un fallo del proceso de renderizado puede quedar contenido en el entorno aislado; para robar una sesión quizá no haga falta ningún fallo del navegador. Consulta nuestra guía sobre el secuestro de sesiones para conocer ese riesgo aparte.

Medidas más allá de las actualizaciones

Actualizar pronto es esencial, pero nadie puede corregir un fallo antes de conocerlo y preparar un parche. Otras medidas cumplen funciones distintas: pueden reducir la posibilidad de llegar al código vulnerable, limitar lo que consigue un exploit o ayudar a detectar un abuso.

Extensiones. Según los permisos concedidos, una extensión puede acceder a muchas páginas o datos de navegación. Revisa las que tienes instaladas y elimina las que ya no necesites. El abuso de una extensión es un riesgo distinto de un zero-day del navegador: actualizar Chrome o Firefox no revisa por ti las extensiones.

Defensas del navegador. El aislamiento de sitios, el entorno aislado y otras protecciones pueden reducir los efectos de ciertos fallos. Su eficacia depende de la vulnerabilidad y de la plataforma. Cualquier cambio en la configuración de seguridad gestionada requiere un motivo documentado y una evaluación del riesgo.

Sistema operativo y protección del equipo. Mantén actualizado también el sistema operativo. Las herramientas de seguridad pueden detectar comportamientos sospechosos aunque no tengan una firma para un zero-day concreto. No son inútiles por definición, pero tampoco garantizan que detengan todos los ataques.

Aislamiento en un navegador remoto. Abrir una web en un navegador remoto puede reducir la exposición directa del navegador y el sistema local a su código. No impide que se comprometan las cuentas usadas en la sesión, que se descarguen archivos peligrosos ni que haya interacción mediante el visor y el portapapeles. Las sesiones de Browser.lol no siempre terminan al cerrar la pestaña y los perfiles guardados pueden conservarse. El aislamiento complementa las actualizaciones; no justifica retrasarlas.

Defensa por capas

Cada medida cubre una parte distinta del ataque. Su utilidad depende del fallo, la configuración y la forma de trabajar.

Ninguna fila promete inmunidad. El aislamiento remoto cambia dónde se ejecuta el código de la web, pero un fallo en ese navegador puede afectar a la sesión o a las cuentas abiertas en ella. El visor de Browser.lol también se ejecuta en un navegador local. Comprueba todo el proceso, incluidas descargas, portapapeles, credenciales y perfiles guardados, antes de dar por contenido el riesgo.

Si tienes que abrir sitios desconocidos, sigue un procedimiento controlado, usa cuentas de prueba y evita datos secretos reales cuando puedas. Comprueba que la sesión remota haya terminado de verdad: cerrar su pestaña no basta para garantizarlo. Sigue actualizando los navegadores locales y remotos y revisa las alertas de las demás defensas.

Limita la exposición y actualiza pronto

Los informes sobre zero-days recuerdan que no puede existir un parche específico antes de descubrir el fallo. No demuestran que todos los navegadores sufran ataques constantes ni que actualizar haya dejado de servir. Los parches del fabricante, el entorno aislado del navegador, la vigilancia del equipo y el aislamiento remoto tienen funciones y límites distintos.

Actualiza los navegadores afectados tan pronto como sea posible, mantén activas sus defensas y utiliza un navegador remoto cuando reduzca de forma útil la exposición local. Incluye las credenciales, los archivos transferidos y la propia sesión remota en tus medidas de seguridad. Combinar varias capas reduce el riesgo sin prometer que siempre detendrá un exploit desconocido.