cPGuard sufrió un ataque a su actualizador y expuso secretos de servidores

OPSSHIELD confirmó que un atacante secuestró el canal de actualización de cPGuard y distribuyó un script malicioso en las versiones 5.88.12 a 5.88.19. La actividad ocurrió el 2 de noviembre: el proveedor sitúa la publicación del paquete falso alrededor de las 02:06 UTC y su ejecución en servidores entre las 02:08 y las 03:20 UTC. El script corría con privilegios de administrador y recopilaba credenciales y ficheros sensibles.

La empresa afirma que la intrusión quedó contenida y recomienda actualizar a cPGuard 5.88.26 o posterior, la versión que su divulgación más reciente identifica como limpia. BleepingComputer publicó, citando al proveedor, que 2.946 servidores resultaron afectados; la nota de OPSSHIELD redondea la cifra a unos 2.950. La diferencia no cambia la decisión operativa: quien instaló una versión comprometida debe tratar sus secretos como expuestos.

-InfraCrew dice: cuando el actualizador del producto de seguridad queda bajo control ajeno, la ventana de exposición ya no depende de que el firewall “parezca tranquilo”.-

El riesgo estaba en la cadena de confianza

cPGuard se despliega en servidores Linux de hosting junto a paneles como cPanel, DirectAdmin y Plesk. El problema no fue una vulnerabilidad anunciada en el producto y luego explotada desde Internet: el atacante accedió a la infraestructura de publicación de OPSSHIELD con credenciales comprometidas y usó el canal de actualización para entregar código que los agentes instalaron como parte de un flujo legítimo.

El proveedor sitúa la primera distribución el 2 de noviembre y describe una ventana aproximada de setenta minutos para servir el falso paquete. Las comprobaciones automáticas se ejecutan a intervalos, por lo que la versión afectada en el historial acredita que un servidor recibió una actualización comprometida, pero no prueba por sí sola qué instrucciones llegaron a ejecutarse. A la inversa, la ausencia de una línea en un registro incompleto tampoco basta para demostrar que el equipo quedó fuera.

Qué datos pueden haber salido

Según la investigación publicada por OPSSHIELD, el script buscó hashes de cuentas locales, ficheros de SSH del usuario root, configuración de MySQL o MariaDB, historial de comandos privilegiados y claves de almacenamiento S3 en los equipos donde existían. El material recopilado se envió a un servidor de licencias de la propia compañía bajo una cuenta que el atacante pudo usar para recuperarlo. El proveedor dice que, además de las máquinas de clientes, también se copiaron registros de cuentas de su portal de facturación.

Las fuentes no permiten afirmar que todos los archivos enumerados se copiaran de cada servidor afectado. OPSSHIELD estima que alrededor de 2.950 equipos ejecutaron el paquete malicioso; BleepingComputer recogió una cifra más precisa de 2.946 y explica que el proveedor aún estaba delimitando la información extraída. Es una estimación del incidente, no una lista pública de hosts comprometidos.

-InfraCrew dice: “la actualización terminó bien” describe el instalador; no responde a la pregunta incómoda de si las claves ya salieron.-

Actualizar no invalida credenciales robadas

La primera acción es comprobar el historial de cPGuard y confirmar que cada servidor usa una versión 5.88.26 o posterior, siguiendo la última indicación del proveedor. La versión correctiva elimina el backdoor conocido y los archivos que dejó el script. Eso limpia artefactos identificados; no revoca una contraseña, una clave SSH, una credencial de base de datos o un token que el atacante haya copiado antes.

Si el registro muestra cualquiera de las versiones 5.88.12–5.88.19, la organización debería tratar el servidor como potencialmente comprometido, actualizarlo y rotar las credenciales accesibles desde root: cuentas locales, llaves SSH, base de datos y secretos de servicios cloud que estuvieran en los archivos o historiales afectados. Las llaves reemplazadas también deben retirarse de los sistemas que confiaban en ellas; cambiar el secreto solo en el origen deja viva la copia distribuida.

Conviene revisar las conexiones administrativas que salían desde esas máquinas y cualquier indicio adicional de persistencia, sin interpretar la limpieza del actualizador como prueba de que el resto del host esté íntegro. OPSSHIELD mantiene abierta la investigación sobre el acceso inicial y el alcance por cliente. Las recomendaciones pueden cambiar con nueva evidencia; la decisión de reconstruir un servidor debe basarse en señales y evaluación del host, no en que el paquete 5.88.26 se instalara correctamente.

-InfraCrew dice: una clave privada que ya fue copiada no vuelve a ser privada porque desaparezca el fichero del disco.-

Diccionario de la Crew

Canal de actualización — Servicio que distribuye nuevas versiones del software a los equipos instalados.

Root — Cuenta privilegiada de Linux con capacidad de administrar todo el sistema.

Backdoor — Mecanismo que permite mantener acceso no autorizado a un equipo.