Cuando hablamos de vulnerabilidades, normalmente pensamos en Windows, servidores, aplicaciones críticas o sistemas expuestos a Internet.

Pero hay una aplicación que prácticamente todos nuestros usuarios utilizan todos los días: el navegador.

Chrome, Microsoft Edge, Firefox…

Y aunque muchas veces lo tratamos simplemente como una aplicación más, un navegador desactualizado puede convertirse en una vía de entrada bastante interesante para un atacante.

Por eso, cuando aparece un CVE (Common Vulnerabilities and Exposures) crítico en Chrome, Edge o Firefox, no deberíamos limitarnos a pensar:

«Hay que actualizar el navegador.»

La pregunta debería ser:

¿Cuántos dispositivos de mi organización están afectados y cómo puedo remediarlo de forma centralizada?

Aquí es donde Microsoft Intune puede ayudarnos bastante.

¿Qué es un CVE?

CVE significa Common Vulnerabilities and Exposures.

Es un sistema utilizado para identificar vulnerabilidades de seguridad conocidas de forma estandarizada.

Por ejemplo:

CVE-2026-XXXX

identifica una vulnerabilidad concreta.

Además, podemos encontrarnos con el CVSS (Common Vulnerability Scoring System), que permite valorar la gravedad de una vulnerabilidad.

De forma simplificada:

• 0.0 → Ninguna
• 0.1–3.9 → Baja
• 4.0–6.9 → Media
• 7.0–8.9 → Alta
• 9.0–10.0 → Crítica

Aunque tampoco deberíamos quedarnos únicamente con el número.

Una vulnerabilidad con CVSS 8.5 que afecta a un navegador instalado en 5.000 equipos puede ser mucho más urgente para nuestra organización que otra vulnerabilidad crítica que afecta a una aplicación instalada en tres servidores aislados.

Aqui podemos ver las últimas de Chrome:

https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop.html

¿Por qué son importantes los CVEs de los navegadores?

Porque el navegador está constantemente interactuando con contenido externo.

Nuestros usuarios visitan:

• Internet.
• Aplicaciones SaaS.
• Microsoft 365.
• Portales corporativos.
• Aplicaciones de terceros.
• Documentos.
• Páginas web.
• Servicios que no controlamos.

Y todo esto convierte al navegador en una superficie de ataque muy interesante.

Un atacante no necesita necesariamente comprometer nuestro servidor.

Puede intentar conseguir que un usuario visite una página especialmente diseñada para explotar una vulnerabilidad del navegador.

Por eso una vulnerabilidad que permita, dependiendo del caso:

• Ejecución de código.
• Corrupción de memoria.
• Escalada de privilegios.
• Evasión de mecanismos de seguridad.
• Ejecución de contenido malicioso.

puede tener bastante impacto.

El problema no es solo tener un navegador vulnerable

Imaginemos que aparece una vulnerabilidad crítica en Chrome.

Tenemos: 1.000 dispositivos y 500 tienen Chrome instalado. Después de varios días descubrimos que hay 180 personas que no han actualizado el navegador y sus dispositivos siguen ejecutando una versión vulnerable.

Aquí empieza realmente nuestra propia odisea.

• No basta con saber que existe el CVE.
• Necesitamos saber: ¿Dónde está?
• Que afectación tiene
• Cuantos dispositivos
• Mismo OS o diferentes sistemas
• Y después: ¿Cómo lo solucionamos?

¿Cómo sabemos qué navegadores tenemos?

Aquí Intune empieza a resultar especialmente útil.

Podemos utilizar el inventario de aplicaciones para obtener información sobre el software instalado en nuestros dispositivos.

Además, si utilizamos Microsoft Defender for Endpoint, podemos complementar esta información con sus capacidades de Threat & Vulnerability Management.

Y aquí tenemos una combinación bastante interesante:

Defender → Nos ayuda a identificar vulnerabilidades y dispositivos afectados.

Intune → Nos ayuda a administrar los dispositivos y aplicar configuraciones.

No son exactamente la misma herramienta ni tienen el mismo objetivo.

Vamos a automatizar

Una primera aproximación podría ser: «Si sale una nueva versión de Chrome, creo un Win32 App en Intune y la despliego.»

Puede funcionar, pero cuando hablamos de navegadores que reciben actualizaciones constantemente, mantener manualmente este ciclo puede convertirse en una carga administrativa importante.

Por eso hay otra opción que me parece mucho más interesante, y es utilizar las políticas administrativas del propio navegador. Y aquí entran en juego los ADMX.

¿Qué son los ADMX?

Los ADMX son plantillas administrativas que permiten definir políticas para aplicaciones y componentes de Windows.

Seguramente muchos administradores las conocemos de los clásicos GPO.

La buena noticia es que Intune también puede trabajar con plantillas administrativas y con plantillas ADMX de terceros.

Microsoft permite importar archivos ADMX y ADML de fabricantes externos y posteriormente utilizarlos para crear políticas de configuración en Intune.

Esto es especialmente interesante para navegadores como:

• Google Chrome.
• Mozilla Firefox.

Chrome y sus políticas de actualización

Google proporciona políticas administrativas para gestionar Chrome y su mecanismo de actualización.

La idea es que podamos configurar cómo debe comportarse Chrome en los equipos corporativos.

Por ejemplo: «Quiero que Chrome se mantenga actualizado automáticamente.«

En lugar de tener que crear un nuevo paquete cada vez que aparece una versión nueva, configuramos el comportamiento de actualización del navegador.

Y entonces el flujo cambia completamente.

Tenemos:

Intune ↓ Política administrativa ↓ Chrome ↓ Mecanismo de actualización de Chrome ↓ Nueva versión

Esto tiene mucho más sentido para un navegador que recibe actualizaciones continuamente.

Además, algunas configuraciones de Chrome están disponibles directamente en el Settings Catalog de Intune, por lo que antes de importar ADMX conviene comprobar si la configuración que necesitamos ya está disponible de forma nativa.

¿Y Firefox?

Mozilla también proporciona plantillas de políticas para Firefox.

Y aquí tenemos un ejemplo muy claro:

AppAutoUpdate

Esta política permite controlar las actualizaciones automáticas de Firefox.

Si está habilitada, las actualizaciones de la aplicación pueden instalarse automáticamente sin requerir aprobación del usuario. Mozilla documenta esta política tanto para GPO como para escenarios gestionados mediante Intune.

Esto significa que podemos establecer desde Intune algo parecido a: «Firefox debe actualizarse automáticamente.»

Y dejamos que sea Firefox quien gestione el proceso.

Entonces, ¿qué hace realmente Intune?

Aquí hay un concepto importante.

Intune no está actualizando Chrome o Firefox directamente. Intune está aplicando la configuración que queremos que tenga el navegador. Después es el propio navegador quien utiliza su mecanismo de actualización.

Por tanto:

Intune: Configura y aplica las políticas.

Chrome / Firefox: Ejecutan su mecanismo de actualización.

Defender: Nos ayuda a comprobar si seguimos teniendo dispositivos vulnerables.

Y tenemos un ciclo bastante interesante:

Configurar → Actualizar → Detectar → Verificar

¿Cómo se gestionan los ADMX en Intune?

En términos generales, el proceso sería:

1. Descargar las plantillas ADMX/ADML del fabricante

Por ejemplo, las correspondientes a Chrome o Firefox.

2. Importarlas en Intune

Intune permite importar plantillas ADMX y ADML de terceros.

3. Crear el perfil de configuración

4. Configurar las políticas

Por ejemplo:

Actualizaciones automáticas habilitadas.

5. Asignar la política

A los grupos de dispositivos o usuarios correspondientes.

6. Comprobar el resultado

Y aquí es importante no quedarse simplemente con:

«La política aparece como aplicada.»

Tenemos que comprobar también el estado real del navegador.

¿Cómo comprobamos que la política funciona?

En Firefox podemos comprobar las políticas aplicadas desde el propio navegador.

En Chrome podemos utilizar:

chrome://policy

para comprobar las políticas que el navegador ha recibido.

Esto es especialmente útil durante la implantación.

Porque podemos tener:

Intune → Policy succeeded

pero:

Navegador → política no aplicada como esperábamos.

Y aquí empieza el troubleshooting.

¿Y si aparece un CVE crítico?

Aquí podemos plantear un procedimiento bastante claro.

Imaginemos:

Lunes, 9 de la mañana con el café en la taza: Google publica una actualización de Chrome 9.5 que corrige una vulnerabilidad crítica.

Defender: Identifica dispositivos que todavía tienen una versión vulnerable.

Intune: Comprueba que la política de actualización automática está aplicada.

Chrome: Descarga e instala la versión corregida.

Defender: Vuelve a evaluar los dispositivos.

Resultado: El número de dispositivos vulnerables empieza a disminuir. Este último paso es importantísimo.

No debemos considerar solucionado el problema simplemente porque hemos desplegado una política. Tenemos que comprobar que realmente hemos reducido la exposición.

¿Y si no podemos actualizar inmediatamente?

Aquí entra otra parte importante de la gestión de vulnerabilidades.

No siempre podremos actualizar todo en cinco minutos.

Podemos tener:

• Aplicaciones antiguas.
• Equipos críticos.
• Dependencias.
• Usuarios fuera de la oficina.
• Dispositivos apagados.
• Problemas de conectividad.
• Software incompatible.

Por eso deberíamos poder identificar:

Qué equipos están afectados. Por qué no se han actualizado. Qué riesgo tienen. Qué medida temporal podemos aplicar. Cuándo esperamos solucionarlo.

¿Podemos utilizar Compliance y Conditional Access para protegernos?

Sí. Y aquí podemos empezar a conectar varias piezas de Microsoft. Por ejemplo:

Intune → Gestiona el dispositivo.

Compliance → Evalúa si cumple determinados requisitos.

Conditional Access → Decide si puede acceder a determinados recursos.

Defender → Nos proporciona visibilidad de seguridad y vulnerabilidades.

Esto permite construir estrategias más completas. No se trata simplemente de «Actualizar Chrome.» Sino de Si un dispositivo está en un estado de riesgo determinado, ¿debería seguir teniendo acceso a nuestros recursos corporativos?

Mantener el navegador actualizado debería ser la norma

Personalmente, no me gusta demasiado la estrategia de:

«Cuando aparece un CVE crítico, hacemos una actualización.»

Prefiero:

«El navegador debe actualizarse automáticamente siempre que sea posible.»

Y cuando aparece un CVE crítico, nuestro trabajo debería ser comprobar:

¿Está funcionando nuestra estrategia? en lugar de empezar desde cero.

Porque si tenemos una buena configuración, cuando aparece una vulnerabilidad:

CVE publicado ↓ Fabricante publica versión corregida ↓ Navegador se actualiza ↓ Defender verifica

Ese debería ser el ciclo normal.

Pero ojo con los navegadores instalados manualmente

Aquí tenemos otro problema bastante habitual.

Tenemos:

• Edge.
• Chrome.
• Firefox.
• Algún navegador que nadie sabe quién instaló.

Y posiblemente varias versiones diferentes.

Esto complica:

• Inventario.
• Actualizaciones.
• Políticas.
• Seguridad.
• Soporte.

No significa necesariamente que tengamos que prohibir todos los navegadores excepto uno. Pero sí deberíamos preguntarnos qué navegadores soporta oficialmente nuestra organización. Y después cómo garantizamos que están correctamente gestionados.

Una estrategia que me gusta

Si tuviera que diseñar una estrategia para una organización gestionada con Intune, sería algo así:

1. Definir navegadores corporativos

¿Qué navegadores permitimos y soportamos?

2. Gestionarlos

Desplegarlos y configurarlos mediante Intune.

3. Configurar actualizaciones automáticas

Utilizando las capacidades propias del navegador y sus políticas administrativas.

4. Utilizar ADMX cuando sea necesario

Chrome, Firefox y otros fabricantes proporcionan plantillas administrativas que podemos utilizar para gestionar su configuración.

5. Monitorizar vulnerabilidades

Defender for Endpoint puede ayudarnos a identificar vulnerabilidades y dispositivos afectados.

6. Remediar

Aplicar las políticas necesarias desde Intune.

7. Verificar

Comprobar que las versiones vulnerables realmente desaparecen.

8. Controlar el acceso

Cuando el escenario lo requiera, utilizar Compliance y Conditional Access.

El verdadero objetivo: reducir la ventana de exposición

Hay un concepto que me parece especialmente importante: Time to Remediate

Imaginemos que Microsoft, Google o Mozilla publican una actualización que corrige un CVE crítico.

Si nuestra organización tarda 30 días en actualizar los endpoints afectados, tenemos una ventana de exposición enorme. Si conseguimos reducirla a 24-48 horas la situación cambia considerablemente.

No siempre podremos actualizar inmediatamente. Pero deberíamos saber exactamente: Qué está vulnerable, por qué y cuándo pensamos solucionarlo.

Mi opinión

Muchas veces hablamos de vulnerabilidades pensando en servidores. Pero nuestros usuarios pasan buena parte del día dentro de un navegador. Y ese navegador está constantemente recibiendo contenido de Internet. Por eso creo que deberíamos tratarlo como lo que realmente es: una aplicación crítica de seguridad.

La pregunta que realmente debería preocuparnos es: ¿Cuántos equipos de mi organización siguen siendo vulnerables y cuánto voy a tardar en solucionarlo?»

Y si la respuesta depende de que alguien se acuerde de empaquetar manualmente la nueva versión del navegador…Tenemos un pequeño problema. 😅

pd: como siempre, espero que te haya servido de algo!