Hay un tipo muy concreto de mal día en seguridad: aquel en el que el parche ya existía, los atacantes lo sabían y lo único que separaba a ellos de tu red era una ventana de mantenimiento que nadie programó.
Ahí están hoy los clientes de Check Point. El 22 de septiembre, Check Point Research publicó un aviso de acción obligatoria confirmando la explotación activa de CVE-2026-85102, un fallo de ejecución remota de código preautenticación en el manejo de certificados VPN de Security Gateway y Spark Firewall. El parche salió el 9 de septiembre. Los intentos de explotación empezaron el 12 de septiembre. La distancia entre "parche disponible" y "ataques en curso" fue de tres días.
Qué está realmente roto
CVE-2026-85102 es un fallo de validación de certificados en la ruta de negociación VPN, con CVSS 9.8. El gateway no valida correctamente los datos clave del certificado que presenta un par durante la negociación. Como el fallo se dispara antes de que se complete la autenticación, el atacante no necesita usuario, contraseña ni sesión. Envía un certificado manipulado, lleva la negociación lo suficientemente lejos y consigue ejecución de código en el propio appliance. Las versiones afectadas van de R81.10.x a R82.10, en Security Gateway y en despliegues de Spark Firewall gestionados de forma central y local.
El segundo fallo, CVE-2026-93616, es un path traversal preautenticación en el servicio web de Check Point Management. Permite a un atacante ejecutar un script desde una ruta arbitraria y cargar una clase Java arbitraria. Check Point observó un puñado de ataques muy localizados contra él el 23 de julio, y el arreglo llegó con este aviso. Fíjate en el detalle que escuece: LivePatch Take 28/29 no lo soluciona.
La parte que debería preocuparte
Esto no es una historia teórica de "investigadores que lo demostraron". Check Point publicó los sujetos de certificado que su telemetría capturó en el mundo real:
CN=vpn,OU=users,O=globalCN=vpn-user,OU=users,O=globalCN=vpnuser,OU=users,O=global
Esos intentos venían de infraestructura de anonimización: servicios VPN y proxies, la habitual capa de blanqueo. El comportamiento posterior es la señal que importa. Tras un inicio de sesión sospechoso en Mobile Access, la segunda fase observada es el escaneo interno de puertos y servicios. Alguien entra por el perímetro y empieza a mapear qué más es alcanzable.
Y el perímetro es justo donde un RCE preautenticación sale más caro. Tu gateway VPN no es una aplicación detrás de un WAF. Es un appliance específico situado en la frontera de confianza, normalmente conectado a tu proveedor de identidad, tu red de gestión interna y, a veces, a tu directorio. La ejecución de código ahí no es un paso hacia la escalada de privilegios. Normalmente ya está al otro lado del muro.
Tres días es el nuevo para siempre
La cronología merece una mirada fría, porque es la lección real:
- 9 de septiembre: Check Point revela CVE-2026-85102 y publica los arreglos. Sin explotación observada.
- 12 de septiembre: comienza una oleada de intentos de explotación contra clientes de Spark en todo el mundo.
- 22 de septiembre: un aviso de acción obligatoria confirma ataques reales.
Son dos semanas desde la divulgación hasta la explotación confirmada, y solo tres días desde el parche hasta el ataque. Cualquier organización que siga con un ciclo de mantenimiento más largo que eso está gestionando una exposición, no un calendario. La economía pública de proof-of-concepts y el escaneo automatizado van demasiado rápido hoy como para que parchear cada trimestre sea una estrategia.
Qué hacer esta semana
Si operas Check Point Security Gateway o Security Management, trátalo como un cambio de postura de respuesta a incidentes, no como un ticket de parcheo:
- Instala los arreglos ya. CVE-2026-85102 está cubierto por la versión del 9 de septiembre; CVE-2026-93616 requiere los Jumbo Hotfix indicados en el aviso (R82.10 Take 45+, R82 Take 127+, R81.20 Take 167+, R81.10 Take 191+) o la compilación más reciente de sk1000171. Omite LivePatch Take 28/29 para el fallo de gestión.
- Caza en tus logs de Mobile Access. Busca inicios de sesión anómalos basados en certificado y no limites la búsqueda a los tres sujetos anteriores. La lista es explícitamente incompleta.
- Persigue la segunda fase. Para cada usuario sospechoso conectado, busca escaneos internos de puertos y servicios originados en esa sesión. Ese patrón es lo que distingue un sondeo bloqueado de un punto de apoyo.
- Inventaría la cola sin soporte. R81 y R81.10 están fuera de soporte y siguen en la lista de afectados. Si tienes equipos en esa cola, estás parcheando un sistema para el que nadie publica arreglos por defecto. Planifica el reemplazo, no solo el hotfix.
- Asume que los fallos en fase de negociación son recursivos. Cada appliance VPN y TLS que tienes valida certificados en algún punto. Haz a tus proveedores la pregunta incómoda: ¿qué pasa cuando esa validación falla en abierto?
La conclusión
Los atacantes no necesitaron magia de zero-day para el evento principal. Usaron un fallo que tenía parche, aviso y dos semanas de ventaja. Las organizaciones que salen heridas aquí no son las que tienen peores herramientas. Son aquellas cuyo cambio de gestión trata un RCE de perímetro con 9.8 como una línea rutinaria.
Parchea ahora. Luego ve a leer los logs. Los escaneos son la parte de la historia que todavía puedes atrapar.