Un binario de Control Web Panel con una puerta trasera y un canal de actualizaciones de cPGuard secuestrado son incidentes distintos. Esto es lo que significa cada uno para los administradores de hosting.
Dos incidentes que afectan a entornos de hosting Linux
A principios de noviembre de 2026, investigadores y proveedores revelaron dos incidentes de seguridad distintos relacionados con herramientas que se usan para administrar y proteger servidores de hosting Linux. El 5 de noviembre, QiAnXin XLab publicó una investigación sobre CWPdoor, una puerta trasera (backdoor) integrada en un binario modificado del servidor web cwpsrv que usa Control Web Panel (CWP). Por otra parte, OPSSHIELD reveló el 3 de noviembre que un atacante había entrado en parte de su infraestructura y había usado el canal de actualizaciones de cPGuard para distribuir una actualización maliciosa el 2 de noviembre.
| Incidente | Vía de ataque | Impacto en la seguridad |
|---|---|---|
| CWPdoor | Un script similar a un actualizador, proporcionado por el atacante, sustituye cwpsrv por un binario troyanizado | Ejecución remota de comandos oculta |
| cPGuard | Unas credenciales robadas de distribución de actualizaciones permiten que una actualización maliciosa llegue a los servidores de los clientes | Ejecución con privilegios de root, exposición de credenciales y persistencia |
Los incidentes no deben describirse como una sola campaña ni como un único canal de actualizaciones comprometido. XLab no ha establecido que se vulnerara la infraestructura oficial de actualizaciones del proveedor legítimo de CWP. XLab afirma que no sabe cómo llega el script a los servidores ni qué vulnerabilidad se utiliza. El incidente de cPGuard implicó una vulneración real del mecanismo de distribución de OPSSHIELD. Lo que ambos comparten es práctico: los dos llegan a un servidor a través de software que se ejecuta con privilegios elevados, por lo que la respuesta en cada caso es verificar el binario y, después, rotar todo lo que un proceso de root podía leer.
CWPdoor: el servidor web sigue funcionando mientras oculta una puerta trasera
CWP ofrece una interfaz de administración para el alojamiento de servidores. Su componente cwpsrv atiende el tráfico de administración. Según XLab, su Cyber Threat Insight and Analysis System capturó un script llamado cwpsrv_update.sh el 29 de junio de 2026. El script descarga un archivo llamado cwpsrv desde 136.0.141[.]71 y sustituye el archivo del mismo nombre en el sistema. XLab afirma que el script solo admite las versiones 1.24.0 y 1.15.10 de cwpsrv y que debe ejecutarse como root.
XLab describe el sustituto como una puerta trasera pasiva. Se comporta como un cwpsrv legítimo ante las solicitudes ordinarias y solo actúa ante una solicitud que lleve tres encabezados concretos, X-Ngx-Integrity-Time, X-Ngx-Integrity-Data y X-Ngx-Integrity-Sig. Si falla la comprobación de la marca de tiempo o de la firma, la solicitud sigue su curso como tráfico ordinario. XLab también afirma que la puerta trasera manipula el contexto de módulo de la solicitud para que el módulo de registro (logging) no la registre, y que el script restaura las marcas de tiempo de archivos y directorios y ejecuta history -d. La inferencia de TechiesJournal, no una afirmación de XLab, es que una puerta trasera así es difícil de detectar mediante comprobaciones de disponibilidad, porque el panel sigue funcionando.
XLab también informa de que un archivo llamado evidencia.tgz se subió a VirusTotal desde Brasil el 30 de septiembre de 2026. Contenía un archivo cwpsrv.suspeito que XLab identifica como CWPdoor, con cero detecciones, junto a una muestra que la mayoría de los proveedores identificaron como la puerta trasera Ebury. XLab concluye que existen víctimas reales y afirma que la relación entre Ebury y CWPdoor no está clara.
Según los datos de QiAnXin Hunter Platform citados por XLab, más de 340 000 instancias de CWP estuvieron expuestas a internet durante el último mes (XLab). Esa cifra mide la exposición, no infecciones confirmadas, y no establece cuántos sistemas recibieron el binario troyanizado.
Fuente: QiAnXin XLab, CWPdoor.
cPGuard: las actualizaciones de software de confianza se convirtieron en la vía de entrega
La divulgación de OPSSHIELD del 3 de noviembre indica que un atacante entró en su entorno de facturación y licencias el 1 y el 2 de noviembre, se llevó las claves usadas para publicar actualizaciones y subió una actualización falsa de cPGuard el 2 de noviembre. El proveedor afirma que los agentes de cPGuard la instalaron aproximadamente entre las 02:08 y las 03:20 UTC. No te bases en esa franja horaria para descartar un servidor. El aviso de OPSSHIELD muestra, en sus entradas de registro (logs) de ejemplo, versiones afectadas que se instalaron hasta las 12:46 del 2 de noviembre, e indica que un registro ausente o incompleto no demuestra por sí solo que un servidor no se viera afectado. Recomienda contactar con el soporte de OPSSHIELD si tienes dudas.
Según el proveedor, el script malicioso se ejecutó con privilegios de root, recopiló hashes de contraseñas, claves SSH, credenciales de MySQL y el historial del shell, y dejó atrás un shell de root oculto y una tarea programada. Las dos páginas de OPSSHIELD difieren sobre cómo entró el atacante. La divulgación indica que una cuenta de cliente registrada el 1 de noviembre condujo a la aplicación de facturación, y que la solicitud exacta no figura en sus registros. El aviso indica que se usaron credenciales comprometidas y que la forma en que se obtuvieron estaba en investigación.
| Observación notificada por el proveedor | Alcance |
|---|---|
| Servidores de clientes que ejecutaron la actualización maliciosa | Aproximadamente 2950 |
| Registros de cuentas del portal de facturación copiados | Aproximadamente 7900 |
| Versiones de actualización afectadas (aviso de OPSSHIELD) | De la 5.88.12 a la 5.88.19 |
OPSSHIELD afirma que las contraseñas de las cuentas de facturación se almacenaban como hashes bcrypt. Las cifras son hallazgos del incidente notificados por el proveedor, no una confirmación independiente de qué se exfiltró exactamente de cada servidor. El recuento de servidores también cambió: el primer aviso de OPSSHIELD estimó que el atacante recuperó 32 archivos recopilados y lo calificó de recuento preliminar de recuperaciones confirmadas, no del número de servidores afectados, mientras que su divulgación posterior cifra en unos 2950 los servidores que ejecutaron la actualización.
Fuentes: divulgación del incidente de OPSSHIELD (la más reciente) y aviso de OPSSHIELD (hallazgos anteriores).
Qué deben hacer los administradores de cPGuard
El aviso de OPSSHIELD indica que hay que ejecutar cPGuard 5.88.25 o posterior. Su divulgación posterior señala la 5.88.26 como la versión limpia y afirma que una actualización adicional elimina la tarea programada i93677. Actualiza a la versión más reciente y, después, confirma que los archivos indicados más abajo ya no están. El aviso enumera los pasos en este orden.
1. Comprueba el historial de actualizaciones. Una entrada de la 5.88.12 a la 5.88.19 significa que el servidor instaló una actualización afectada. OPSSHIELD afirma que esto confirma la instalación, no qué archivos se transfirieron, y que un servidor así debe tratarse como potencialmente comprometido aunque ahora ejecute la 5.88.25 o posterior.
grep 'Successfully updated' /opt/cpguard/logs/install_log2. Actualiza.
cpgcli update --start3. Verifica la versión. El aviso de OPSSHIELD pide la 5.88.25 o posterior e indica que hay que contactar con el soporte si la actualización falla.
cpgcli --version4. Confirma que los restos han desaparecido. La divulgación menciona /etc/cron.d/i93677, /var/tmp/.i93677/ y /var/tmp/.cpg91511_sh. El aviso añade /var/tmp/.cpg91511 y /var/tmp/.cpg91511/loot.tgz. OPSSHIELD afirma que la ausencia de estos archivos tras la limpieza no permite establecer si el script se ejecutó antes.
5. Rota las credenciales. Una actualización limpia no revoca las credenciales ya copiadas. OPSSHIELD pide a los administradores de servidores potencialmente afectados que:
- Restablezcan la contraseña de root y las de todas las cuentas locales, desde un entorno de recuperación de confianza según el aviso, y cambien desde un dispositivo de confianza las contraseñas reutilizadas en otros sistemas.
- Sustituyan las claves SSH de root y eliminen las claves públicas antiguas de
authorized_keysen todos los sistemas que confiaban en ellas. Traten como expuestos los demás servidores accesibles con esas claves hasta que se sustituyan las claves. - Cambien la contraseña de root de MySQL y las contraseñas de bases de datos almacenadas en
/root/.my.cnf. - Roten las contraseñas, claves de API y tokens que aparezcan en el historial del shell de root, además de las claves de
/root/.s3cfgy cualquier token de DigitalOcean (el aviso menciona ambos). - Restablezcan la contraseña del portal de facturación de OPSSHIELD y activen el inicio de sesión con dos factores. La divulgación pide el restablecimiento incluso cuando cPGuard estaba sin conexión durante esa franja horaria.
- Reconstruyan el servidor a partir de una copia de seguridad limpia realizada antes del 1 de noviembre solo si OPSSHIELD les comunicó que el atacante inició sesión manualmente en su servidor. En caso contrario, el aviso no recomienda una reconstrucción rutinaria y califica esa evaluación de provisional.
El artículo de TechiesJournal sobre qué se va con una configuración de firewall y qué hay que rotar aborda el mismo problema de rotación para otra clase de dispositivo. Su artículo sobre qué hacer después de aplicar el parche a un dispositivo explotado explica por qué un sistema con parche no es necesariamente un sistema limpio.
Qué deben hacer los administradores de CWP
XLab publica las siguientes comprobaciones del host. La primera busca el socket Unix ngx_http_integrity_helper que CWPdoor usa para la comunicación entre procesos.
ss -axp | grep integrity
ps aux | grep cwpsrv
strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-IntegrityPara el segundo comando, XLab indica que hay que buscar procesos hijo auxiliares (helper) sospechosos de cwpsrv. Para el tercero, indica que hay que buscar cadenas X-Ngx-Integrity sospechosas en el binario. Los equipos de red también pueden buscar en los registros del firewall y del proxy conexiones a 136.0.141[.]71, la dirección que XLab señala como servidor de descarga (downloader).
Si se confirma una infección, XLab recomienda tres pasos. Primero, sustituir el cwpsrv malicioso por la copia de seguridad legítima que el script del atacante creó en /usr/local/cwpsrv/bin, llamada cwpsrv.prev- seguida de una marca de tiempo. Segundo, actualizar a la versión más reciente y confirmar que ss -axp | grep integrity ya no devuelve ninguna coincidencia. Tercero, rotar de inmediato todas las credenciales del panel de control, tratarlas como comprometidas, y tratar el host como comprometido e investigarlo en busca de otras amenazas.
Ten en cuenta que XLab también afirma que el script elimina su copia de seguridad cuando la sustitución tiene éxito, por lo que ese archivo cwpsrv.prev- puede no existir. La inferencia de TechiesJournal es que un binario obtenido de una fuente de CWP de confianza es el sustituto más seguro. XLab pide tratar el host como comprometido, porque la puerta trasera puede ejecutar comandos arbitrarios, de modo que sustituir solo el binario no basta.
Fuente: QiAnXin XLab, CWPdoor.
Qué deben sacar en claro los administradores
CWPdoor demuestra cómo un ejecutable modificado puede ocultar un acceso remoto dentro de un software que aparentemente sigue funcionando. El incidente de cPGuard muestra el peligro distinto de que un atacante obtenga acceso a una vía legítima de distribución de actualizaciones. La respuesta práctica depende de qué incidente afectó al host: verificar los binarios instalados y el historial de actualizaciones, sustituir los componentes comprometidos, investigar la persistencia y rotar las credenciales expuestas.
Referencias
- QiAnXin XLab: investigación sobre CWPdoor, 5 de noviembre de 2026
- OPSSHIELD: divulgación del incidente (la más reciente), 3 de noviembre de 2026
- OPSSHIELD: aviso (hallazgos anteriores), 3 de noviembre de 2026
Las fuentes se consultaron el 12 de noviembre de 2026. OPSSHIELD indica que seguirá actualizando su divulgación, así que compruébala antes de actuar.