Zero-day de Check Point: lo usaron para tomar firewalls como root y ya hay hotfix

El zero-day de Check Point que ya se usaba para tomar el control total de sus firewalls tiene arreglo. La falla, registrada como CVE-2026-123039, está en un servicio interno de Gaia, el sistema operativo de sus equipos, y le permite a quien ya logró ejecutar algo adentro del equipo dar órdenes como root, el usuario con todos los permisos. Sola no abre la puerta: en este ataque, la primera llave fue PHP2Shell.

Según el equipo de investigación de la propia empresa, Check Point Research, un atacante encadenó las dos fallas desde el 30 de octubre de 2026: entró por el portal de acceso remoto Mobile Access de firewalls sin parchear, subió a root e instaló puertas traseras. En la primera oleada borró datos en algunas organizaciones de Israel, y en la intrusión que investigó la empresa el atacante saltó además a un servidor de virtualización. Check Point dijo que vio explotación activa contra «un par de docenas» de clientes, según BleepingComputer.

Qué hacer hoy: si en tu empresa hay un firewall o una consola de administración de Check Point, el paso es instalar el hotfix que publicó la empresa y revisar si el equipo muestra indicios de ataque. Si lo administra un proveedor de IT, preguntale hoy si ya lo aplicó y si usan el portal Mobile Access. Si el hotfix no se puede instalar en el acto, Check Point propone una mitigación temporal: detener el proceso dynamic_server e impedir que vuelva a arrancar. Si no tenés nada de Check Point, esta falla no te alcanza, aunque PHP2Shell sí puede alcanzar a tu sitio web, como explicamos más abajo.

Qué corrigió Check Point

La ficha oficial de la vulnerabilidad, cargada por Check Point como autoridad del CVE y publicada en la base NVD el 12 de noviembre a las 14:17 UTC, describe el problema en dos líneas: el servicio DynamicCLI de Gaia corre como root y escucha en un socket local (/tmp/dynamic_socket) en el que cualquier proceso puede escribir, sin comprobar quién se conecta. Cualquier usuario local autenticado puede mandarle una orden a ese socket y conseguir que se ejecute con todos los permisos.

Check Point le asignó 7,8 sobre 10 en la escala CVSS, gravedad «alta». No llega a «crítica» porque exige acceso local y algún permiso previo. Según The Hacker News, Check Point lo dice sin vueltas: es una escalada local de privilegios que requiere que el atacante «ya tenga ejecución de código local en el equipo».

La ficha del CVE enumera dos productos, Quantum Security Gateway y Quantum Security Management, y cuatro versiones afectadas según el Jumbo Hotfix que tengan, que es el paquete acumulativo de parches de Check Point, numerado por «Take». Un equipo sin ningún Jumbo Hotfix también queda afectado.

Según BleepingComputer y The Hacker News, la lista de productos afectados es más amplia que la de la ficha. BleepingComputer nombra el Firewall, Multi-Domain Security Management Server, Scalable Platforms, Security Gateway y Security Management Server, y The Hacker News suma los servidores de administración y de registros, Multi-Domain Log Server y Maestro Orchestrator. Por eso conviene leer el aviso oficial antes de dar un equipo por fuera: la tabla de arriba no es la lista final.

Cómo fue el ataque, paso a paso

El informe que Check Point Research publicó el 12 de noviembre reconstruye una intrusión completa. La cadena tiene cuatro tramos:

• La entrada: el portal Mobile Access, la página web con la que los empleados se conectan a la red de la empresa desde afuera. Ahí el atacante usó PHP2Shell, el nombre que recibieron las fallas CVE-2026-109618 y CVE-2026-109619 de PHP. Check Point dice que la actividad empezó «aproximadamente una semana después» de que hubiera un arreglo de seguridad disponible: los equipos atacados eran los que todavía no lo tenían.
• La escalada: desde la cuenta de servicio del portal, que tiene permisos limitados, el atacante subió a root con la CVE-2026-123039.
• La permanencia: con permisos totales instaló webshells en PHP, que son páginas que le permiten dar órdenes al equipo desde el navegador, y una puerta trasera persistente que Check Point llama TSGA, con un componente de red llamado TSProxy.
• El daño: en la intrusión investigada, el atacante saltó por SSH, el acceso remoto por consola, del firewall a un servidor VMware ESXi (el software que hace correr las máquinas virtuales de una empresa). Ahí instaló un programa de borrado llamado destroy_v6 y dejó notas de contenido político con el nombre DREAM_ANNEXATION.txt.

Hubo dos oleadas, y no se parecen. La primera, el 30 de octubre, apuntó a organizaciones israelíes e incluyó borrado de datos en algunas. La segunda, el 2 de noviembre, fue una ola de escaneo más amplia: apuntó a organizaciones de varios países y sectores, entre ellas algunas israelíes que ya habían estado en la mira, y Check Point no encontró evidencia de borrado. Como ninguna de las dos mostró preferencia por un sector, la empresa lo interpreta como intentos oportunistas de conseguir acceso, no como una cacería dirigida a una industria. Traducido: el que tenía el portal expuesto y sin parchear estaba en la lista, se dedicara a lo que se dedicara.

Quién está detrás, y por qué nadie lo firma

Acá el informe de Check Point Research es prudente, y conviene respetar esa prudencia. TSGA y TSProxy son variantes modificadas de PhiliKit, un conjunto de herramientas que ya se había visto en ataques contra equipos de Ivanti y con el que comparten código, configuración y material criptográfico. La empresa de seguridad ESET asoció PhiliKit con UNC5221, un grupo vinculado a China. Pero Check Point no da ese salto:

«La evidencia no nos permite evaluar con un nivel alto de confianza la verdadera naturaleza de esta operación. Siguen siendo plausibles varios escenarios: que el actor identificado haya llevado adelante toda la campaña, que haya actuado solo como intermediario de acceso inicial o que haya participado en una operación de bandera falsa. También es posible que la actividad destructiva haya servido como cortina de humo.»Check Point Research, 12 de noviembre de 2026 (traducción propia)

Hay un dato más que enreda la historia. La nota que dejó el programa de borrado usa la marca de Dream Security, una empresa que poco antes había publicado una investigación sobre la explotación de PHP2Shell en equipos de Palo Alto Networks por parte de actores vinculados a China. Check Point reconoce que esa coincidencia de fechas abre la posibilidad de una represalia, pero aclara que la evidencia disponible no establece un motivo claro. Para el que administra el firewall, el nombre del culpable cambia poco: el agujero es el mismo.

Por qué esto le importa a una pyme

Porque el firewall es la puerta de la oficina. Es el equipo por el que pasa todo el tráfico entre la red de la empresa e internet, y el portal de acceso remoto es, por diseño, la parte que queda mirando hacia afuera. Quien toma el control del firewall como root no entra a una computadora: se para en el pasillo por el que pasa todo. Y en el caso que investigó Check Point, de ahí saltó a los servidores donde corren las máquinas virtuales de la empresa.

Las fuentes no dan países fuera de Israel ni cifras por región, así que no hay datos para decir que el ataque llegó a América Latina. Lo que sí está escrito es que la segunda oleada apuntó a organizaciones de varios países sin preferencia de sector. Si tu empresa tiene un equipo de Check Point con el portal Mobile Access publicado en internet, la pregunta vale igual.

Tampoco es un rayo en cielo despejado. PHP2Shell se explota desde octubre: el 21 de ese mes, el proyecto PHP publicó las versiones que corrigen las dos fallas, y el 26, CISA, la agencia de ciberseguridad de Estados Unidos, las sumó a su catálogo de vulnerabilidades explotadas. Ya contamos qué hacer si tu sitio WordPress corre sobre PHP. Lo que se conoció esta semana es que las mismas fallas aparecieron como puerta de entrada en firewalls, que no son un sitio web pero tienen un portal web adentro.

Y Check Point viene de un año movido. Según BleepingComputer, en septiembre la empresa ya había avisado de otras dos fallas críticas, una en Security Management Server (CVE-2026-93616) y otra en Security Gateway (CVE-2026-85102), explotadas como zero-day y sin necesidad de permisos previos. El mismo medio cuenta que en los últimos dos años CISA agregó cinco fallas de Check Point a su catálogo de explotadas, dos de ellas usadas por bandas de ransomware.

Qué hacer según quién seas

Si administrás equipos de Check Point:

• Instalá el hotfix que corresponde a tu versión, siguiendo el aviso sk1000362. Comparalo contra la tabla de arriba, pero no te quedes solo con ella: según BleepingComputer y The Hacker News, hay más versiones y productos afectados que los que nombra la ficha del CVE.
• Si hoy no podés instalarlo, la mitigación temporal que propone Check Point, según BleepingComputer, es detener el proceso dynamic_server e impedir que se reinicie. Es un parche de emergencia, no un reemplazo del hotfix.
• Revisá el portal Mobile Access. Fue la puerta de entrada en este ataque: confirmá que tenga aplicada la corrección de PHP2Shell, no solo el hotfix de esta semana.
• Buscá indicios de ataque. Check Point publicó indicadores de compromiso en su informe y, según BleepingComputer, recomienda buscar comandos asociados a la explotación, el uso de la función system(), que es rara o inexistente en el tráfico legítimo, y comandos que no pasan por el intérprete Clish habitual, porque eso indica que se ejecutaron como root a través del socket.
• Si encontrás algo, no te quedes en el firewall. En la intrusión que investigó Check Point, el atacante saltó a un servidor VMware ESXi por SSH. Revisá también lo que el firewall puede alcanzar, y conservá la evidencia antes de reinstalar nada.

Si el firewall te lo maneja un proveedor de IT:

• Preguntale si el equipo es Check Point, si tiene el portal Mobile Access publicado, si ya instaló el hotfix de la CVE-2026-123039 y, si es un Quantum Spark, la línea para pymes, si el aviso lo alcanza. Entra todo en un mensaje.
• Pedile que te confirme si revisó los indicios de ataque, no solo si actualizó. Un hotfix cierra la falla, pero no saca una puerta trasera que ya esté instalada.
• Si te contesta que el equipo estuvo expuesto desde fines de octubre sin parches, lo razonable es pedirle una revisión completa, incluidos los servidores que dependen del firewall.

Lo que todavía no se sabe del zero-day de Check Point

Al cierre de esta nota no está claro quién está detrás, como contamos más arriba. Tampoco se sabe cuántas organizaciones terminaron comprometidas: el aviso habla de explotación activa contra «un par de docenas» de clientes, sin decir en cuántas tuvo éxito. No se sabe a qué países pertenecen las organizaciones apuntadas en la segunda oleada, si hubo compromisos en ella ni si hay casos en América Latina. Las fuentes que leímos no aclaran si los equipos Quantum Spark están alcanzados; si tenés uno, consultalo en el aviso o con tu proveedor. Cuando consultamos las fuentes oficiales, el 13 de noviembre a las 11:10 UTC, la ficha del CVE en NVD seguía «a la espera de análisis» y CISA todavía no la había sumado a su catálogo de vulnerabilidades explotadas. Si cambia algo de lo que contamos acá, lo vamos a actualizar.

Fuentes

• Check Point Research, «PHP2Shell Exploitation on Check Point Gateway», 12 de noviembre de 2026.
• NVD (NIST), ficha de CVE-2026-123039, cargada por Check Point y publicada el 12 de noviembre de 2026.
• Check Point, aviso sk1000362 sobre CVE-2026-123039.
• BleepingComputer, «Check Point warns of zero-day flaw exploited for root access», de Sergiu Gatlan, 13 de noviembre de 2026.
• The Hacker News, «Hackers Exploit PHP2Shell Flaws in Check Point Gateways to Deploy TSGA Backdoor and Wipe ESXi Files», de Ravie Lakshmanan, 13 de noviembre de 2026.
• CISA, catálogo de vulnerabilidades explotadas conocidas, consultado el 13 de noviembre de 2026.
• Créditos de imagen: fotomontajes editoriales asistidos por IA con el logo de Check Point tomado de su sala de prensa oficial.

¿Ya le preguntaste a tu proveedor por tu firewall? Contanos cómo te fue, sin datos de tu red ⬇️