CVE-2026-91843: Ejecución de código como root en Check Point Security Management Server

Por qué esta vulnerabilidad de Check Point te importa aunque no uses sus appliances

El 16 de septiembre de 2026, Check Point publicó un aviso crítico sobre CVE-2026-91843, una vulnerabilidad de desbordamiento de pila (stack overflow) en el proceso de autenticación no autenticado de sus servidores de gestión. El fallo permite a un atacante remoto, sin credenciales, ejecutar código arbitrario como root en los servidores Security Management y Log. La puntuación CVSS v3.1 asignada por Check Point es 9.8 (crítico), con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: red, baja complejidad, sin privilegios, sin interacción y con impacto total en confidencialidad, integridad y disponibilidad.

¿Por qué importa si en tu homelab corres OPNsense o pfSense? Porque detrás de muchas empresas que sí son clientes de Check Point están tus proveedores, tus clientes B2B y tu propia matriz si trabajas en una organización grande. Si su servidor de gestión cae, tu conexión de VPN sitio-a-sitio se cae con él. Si además de los gateways tienen tú un appliance de Check Point en alguna sede, esto te toca directo.

Qué productos están afectados

El aviso oficial sk1000155 lista los siguientes productos impactados:

• Security Management Server (SMS).
• Multi-Domain Security Management Server (MDS).
• Log Server.
• Multi-Domain Log Server (MLog).

Nota importante del propio aviso: Smart-1 Cloud NO está afectado, porque la corrección ya se desplegó en la infraestructura cloud antes de hacerse pública la vulnerabilidad.

Qué versiones reciben el parche

Las versiones afectadas y los umbrales de Jumbo Hotfix a partir de los cuales ya no aplica la vulnerabilidad son:

Versión de Check Point	Estado de soporte	Aplica si el Jumbo Hotfix Take es ≤
R82.20	Soportada	Aplica hasta el take 28 incluido
R82.10	Soportada	44
R82	Soportada	126
R81.20	Soportada	166
R81.10	EoS	190
R81	EoS	todas
R80.40	EoS	todas
R80.30, R80.20, R80.10, R80	EoS	todas

Si tienes un servidor en versión R80.x o R81 sin mantenimiento activo, el aviso oficial no entrega parche y la única vía es migrar a una versión soportada (R81.20, R82, R82.10 o R82.20). Check Point lo deja claro: para versiones EoS, la actualización de plataforma es obligatoria.

Cómo funciona el ataque, sin inventar

El aviso oficial describe la mecánica con una frase: “A stack overflow during the unauthenticated login process may allow an attacker to run arbitrary code remotely with root privileges.” En castellano: el proceso de login pre-autenticación recibe datos del cliente y los copia a un buffer de pila sin validar el largo. Un atacante remoto envía un nombre de usuario deliberadamente largo y desborda la pila, lo que en arquitecturas x86_64 clásicas permite sobrescribir la dirección de retorno del frame y desviar la ejecución a shellcode que se ejecuta con privilegios de root, dado que el servicio afectado corre como root en la arquitectura de Gaia.

La CWE asignada por NVD y por el CNA de Check Point es CWE-121 (Stack-based Buffer Overflow), una clase conocida y duradera. Que un stack overflow no autenticado llegue a producción en 2026 y se catalogue como crítico es, siendo francos, un recordatorio de que las auditorías modernas con fuzzing siguen encontrando lo básico en productos maduros.

Para que te quede claro el flujo:

1. El atacante llega al puerto de gestión (típicamente TCP 443 o TCP 19009 dependiendo de la configuración de SmartConsole) sin autenticarse.
2. Envía un login con un campo username de longitud anormal.
3. La rutina de parsing copia el campo a un buffer de tamaño fijo sin validar el largo, lo desborda y pisa el saved RIP/RBP en la pila.
4. Cuando la función retorna, la ejecución salta a la dirección controlada por el atacante y se ejecuta con UID 0.

Check Point, al cierre del aviso público, indica que no tiene constancia de explotación en producción ni de código PoC público. Eso no significa que no lo vayas a ver esta semana: cuando una CVE de 9.8 sale a la luz, el reloj hasta el primer PoC se mide en horas, no en días.

Cómo saber si te intentaron atacar

El aviso oficial entrega un indicador de compromiso muy útil para la fase de triage. En SmartConsole, busca en los logs de Audit and Admin login la cadena:

Administrator failed to log in: Username too long

Esta entrada la genera el propio servicio cuando recibe un intento de login con un username que excede el largo máximo permitido. Si ves esta línea repetida desde una IP externa que no es tu VPN corporativa, asume que alguien ya te probó la CVE. El log debería aparecer con marca temporal y la IP de origen del intento.

Aplicar el parche: la vía soportada

Check Point entrega la corrección mediante LivePatch, su sistema de hotfixes en caliente sin reinicio. Los paquetes offline disponibles son:

Versión	Paquete
R82.20	BUNDLE_URGENT_SECURITY_UPDATE_R82_10_AUTOUPDATE take 29 (TAR)
R82.10	BUNDLE_URGENT_SECURITY_UPDATE_R82_10_AUTOUPDATE take 28 (TAR)
R82	BUNDLE_URGENT_SECURITY_UPDATE_R82_AUTOUPDATE take 28 (TAR)
R81.20	BUNDLE_URGENT_SECURITY_UPDATE_R81_20_AUTOUPDATE take 28 (TAR)

El procedimiento de instalación está en sk185114. Si tienes auto-update habilitado según sk175504, ya estás protegido y no tienes que hacer nada más que validar.

Si quieres validar a mano que el LivePatch quedó aplicado, entra a Expert mode en el Security Management Server o Log Server y corre:

cplp list

El resultado esperado incluye una línea con el identificador del proceso fwm y el comentario CVE-2026-91843:

[Expert@MGMT]# cplp list
ID(PATCH:PROC)        STATUS  MODE            COMMENT
--------------------------------------------------------------------------
fwm:fwm               armed   livepatch       CVE-2026-91843

Si la línea armed aparece, el LivePatch está cargado en memoria y protegiendo el binario fwm sin necesidad de reinicio. Si no aparece, revisa si el paquete se instaló correctamente y si reiniciaste el servicio tras la instalación.

Mitigación si todavía no pudiste parchear

El aviso oficial entrega dos mitigaciones aplicables en caliente, antes de poder instalar el LivePatch. Ambas están pensadas para reducir la superficie de ataque sin esperar a una ventana de mantenimiento.

La primera es seguir la guía de hardening general de Check Point para Gateway y Management (sc1.checkpoint.com/documents/Check_Point_Gateway_and_Management_Hardening). Es larga, pero el capítulo de Trusted Clients es el que te interesa aquí.

La segunda, la realmente operativa: limitar los Trusted Clients (los clientes GUI que pueden conectar al servidor de gestión vía SmartConsole) a subredes IP de confianza. Desde SmartConsole:

Manage & Settings > Permissions & Administrators > Trusted Clients

Edita cada cliente y deja el Client Type apuntando a un objeto de red específico, no a Any. Si tienes una consola de administración en una subred 10.0.5.0/24, crea un objeto de red para esa subred y úsalo como Trusted Client. Lo que quieres es que un atacante desde internet, aunque descubra el puerto 443 del SMS, no llegue ni a la fase de login.

Por qué Trusted Clients mitiga, y por qué no es suficiente sola

Trusted Clients actúa a nivel del handshake de SmartConsole: si la IP origen no está en la lista, la conexión GUI se rechaza antes incluso de llegar al proceso vulnerable. Es una mitigación válida, pero tiene una limitación: solo aplica a clientes GUI de administración, no a tráfico de gestión automatizada (API REST de Gaia, fetching de logs, syslog forward, integración con SIEM). Si abriste el puerto de gestión a internet por error, o si tienes un jump host que enruta a varios subrangos, la mitigación se queda corta.

La combinación correcta para un sysadmin que no puede parchear hoy mismo:

1. Lista blanca de Trusted Clients por subred, sin Any.
2. Regla de firewall perimetral que limite el acceso al puerto de gestión a un jump host o VPN corporativa.
3. LivePatch programado para la próxima ventana de mantenimiento.
4. Reglas de detección en el SIEM (si lo tienes) que alerten sobre Username too long desde cualquier IP externa.

Qué significa para sysadmins Linux y homelab

Si eres sysadmin en una empresa con appliances Check Point, tu lista de tareas para esta semana es:

1. Inventariar todos los Security Management Server, Multi-Domain SMS, Log Server y Multi-Domain Log Server de tu parque. Pregunta al equipo de red si los tienen separados de los gateways.
2. Verificar versión y Jumbo Hotfix Take de cada uno. Para cada uno que aparezca como vulnerable, abre ticket de cambio para aplicar LivePatch.
3. Aplicar la mitigación de Trusted Clients ya mismo, sin esperar al parche. Reduce la ventana de exposición.
4. Activar la búsqueda del log Username too long en tu SIEM si lo tienes, o grep en logs locales del SMS mientras tanto.

Si eres entusiasta de homelab y NO usas Check Point, este CVE no te toca directo, pero te deja dos lecciones que sí son tuyas. La primera: los desbordamientos de pila sin autenticación siguen siendo moneda corriente incluso en productos de seguridad perimetral de primer nivel. La segunda: separar la capa de gestión de los gateways no es paranoia, es higiene. Cuando el próximo 9.8 caiga sobre el componente de gestión y no sobre el de forwarding, tu tráfico seguirá pasando mientras los sysadmins de seguridad apagan fuegos.

Diagnóstico rápido desde Linux

Si quieres comprobar desde una máquina Linux si tu servidor de gestión está expuesto a internet sin querer, el chequeo mínimo es:

nmap -Pn -p 443,19009,18190,18264 mgmt.example.com

Si esos puertos responden desde una IP pública de un ASN que no es tu proveedor, tienes superficie de ataque innecesaria. La forma correcta de exponer un SMS a administradores remotos es vía VPN corporativa o jump host con MFA, nunca con el puerto abierto a 0.0.0.0/0.

Conclusión

CVE-2026-91843 es un recordatorio incómodo: los stack overflow en código C siguen encontrando camino en productos que llevan décadas en producción. Check Point respondió rápido con LivePatch en caliente, sin reinicio, y publicó una mitigación operativa de Trusted Clients que aplica mientras se agenda el cambio. Si tienes un Security Management Server en cualquier versión de R80.x a R82.x, el orden es: inventario, mitigación, LivePatch, búsqueda de IOCs. Si tu organización ni siquiera sabe cuántos SMS tiene, este es el momento de averiguarlo.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux