El 22 de septiembre CISA metió dos vulnerabilidades de Check Point en su catálogo de fallos explotados, con fecha límite el día 25. Tres días. La mayoría de las lecturas que hemos visto se quedaron en "parchea la VPN de acceso remoto". Pero la descripción oficial de la entrada dice literalmente "using Site to Site VPN or Remote Access VPN". Y el túnel entre tus sedes es otra cosa: ahí no hay un usuario al que pedirle un segundo factor. No hay nadie a quien pedírselo.
Lo que dice el catálogo, palabra por palabra
Nos descargamos el JSON del catálogo KEV de CISA (versión 2026.09.25, 1.726 entradas) en vez de fiarnos de los titulares, porque el matiz está en el texto. Las dos entradas nuevas son del 22 de septiembre, ambas con vencimiento el 25 y ambas marcadas con requisito de triaje forense:
- ·CVE-2026-85102: "Check Point Security Gateway y Check Point Spark Firewall usando Site to Site VPN o Remote Access VPN contienen una vulnerabilidad de validación incorrecta de certificado que podría permitir a un atacante remoto no autenticado ejecutar código arbitrario en el gateway".
- ·CVE-2026-93616: un fallo de path traversal en Security Management Server, Multi-Domain, Log Server y SmartEvent que permite "a un atacante no autenticado subir y ejecutar scripts arbitrarios". Es decir, el servidor que gobierna los gateways, no los gateways.
Las dos llevan un CVSS de 9,8. De la segunda no vamos a hablar mucho, porque el plano de gestión ya lo tratamos a fondo en julio con el zero-day de SmartConsole y la tesis era la misma: la consola es mejor botín que el cortafuegos. Lo que no habíamos contado nunca es lo de arriba.
El matiz que decide si te aplica: certificado o clave precompartida
El matiz importante, porque casi nunca aparece: el alcance se centra en los túneles que usan —o simplemente permiten— autenticación por certificado. Y ese "permiten" es la parte incómoda. Una pasarela que en la práctica levanta sus túneles con clave precompartida puede seguir aceptando certificado en la negociación, así que "nosotros vamos con PSK" no es una respuesta hasta que alguien ha ido a mirar la configuración. Comprobarlo y suponerlo no son lo mismo, y sobre un fallo pre-autenticación en explotación activa la diferencia no es académica.
Hay además un detalle de los ataques observados que encaja con todo lo que viene después: la oleada que arrancó el 12 de septiembre se dirigió sobre todo a clientes de Spark, la gama pequeña, la que está precisamente en las sucursales y en las oficinas de diez personas. Los atacantes salían por servicios de VPN y proxies para tapar el origen y mandaban certificados X.509 malformados durante la negociación. O sea que el aparato que más se ha llevado no es el grande del datacenter.
Un túnel entre sedes no tiene usuario
Aquí está lo que nos parece que se ha contado mal. Cuando alguien dice "fallo en la VPN", el reflejo es pensar en la puerta por la que entra la gente: el portátil de casa, el usuario, la contraseña, el segundo factor. Sobre esa puerta hemos construido una década de controles. Acceso condicional, MFA, cumplimiento del dispositivo, geolocalización, sesiones que caducan.
El túnel entre sedes no tiene nada de eso, y no por dejadez: por definición. Autentica máquinas, no personas. No hay segundo factor porque no hay factor. No hay acceso condicional porque no hay una identidad a la que aplicarle una condición. No caduca: se configuró una vez, el día que se abrió la oficina de Girona, y lleva ahí desde entonces. No aparece en el informe mensual de accesos porque no es un acceso, es topología.
Y ahora júntalo con dónde está el fallo. La validación del certificado ocurre durante la negociación, o sea antes de que la autenticación llegue a completarse y mucho antes de que tu directorio se entere de que alguien ha llamado a la puerta. Con precisión: el certificado es la autenticación de la máquina, y el fallo está justo ahí, en el trámite que decide si esa máquina es quien dice ser. Todo tu tinglado de identidad —el MFA, el acceso condicional, las políticas— vive detrás de la pieza que se rompió. No es que fallaran los controles: es que no llegaron a ejecutarse.
Lo que hay al otro lado del túnel
La segunda parte es peor que la primera, y es puramente de diseño de red. Un túnel entre sedes casi siempre desemboca en enrutado plano: la red de la sucursal ve la red de la central, y a menudo al revés. Se monta así porque es lo cómodo. El ERP tiene que verse, la impresora de la sucursal tiene que imprimir el albarán, el técnico tiene que llegar al NAS de allí desde aquí.
Con lo cual, el día que alguien se hace con ese gateway hereda la carretera entre todas tus sedes, y además con ejecución de código en el propio aparato que la vigila. Es la misma forma de problema que contamos hace tres días con el orquestador de SD-WAN: hay piezas cuyo compromiso no se mide por lo que esa pieza hace, sino por a cuántos sitios llega. Y lo mismo que vimos cuando el cortafuegos de la sucursal era una casilla que alguien marcó y nadie volvió a mirar.
Los dos avisos, leídos en pareja
Hay un detalle que solo aparece si pones los dos alcances uno al lado del otro, y que nos parece la parte más útil de todo esto. Según los resúmenes de alcance publicados, la rama R82.20 NO está afectada por el fallo del gateway (85102)… y en cambio sí figura en el alcance del fallo del servidor de gestión (93616). La versión que te salva de uno es exactamente la que te deja expuesto al otro.
Por eso "¿estamos parcheados?" es una mala pregunta. La buena es "¿parcheados contra cuál?". Y hay una trampa documentada esperando justo ahí: el canal de parcheo automático cubre uno de los dos fallos y no el otro. Los live patch que taparon el del gateway no remedian el del servidor de gestión, y el fabricante ha dicho que para ese no va a haber live patch por la naturaleza de la corrección: hay que instalar el acumulativo, y en el caso de R82.20 un parche específico aparte. Traducido a la reunión del lunes: puedes ver "protegido" en la consola, tener razón, y seguir dentro del alcance del otro fallo. Los números exactos de versión no los reproducimos aquí a propósito —publicar una versión equivocada en un post de seguridad es peor que no publicarla—: se cogen de sk1000117 y sk1000171, y de ningún otro sitio.
Esto no va de un fabricante
Sería fácil y deshonesto convertir esto en una pulla a una marca. El catálogo, mirado entero, cuenta otra cosa. En lo que va de año el mismo fabricante suma cuatro entradas en el catálogo, y tres de ellas atacan el mismo punto: el sitio donde se decide quién eres. (La cuarta es la del servidor de gestión de arriba.) En junio, un fallo de autenticación en el intercambio de claves IKEv1 que permitía —cita del propio catálogo— "establecer una conexión VPN de acceso remoto sin una contraseña de usuario válida", y que CISA marca como usado por campañas de ransomware. En julio, el token de administrador de la consola. En septiembre, la negociación del certificado.
Llámalo patrón de categoría. El concentrador VPN es un objetivo preferente porque es la única pieza de tu infraestructura que tiene la obligación de estar expuesta. Un servidor lo escondes. Una base de datos la segmentas. El cortafuegos que termina los túneles tiene que responder en Internet a quien le hable, porque ese es su trabajo. Nosotros montamos los túneles entre sedes con WireGuard y BGP, así que esta CVE concreta no toca nuestra propia red. Eso no nos hace mejores: nos hace tener otro fabricante del que preocuparnos y otro aviso que leer los lunes.
Opinión: el parche que llegó solo
Esta sección es opinión, y la marcamos como tal. Según lo publicado, el fabricante empezó a desplegar protección de forma automática a través de su servicio de live patch el mismo día que salieron los arreglos. A quien tuviera esa instalación automática activada eso le salvó la semana, y quien diga lo contrario no ha gestionado nunca un parque de cortafuegos. Y a la vez: es un cambio en tu perímetro que no pasó por tu ventana de mantenimiento y que no se anotó en tu registro de cambios. Con la vuelta de tuerca de que ese mismo canal no llega al segundo fallo, así que tampoco sirve para relajarse. Las dos cosas son verdad a la vez, y no pasa nada por sostenerlas. Si tu reacción es "menos mal", vale. La pregunta que dejamos es la otra: por ese mismo canal, ¿qué más puede llegar, y te enterarías?
Qué miraríamos esta semana
Parchear ya lo sabes hacer. Esto es lo otro, lo que sigue valiendo cuando el parche esté puesto y el siguiente aviso todavía no haya salido:
- 1Lista de túneles y cómo autentica cada uno. Certificado o PSK, por túnel. Si nadie del equipo puede contestar eso hoy, ese es el hallazgo del día, y es más grave que la CVE.
- 2Qué alcanza el otro extremo, mirando la tabla de rutas y no las intenciones. "La sucursal solo accede al ERP" es una frase; la tabla de rutas y las reglas son el hecho. Cuando no coinciden, gana la tabla de rutas.
- 3El plano de gestión, fuera del camino del túnel. Que llegar al túnel no sea llegar a la consola que gobierna el túnel. Si las dos cosas se alcanzan desde el mismo sitio, tienes una pieza y no dos.
- 4Los registros, antes de tocar nada. Las dos entradas piden triaje forense, y un triaje solo se puede hacer con lo que ya estuviera saliendo del aparato hacia otro sitio. Si tus logs viven únicamente en el gateway, el día que lo reinstales habrás cerrado la puerta y borrado la huella a la vez.
Sobre los indicadores publicados: se han descrito tres asuntos de certificado usados en los intentos observados (vpn, vpn-user, vpnuser). Sirven para buscar hacia atrás, no para dar nada por limpio. El propio aviso advierte de que puede haber más en uso, así que no encontrarlos no demuestra nada.
Zero Trust, dicho sin humo
Zero Trust se ha gastado de tanto usarlo para vender cajas. Aplicado a esto concreto cabe en una frase que puedes comprobar en tu red esta tarde, sin comprar nada y sin proyecto de dos años. Que entrar por el túnel no conceda nada por sí solo. Que el alcance lo decida la identidad y el destino, no la procedencia. Que "viene de la sede de Girona" deje de ser un argumento de autorización, porque cuando lo es, quien se hace con el gateway de Girona hereda ese argumento entero.
El fallo de esta semana ya tiene fecha de vencimiento cumplida. La decisión de cuánto alcanza un túnel se tomó hace años y sigue en pie hasta que alguien la cambia. La primera te la marca el calendario de otro; la segunda es tuya, y es la que decide si el próximo aviso es un rato de trabajo o un fin de semana.
Fuentes. Fechas, descripciones literales, alcance y requisito de triaje forense: catálogo Known Exploited Vulnerabilities de CISA, versión 2026.09.25, consultado directamente en su JSON — cisa.gov (entradas CVE-2026-85102 y CVE-2026-93616, añadidas el 22-09-2026; CVE-2026-50751, añadida el 08-06-2026). CVSS 9,8, referencias sk1000117 / sk1000171, el alcance centrado en túneles que usan o permiten autenticación por certificado y el alcance por ramas: resúmenes de Qualys ThreatPROTECT. Oleada del 12 de septiembre contra clientes Spark con certificados X.509 malformados en la negociación, despliegue automático vía live patch, el hecho de que ese canal NO cubre CVE-2026-93616 y los asuntos de certificado observados: el aviso del propio fabricante y BleepingComputer. Alcance por ramas de la segunda (incluida R82.20 y los acumulativos que la cierran), cotejado además con el aviso de Beazley Security, que lista R82.20 como versión ya corregida para el fallo del gateway. Los números de take no se reproducen aquí a propósito: consúltalos en el aviso del fabricante.
¿Sabes qué alcanza el otro extremo de tus túneles?
En everyWAN diseñamos y operamos redes y comunicaciones entre sedes, y aplicamos Zero Trust donde de verdad cambia algo: en el alcance, no en el folleto. Si no tienes claro qué ve cada extremo de tu red, empecemos por ahí.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN