CVE-2026-93616: path traversal crítico en Check Point Security Management Server

septiembre 23, 2026 Alfonso Moreno | Sysadmin Senior 68 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué este fallo importa aunque no uses Check Point

El 22 de septiembre de 2026 Check Point publicó el aviso sk1000171 con un parche de emergencia para CVE-2026-93616, una vulnerabilidad de path traversal con CVSS 9.8 en el servicio web del Security Management Server. Lo urgente no es sólo que ya está siendo explotada en ataques dirigidos desde el 23 de julio, sino que combina tres factores que la convierten en crítica: no requiere autenticación, permite subir y ejecutar scripts arbitrarios, y el componente afectado controla las políticas de firewall y los logs de toda la flota de gateways administrados.

Si tu organización usa Quantum Security Gateway con un Management Server on-premise —algo común en empresas que empezaron con Check Point hace una década y no migraron a Spark ni a Smart-1 Cloud—, esta CVE te toca directamente. Si administras otra marca pero tu proveedor o cliente final corre Check Point en algún segmento, también te toca. Y si simplemente te interesa entender qué patrón de vulnerabilidad sigue apareciendo una y otra vez en productos enterprise, este caso es de manual.

Qué es CVE-2026-93616 técnicamente

El fallo reside en el servicio web del Management Server (puerto TCP/19009) que expone las APIs internas para SmartConsole y otros componentes de administración. La validación de rutas de archivos en uno de los endpoints no sanea correctamente secuencias ../, permitiendo a un atacante no autenticado:

Construir una URL con traversal (../../../../tmp/...) que evade las restricciones de directorio del servidor.
Cargar un archivo arbitrario en una ruta writable del Management Server.
Ejecutar ese archivo como script dentro del contexto del servicio web, que corre con privilegios altos.

El tipo de vulnerabilidad es CWE-22 (Path Traversal) combinado con CWE-434 (Unrestricted Upload of File with Dangerous Type). La cadena completa es lo que le da el CVSS 9.8: vector de red, complejidad baja, sin autenticación, sin interacción de usuario, impacto alto en confidencialidad, integridad y disponibilidad.

Productos y versiones afectadas

Según el advisory oficial de Check Point, los productos afectados son:

Producto	Estado
Security Management Server	Afectado
Multi-Domain Security Management Server	Afectado
Log Server	Afectado
Multi-Domain Log Server	Afectado
SmartEvent	Afectado
Smart-1 Cloud	No afectado (fix ya aplicado)
Check Point Firewall Appliances	No afectado
Check Point Spark Firewall	No afectado

Versiones específicas con la vulnerabilidad:

R82.20 — vulnerable en la versión base, fixed en Security Hotfix TAR.
R82.10 — vulnerable hasta Jumbo Hotfix Accumulator Take 44 (fixed en Take 45).
R82 — vulnerable hasta JHF Take 126 (fixed en Take 127).
R81.20 — vulnerable hasta JHF Take 166 (fixed en Take 170).
R81.10 — vulnerable hasta JHF Take 190, ya en End of Support.
R80, R80.10, R80.20, R80.30, R80.40, R81 — todas en EoS, sin fix oficial.

Importante: el LivePatch Take 28/29 NO cubre CVE-2026-93616. Check Point no pudo generar un parche en caliente por la naturaleza del fix — toca recompilar binarios y reemplazar componentes del servicio web.

Por qué importa el patrón de path traversal en 2026

CISA y el FBI llevan desde mayo de 2024 instando a los fabricantes de software a eliminar las debilidades de path traversal antes de publicar, citando que estos bugs son “unforgivable since at least 2007“. Aun así, siguen apareciendo en productos enterprise de primer nivel. Lo llamativo de CVE-2026-93616 es que el patrón es viejo pero la superficie de ataque es nueva: el servicio web del Management Server no era accesible directamente desde internet en deployments clásicos (estaba detrás de un gateway interno), pero la tendencia a exponer consolas de administración vía reverse proxy o VPN SSL ha ampliado esa superficie.

Para un sysadmin Linux, el equivalente cotidiano de este fallo es un endpoint PHP o Python que hace open(os.path.join(base_dir, user_input)) sin sanear ../. La remediación genérica — usar os.path.realpath() y verificar que el resultado siga dentro de base_dir con commonpath() — aplica igual aquí. El bug no es de Check Point; es de quien escribió el handler HTTP hace 8-10 años y nadie revisó.

Cómo verificar si tu Management Server fue comprometido

Check Point publicó dos indicadores de compromiso (IOCs) específicos en el advisory. Ambos se corren desde Expert mode en el Management Server afectado.

IOC #1: logins con username anormalmente largo. El exploit intenta enviar credenciales con un payload mayor a 1000 caracteres en el campo username para desbordar buffers en la validación. Desde el shell Expert del appliance:

grep -nHP "login(loginRequest=LoginRequest{authenticationInfo=AuthenticationInfoBase{username='[^']{1001,}'" "$MDS_FWDIR"/log/cpm.elg*

Si este comando devuelve alguna línea, hay que correlacionar con dumps del proceso FWM o MDS en el mismo timestamp:

ls -l /var/log/dump/usermode/ | grep -e fwm -e mds

Si hay un dump de fwm o mds generado al mismo tiempo que el login sospechoso, hay alta probabilidad de que el intento de exploit haya tenido éxito parcial (crasheó el proceso al desbordar).

IOC #2: errores de ReflectionUtils con paths traversal. El endpoint vulnerable registra errores al intentar cargar archivos desde rutas mal formadas:

grep -E "ERROR.*upgrade.base.ReflectionUtils.*Failed to load allResourceFiles map from" $MDS_FWDIR/log/cpm.elg*

Output de ejemplo que indica intento de exploit:

18/09/26 21:54:57,396 ERROR upgrade.base.ReflectionUtils [qtp700085606-66]: Failed to load allResourceFiles map from /opt/CPupgrade-tools-../../../../tmp/003193_VULNCHECK/scripts/upgrade_files.conf

Si ves ../../../../ en la ruta del log, eso es un intento de traversal desde la red hacia tu Management Server.

Mitigación inmediata si no puedes aplicar el hotfix hoy

El advisory oficial recomienda tres acciones temporales mientras se coordina la ventana de mantenimiento para instalar el hotfix.

1. Limitar acceso al puerto TCP/19009. El Management Server NO debería estar accesible directamente desde internet ni desde redes no confiables. Si tienes un Security Gateway o firewall delante, crear una regla que sólo permita el tráfico al puerto 19009 desde IPs internas de administración específicas.

# Verificar quién está hablando con el puerto 19009 HOY
tcpdump -i any -nn -s 0 -w /tmp/cp_19009.pcap 'tcp port 19009' &
sleep 3600
tcpdump -r /tmp/cp_19009.pcap -nn | awk '{print $3}' | cut -d. -f1-4 | sort -u | head -20

Este comando captura una hora de tráfico al puerto de administración y lista las IPs fuente únicas. Si ves IPs públicas o segmentos no esperados, hay algo fuera de lugar.

2. Configurar Trusted Clients en SmartConsole. Si ya tienes un Security Gateway con implied rules activas, puedes refinar la lista de Trusted Clients para que sólo las IPs internas de tu equipo de seguridad puedan administrar el Management Server:

Abrí SmartConsole.
Ir a Manage & Settings → Permissions & Administrators → Trusted Clients.
Doble clic sobre cada cliente de la lista y ajustar los rangos.
Esto crea una implied rule que limita el acceso antes que llegue al servicio vulnerable.

3. Poner el Management Server detrás de un firewall dedicado. Si tu deployment actual expone el Management Server directamente o vía un bastion host poco segmentado, esta CVE es el momento ideal para repensar la arquitectura. Un jump host con MFA + bastion en una VLAN aislada es el patrón recomendado.

Ninguna de estas mitigaciones es permanente. El fix real está en los Jumbo Hotfix Accumulator mencionados arriba.

Cómo aplicar el fix correctamente

El proceso de upgrade depende de la versión exacta:

Para R82.20: descargar el R82.20 Security Hotfix (TAR) y seguir el procedimiento de Check Point para instalarlo en caliente. Este hotfix reemplaza binarios del servicio web — requiere reinicio del proceso CPD, pero NO reinicio del appliance completo.

Para R82.10, R82, R81.20: instalar el Jumbo Hotfix Accumulator correspondiente (Take 45 / 127 / 170 o superior). Estos Jumbo HFAs también incluyen el fix para CVE-2026-91843, una vulnerabilidad previa en el mismo componente. La instalación de un JHA reinicia múltiples servicios — planificar ventana de mantenimiento.

Para R81.10 y todas las versiones R80-R81: Check Point no va a publicar fix. Estas versiones están en End of Support. La mitigación es estricta: limitar acceso de red al Management Server y planificar upgrade a R82.x en los próximos 30-60 días.

# Verificar versión actual del Management Server desde Expert mode
cpstat -f version mgmt
# Verificar Jumbo Hotfix Take instalado
cpinfo -y all | grep -A1 "Jumbo Hotfix"

Si el output muestra un Take igual o menor al listado en la tabla de versiones afectadas arriba, el Management Server es vulnerable y necesita actualización inmediata.

Lo que este caso enseña sobre administración de appliances enterprise

CVE-2026-93616 es el tercer fallo crítico explotado in-the-wild en Management Server o VPN de Check Point en los últimos 90 días, después de CVE-2026-85102/85103 (VPN RCE, parcheado 9-sept-2026) y CVE-2026-16232 (auth bypass en SmartConsole, julio 2026). El patrón que se repite: la superficie de ataque del plano de administración se expandió más rápido que las prácticas de hardening de los deployments existentes.

Para equipos que corren Check Point o appliances similares (Fortinet FortiManager, Palo Alto Panorama, Cisco FMC), las tres acciones que pagan dividendos inmediatos son:

Inventario honesto: ¿dónde están corriendo los Management Servers? ¿quién tiene acceso? ¿hay alguno accesible desde internet sin querer?
Segmentación estricta: jump host + MFA + VLAN aislada para administración. Si todavía manejás tus appliances vía VPN SSL con usuario y password, este trimestre es el momento de cambiar.
Monitoring de IOCs: configurar alerting en tu SIEM sobre los IOCs publicados por el vendor. Los grep de cpm.elg en este caso se pueden traducir a reglas Sigma o a queries Splunk/Elastic sin mucho esfuerzo.

El ataque no fue masivo — Check Point habla de “a handful of customers” — pero precisamente por eso es el preludio de algo más grande. Los grupos APT que tuvieron acceso temprano al 0-day suelen usarlo en oleadas: primero targets de alto valor, después masivamente cuando hay PoC público circulando.

Resumen

CVE-2026-93616 es una vulnerabilidad crítica de path traversal con CVSS 9.8 en el Security Management Server de Check Point, explotada activamente desde julio 2026, parcheada el 22-sept-2026. Si tu organización tiene un Management Server on-premise en R80-R82.20, el orden de operaciones es: (1) verificar versión con cpstat; (2) buscar IOCs en logs con los grep del advisory; (3) instalar el JHA correspondiente o el Security Hotfix de R82.20; (4) si no puedes patchear hoy, limitar acceso al puerto 19009 y configurar Trusted Clients en SmartConsole. La superficie de administración es el nuevo perímetro — tratarla como tal es la única defensa durable.

Preguntas frecuentes

¿Por qué CVE-2026-93616: path traversal crítico en Check Point Security Management Server es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con CVE-2026-93616: path traversal crítico en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con CVE-2026-93616: path traversal crítico en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar CVE-2026-93616: path traversal crítico en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a CVE-2026-93616: path traversal crítico en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.