Control Web Panel: puerta trasera oculta en el servidor

El laboratorio XLab, de la firma china QiAnXin, publicó el 5 de noviembre de 2026 el hallazgo de «cwpdoor», una puerta trasera escondida dentro de cwpsrv, el servidor web de Control Web Panel (CWP). Afecta a servidores Linux con CWP en los que el atacante ya consiguió acceso de administrador (root). No se ve en los registros y se detecta con tres comandos.

Lo que se sabe

  • Qué es: según XLab, una copia de cwpsrv con código añadido. Funciona como el programa normal hasta que recibe una petición con unas cabeceras especiales firmadas; entonces ejecuta las órdenes del atacante. Esas peticiones no aparecen en los registros de acceso.
  • Versiones: XLab capturó dos muestras, para cwpsrv 1.15.10 y 1.24.0; el instalador solo admite esas dos.
  • Cómo llega: el instalador, un script que se hace pasar por una actualización de cwpsrv, tiene que ejecutarse como root. XLab dice que todavía no sabe qué fallo usan los atacantes para llegar hasta ahí.
  • Cómo se esconde: según XLab, el instalador devuelve al archivo sus fechas originales, así que `ls` y `stat` no muestran cambios.
  • Fechas: XLab capturó el instalador el 29 de junio de 2026. El 30 de septiembre alguien subió desde Brasil a VirusTotal un archivo con una copia de la puerta trasera, que ningún antivirus detectaba; para XLab eso indica que ya hay víctimas reales.
  • Cuántos: XLab no da una cifra de servidores infectados. Cita, con datos de su plataforma Hunter, más de 340.000 instalaciones de CWP visibles en internet en el último mes como posibles objetivos, no como afectadas.
  • Algo más en la misma muestra: el archivo de Brasil incluía también un componente que la mayoría de los antivirus identifican como Ebury, que The Hacker News describe como una puerta trasera de OpenSSH que roba credenciales. XLab no sabe si tiene relación con cwpdoor.
  • El fabricante: al publicarse el informe no había ninguna declaración de los desarrolladores de CWP.

Qué cambia y qué no

  • Cambia para quien tiene CWP en su VPS: hay una forma concreta, con comandos publicados, de saber si el panel fue manipulado.
  • No es un fallo nuevo de CWP que se arregle con un parche: es lo que un atacante deja instalado después de entrar como root. La pregunta de fondo es cómo entró.
  • No afecta, según lo publicado, a servidores sin Control Web Panel: el script solo sustituye el cwpsrv de CWP. Quien usa cPanel, Plesk u otro panel no tiene ese archivo.

Cómo saber si te afecta

Si tienes un VPS con Control Web Panel, entra por SSH como root y ejecuta los tres comandos que publica XLab:

  1. `ss -axp | grep integrity` — si aparece `ngx_http_integrity_helper`, el servidor está infectado. Según The Hacker News, en un caso fue la única señal: la lista de puertos abiertos parecía normal.
  2. `ps aux | grep cwpsrv` — busca procesos auxiliares que no esperas, lanzados por cwpsrv.
  3. `strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity` — si devuelve algo, el archivo lleva las cabeceras de la puerta trasera.

Además, `md5sum /usr/local/cwpsrv/bin/cwpsrv` y compara el resultado con las dos huellas publicadas por XLab: `965aea67fb40de1bab5169ada993349f` (1.15.10) y `d3f4e95113d49ab3991b45e457bda75b` (1.24.0). Si coincide, está infectado. Si no coincide, solo descarta esas dos muestras.

Si alguna prueba sale positiva, XLab recomienda:

  1. Recuperar el cwpsrv original desde la copia `cwpsrv.prev-<fecha>` en `/usr/local/cwpsrv/bin` (el instalador puede haberla borrado).
  2. Actualizar CWP a la última versión y repetir `ss -axp | grep integrity` hasta que no devuelva nada.
  3. Cambiar todas las contraseñas del panel y tratar el servidor entero como comprometido: quien instaló esto ya era root.

En la práctica, un servidor donde alguien fue root no se da por limpio solo con quitar un archivo. Lo prudente es copiar la web y la base de datos, revisar que no traigan código añadido y moverlas a un servidor nuevo.

Si las tres pruebas salen limpias: bien, pero no prueban que nadie haya entrado. Revisa también usuarios nuevos, claves en `authorized_keys` y conexiones hacia la dirección del servidor de descarga que publica XLab (136.0.141[.]71).

Si tu web está en un hosting que administra otro: pregunta a tu proveedor: «¿Mis servidores usan Control Web Panel? ¿Ya comprobaron cwpsrv contra el informe de XLab del 5 de noviembre?».

Relacionado: cPGuard: actualización con puerta trasera en servidores

Fuentes

Actualizaciones: si los desarrolladores de CWP responden o se conoce la vía de entrada, se añadirá aquí con su enlace.