Pasarelas Check Point atacadas mediante PHP2Shell: el fabricante confirma ataques, una puerta trasera y un borrador

Vigilancia cibernética de Top-Secured: análisis independiente basado en las fuentes citadas más abajo. Top-Secured no está afiliado a las empresas mencionadas y nunca le pedirá sus datos bancarios ni sus contraseñas.

Check Point afirma que unos atacantes explotaron los fallos PHP2Shell del portal Mobile Access de pasarelas sin parchear y después un segundo fallo para convertirse en root. En algunos objetivos instalaron una puerta trasera y saltaron a hosts VMware ESXi para destruir archivos.

Qué ha pasado

El 12 de noviembre de 2026, Check Point Research publicó un análisis de ataques contra los propios cortafuegos del fabricante. Los atacantes usaron PHP2Shell (CVE-2026-109618 y CVE-2026-109619), dos fallos de PHP que Check Point puntúa con 9,2 sobre 10 y que trató para sus pasarelas en un boletín publicado por primera vez el 21 de octubre. La actividad empezó una semana después de que el parche estuviera disponible, así que solo se vieron afectadas pasarelas sin actualizar. Una primera oleada, el 30 de octubre, apuntó a organizaciones israelíes, con destrucción en algunas; una segunda, el 2 de noviembre, alcanzó a organizaciones de varios países y sectores, sin destrucción observada. Check Point no da una cifra de víctimas; su boletín sobre el segundo fallo menciona explotación activa en un par de decenas de clientes.

Cómo entraron los atacantes

La puerta de entrada fue el portal Mobile Access expuesto a Internet. Una vez dentro, los atacantes usaron la CVE-2026-123039, un fallo local del servicio DynamicCLI, para obtener privilegios de root. Dejaron webshells en las plantillas del portal, una puerta trasera que sobrevive a los reinicios, una biblioteca que actúa como proxy de red y un escáner. Desde algunas pasarelas se conectaron por SSH a hosts VMware ESXi y ejecutaron allí un borrador para Linux. Check Point ve coincidencias con herramientas asociadas a un grupo vinculado a China, pero dice no poder determinar con seguridad la verdadera naturaleza de la operación.

Qué hacer ahora

  1. Parchee: Jumbo Hotfix Accumulator Take 14 o posterior en R82.20, Take 52 en R82.10, Take 132 en R82, Take 174 en R81.20, o el hotfix independiente de la sk1000302 (requiere reinicio). Spark: R82.00.11 build 998002843 o R81.10.17 build 996005005 y posteriores. Compruebe el Take instalado con cpinfo -y all.
  2. En R81.10 y anteriores (sin soporte), planifique una actualización: no hay corrección prevista para la CVE-2026-123039.
  3. Si no puede parchear de inmediato, aplique la mitigación manual de la sk1000302 y detenga dynamic_server como indica la sk1000362.
  4. Busque indicios de compromiso, incluso después de parchear: /tmp/CPconfigdaemon, /lib/libcpfwcommon.so, archivos zz*.tpl en las plantillas del portal, un servicio escuchando en TCP 11072 (netstat -tlnp) y las direcciones IP publicadas por Check Point.
  5. Si encuentra algo, reinstale la pasarela, renueve sus secretos y certificados VPN y revise los hosts ESXi a los que puede llegar.

Nuestra opinión

Un cortafuegos también es un servidor, y sus portales web usan las mismas bibliotecas que cualquier sitio. Una semana entre parche y ataque ya es lo habitual: los equipos perimetrales necesitan el mismo plazo de actualización que el servidor web más expuesto, y su acceso de administración a los hipervisores debe cortarse.

Fuentes

Cómo elegimos, verificamos y redactamos nuestros análisis →

¿Está expuesto su propio servidor? Haga una prueba gratuita, solo con información pública y sin intrusión:

Comprobar un servidor Comprobar un sitio

¿Le preocupa que sus servidores estén expuestos? Nuestro equipo audita, parchea y supervisa infraestructuras Linux y cloud 24/7.

Hablar con un experto Nuestros servicios de servidores gestionados →