Check Point parchea dos fallos de VPN de severidad 9.8 que permiten ejecución de código sin autenticación

Check Point publicó el 9 de septiembre actualizaciones de emergencia para dos vulnerabilidades críticas en la gestión de certificados de sus productos VPN, fallos que permitirían a un atacante sin autenticación ejecutar código en un cortafuegos o un servidor de gestión situado en el borde de una red corporativa.

Lectura relacionada: WordPress parchea Comment2Shell, un fallo en los comentarios que puede llevar a la toma de control del servidor · Oracle publica 673 parches de seguridad, incluidos seis fallos de gravedad máxima.

Ambos fallos tienen una puntuación CVSS de 9.8, la calificación máxima de gravedad, y los dos pueden desencadenarse de forma remota sin credenciales. El primero, registrado como CVE-2026-85102, es una validación incorrecta de los datos del certificado durante la negociación de la VPN. El segundo, CVE-2026-85103, es un desbordamiento de búfer basado en montículo (heap) en la decodificación ASN.1 de los certificados VPN. Check Point publicó los avisos sk1000117 y sk1000118, y el CERT-EU de la Unión Europea emitió su propia alerta.

Los productos afectados son Check Point Security Gateway, Security Management Server y Spark Firewall, en las ramas de versiones R81.20, R82 y R82.10 configuradas para Remote Access VPN o Site-to-Site VPN. Check Point dijo que la rama más reciente, R82.20, no está afectada. Como estos dispositivos gestionan la política de cortafuegos y terminan túneles VPN, un compromiso exitoso no se queda en exponer un solo aparato: puede dar al atacante un punto de apoyo en el perímetro de la red y una ruta hacia los sistemas internos y la consola de gestión que controla todas las pasarelas de la organización.

Por qué el análisis de certificados es el punto débil

Ambos fallos se encuentran en la parte del handshake de VPN que se ejecuta antes de verificar la identidad del usuario. Para establecer un túnel, la pasarela debe analizar y validar un certificado presentado por la otra parte. Ese análisis ocurre pronto y en un puerto de red accesible, que es justo la combinación que buscan los atacantes en un dispositivo expuesto a internet.

En CVE-2026-85102, la pasarela no establece correctamente la confianza de un certificado presentado, lo que permite a un atacante sin autenticación llevar la negociación lo bastante lejos como para ejecutar código. En CVE-2026-85103, un certificado especialmente manipulado corrompe la memoria del montículo dentro del decodificador ASN.1 y otorga al atacante el control de la ejecución tanto en las Security Gateway como en los Security Management Server. Armis, que sigue el segundo fallo, señala que las versiones vulnerables son R82.10 con Jumbo Hotfix Take 43 o anterior, R82 con Take 125 o anterior, y R81.20 con Take 165 o anterior.

La distinción entre ambos importa a los administradores. CVE-2026-85102 afecta a las Security Gateway y a los Spark Firewall usados para VPN. CVE-2026-85103 llega también al plano de gestión, lo que significa que un solo certificado malformado podría comprometer la consola que aprovisiona políticas en todos los cortafuegos de una organización.

Quién está expuesto y con cuánta urgencia

Check Point dijo que ambas vulnerabilidades se descubrieron internamente y que no tiene indicios de que se hayan explotado. También afirmó que no existía código de prueba de concepto público en el momento de la divulgación. Esa es una posición de partida, no una definitiva.

El Centro Nacional de Ciberseguridad de los Países Bajos evaluó como alta la probabilidad de explotación y el impacto potencial, y dijo el 10 de septiembre que esperaba que aparecieran intentos de explotación pronto. El razonamiento es el habitual para esta clase de fallo: un fallo de ejecución remota de código, sin autenticación y accesible desde la red, en un dispositivo de perímetro, resulta atractivo para bandas de ransomware y grupos vinculados a Estados, y la historia sugiere que la ventana entre la divulgación y la explotación es corta. El fallo de path traversal de GitLab, parcheado el día después de la actualización de Check Point, ya estaba siendo sondeado en cuestión de horas, un recordatorio de la velocidad del ciclo de escaneo.

Check Point descubrió ambos problemas por sí misma. Es una buena señal para las pruebas internas de la compañía, pero también significa que el público no ha tenido ocasión de evaluar de forma independiente qué tan difíciles son de desencadenar los fallos, y que no ha circulado ninguna prueba de concepto que dé a los defensores una forma de comprobar su propia exposición.

Versiones corregidas y soluciones alternativas

Para las ramas compatibles, los estados corregidos son R82.10 Jumbo Hotfix Take 44 o posterior, R82 Take 126 o posterior, y R81.20 Take 166 o posterior. Las correcciones de Spark Firewall se incluyen en R82.00.10 Build 2325 o posterior y R81.10.17 Build 4968 o posterior. Los clientes con Check Point LivePatch activado deberían recibir las correcciones automáticamente; la compañía empezó el despliegue de LivePatch el 9 de septiembre. Los administradores que no hayan verificado que el parche se instaló realmente no deberían dar por hecho que la vía automática funcionó, y deberían comprobar el estado del hotfix instalado o de LivePatch frente al aviso.

Cuando no sea posible parchear de inmediato, Check Point recomienda una reducción temporal de la exposición para Site-to-Site VPN: desactivar las reglas implícitas de VPN y definir manualmente el acceso VPN para el puerto UDP 500 y el puerto UDP 4500, limitado a direcciones IP de pares específicas. La compañía advierte de que esta mitigación no se aplica a Remote Access VPN y de que no hay solución alternativa para las instancias de Spark Firewall gestionadas localmente, que deberían parchearse cuanto antes.

Esas restricciones son un apaño temporal, no una solución. Cualquier dirección de par que aún pueda alcanzar el puerto VPN todavía puede entregar el certificado malformado, así que reducir la lista de permitidos disminuye la superficie de ataque sin cerrar la vulnerabilidad.

El patrón más amplio

La divulgación de Check Point llega en un mes cargado para la seguridad del perímetro de red. Cisco Talos informó de que tres clústeres de amenazas distintos habían explotado dos fallos del Secure Firewall Management Center, entre ellos un bypass de autenticación de gravedad máxima, con un clúster vinculado a afiliados del ransomware Qilin y otro a un grupo cuyo arsenal se solapa con el APT Sandworm. La CISA añadió otros cinco fallos explotados activamente a su catálogo de vulnerabilidades explotadas conocidas, que abarcan JFrog Artifactory, ConnectWise ScreenConnect y MikroTik RouterOS. Y el fallo de path traversal de GitLab, con CVSS 10.0, fue sondeado en el plazo de un día desde su parche.

En conjunto, el patrón resulta conocido: los dispositivos en los que las organizaciones confían para imponer la confianza en el borde de la red se están convirtiendo ellos mismos en el objetivo, porque comprometer uno da acceso a todo lo que hay detrás. Los concentradores VPN son especialmente valiosos porque están en la internet pública por diseño y porque sus usuarios esperan que sean accesibles.

Cómo encuentran los atacantes las pasarelas expuestas

El riesgo práctico de un fallo como este depende menos de su puntuación CVSS que de cuántos dispositivos afectados sean accesibles desde internet y de la rapidez con la que aparezca un exploit. Ambas condiciones tienden a favorecer al atacante. Los servicios de escaneo a escala de internet indexan los portales VPN de forma continua, y catalogar una pasarela que anuncia su fabricante y su versión en una página de inicio de sesión es sencillo. Una vez publicado un parche, esos mismos servicios permiten al atacante filtrar dispositivos sin parchear, y la distancia entre la divulgación y la conversión en arma suele medirse en días.

Los dispositivos de perímetro se han convertido por eso en un vector preferido de acceso inicial. En los últimos años ha habido campañas sostenidas contra dispositivos VPN y de borde de Ivanti, Fortinet, Citrix, Palo Alto Networks y Cisco, con grupos vinculados a Estados y afiliados de ransomware que los tratan como una vía de entrada a redes por lo demás bien defendidas. Un compromiso exitoso de un servidor de gestión es peor todavía: puede dar al atacante la capacidad de aplicar políticas, confiar en nuevos certificados y alcanzar todas las pasarelas que controla el servidor.

Parchear estos dispositivos es más difícil de lo que parece. Están en entornos controlados por cambios, donde el tiempo de inactividad exige una ventana de mantenimiento; a menudo funcionan en pares de alta disponibilidad que deben actualizarse de uno en uno; y muchos los gestionan equipos regionales de forma local, sin un inventario central. Los dispositivos también generan mucha menos telemetría de seguridad que los endpoints, así que una brecha puede dejar pocos rastros evidentes. El propio consejo de Check Point de verificar que LivePatch se instaló realmente refleja con qué frecuencia una afirmación de haber parcheado resulta significar que la actualización solo se programó.

La combinación de alto valor, conversión rápida en arma y remediación lenta es la razón por la que los reguladores y las firmas de respuesta a incidentes tratan las vulnerabilidades de borde como urgentes incluso antes de que se confirme la explotación. Para los atacantes, una pasarela sin parchear suele ser la vía más barata a un punto de apoyo, y para los defensores es con frecuencia el último dispositivo que a alguien se le ocurre actualizar.

Qué hacer

Los clientes de Check Point deberían inventariar sus pasarelas, servidores de gestión y dispositivos Spark, registrar la versión exacta y el take del hotfix instalado, y confirmar frente a los avisos del fabricante si cada dispositivo está afectado. Los dispositivos con un take corregido deberían documentarse como remediados. Los dispositivos con un take afectado, y con LivePatch no confirmado como instalado, deberían actualizarse por la vía compatible de Jumbo Hotfix para su rama.

A más largo plazo, el episodio refuerza el argumento a favor de limitar lo que un dispositivo VPN puede exponer. Restringir las interfaces de gestión a una red segregada, exigir autenticación multifactor incluso donde se usan certificados y vigilar los errores de análisis de certificados en busca de indicios de sondeo reducen el radio de impacto si un parche llega tarde. Ninguno de esos controles sustituye la actualización de un dispositivo con un fallo de preautenticación calificado con 9.8. Pero son lo que convierte una brecha de perímetro en un incidente contenido en lugar de uno de alcance global.

La acción inmediata es poco lucida y urgente en el tiempo: parchear, verificar que el parche se instaló y no esperar a que aparezca una prueba de concepto para tratar los fallos como urgentes.