cPGuard: actualización con puerta trasera en servidores

Lo que se sabe

• Cómo entró: según el aviso de OPSSHIELD, a las 02:06 UTC del 2 de noviembre un atacante accedió con credenciales robadas a la red desde la que la empresa distribuye sus actualizaciones. Desde ahí salieron las versiones 5.88.12 a 5.88.19.
• Qué hacía el script: el aviso dice que instalaba una puerta trasera y recogía archivos sensibles del servidor: las cuentas y contraseñas cifradas del sistema (/etc/shadow y /etc/passwd), la configuración de la base de datos de root (my.cnf), el historial de órdenes de root y los archivos de claves SSH de root.
• Adónde iba: según OPSSHIELD, el script subía esos datos a uno de sus propios servidores de licencias, usando una cuenta comprometida, y el atacante los recogía después.
• Cuántos: la estimación preliminar de la empresa es que el atacante se llevó 32 archivos, cada uno de un servidor de cliente. El aviso aclara que esa cifra no es el total de servidores que pudieron instalar las versiones afectadas.
• Cuándo se detectó: OPSSHIELD dice que lo detectó en menos de 12 horas desde la salida de las versiones afectadas, que borró las credenciales de su infraestructura y que cerró la cuenta comprometida.
• Lo que aún no se sabe: cómo consiguió el atacante las credenciales, qué datos salieron de cada servidor y si hubo más actividad maliciosa. La empresa dice que no ha encontrado más, pero que su evaluación es provisional.
• Claves de soporte: por precaución, OPSSHIELD publica una actualización que retira de los servidores las claves de acceso de su equipo de soporte donde se hubieran añadido.

Qué cambia y qué no

• Cambia para quien administra un servidor dedicado o un VPS con cPGuard instalado: si recibió una de esas versiones, el servidor debe tratarse como comprometido aunque ya esté actualizado.
• Actualizar no basta: según el aviso, la 5.88.25 quita la puerta trasera y los restos del script, pero eso no deshace lo que ya se llevó. Que esos archivos no estén después no prueba que el script no se ejecutara.
• Reinstalar no es la norma: OPSSHIELD no recomienda rehacer el servidor de cero como respuesta general. Si aparecen otras señales o no se puede asegurar que el servidor esté limpio, pide contactar con su soporte para valorarlo caso por caso.
• No cambia para quien no usa cPGuard. No es un fallo de WordPress, de Drupal ni del panel de hosting: es una actualización falsa de una herramienta concreta.

Cómo saber si te afecta

Si tienes un servidor o un VPS propio:

1. Mira si tienes cPGuard y qué versión. El aviso indica comprobarlo con `cpgcli --version`. Tiene que decir 5.88.25 o superior.
2. Actualiza ya. La orden que da el fabricante es `cpgcli update --start`. Si falla, pide ayuda a su soporte.
3. Mira si instalaste una versión afectada. El aviso propone buscar en el registro de instalación con `grep 'Successfully updated' /opt/cpguard/logs/install_log`. Si aparece cualquier versión entre la 5.88.12 y la 5.88.19, se instaló. Si el registro falta o está incompleto, eso no descarta nada.
4. Si se instaló, cambia todo lo que el script pudo leer. Desde un entorno de confianza: contraseñas de root y de las cuentas locales, contraseñas de las bases de datos, claves de almacenamiento y de API que aparezcan en el historial de root, y las claves SSH de root (y quita las públicas viejas de los equipos que confían en ellas). Así lo pide el aviso.
5. Después, revisa las webs del servidor. Si cambias la contraseña de una base de datos, actualiza también el archivo de configuración de cada web que la usa (wp-config.php en WordPress, settings.php en Drupal) o dejará de cargar.

Si tu web está en un hosting de otra empresa:

1. Pregunta por escrito: «¿Vuestros servidores usan cPGuard? ¿Alguno instaló las versiones 5.88.12 a 5.88.19 el 2 de noviembre? ¿Qué habéis cambiado desde entonces?».
2. Si la respuesta es sí, cambia lo tuyo: la contraseña del panel de hosting, la de FTP o SFTP y, con tu proveedor, la de la base de datos de tu web. Revisa también los usuarios administradores de tu WordPress o tu Drupal por si aparece alguno que no conoces.

Relacionado: Fallo crítico en el kernel Linux: qué revisar en tu servidor

Fuentes

• OPSSHIELD, «cPGuard Update Channel Compromise», 3 de noviembre de 2026 (en inglés)
• The Hacker News, 3 de noviembre de 2026 (en inglés)

Actualizaciones: si OPSSHIELD explica cómo se robaron las credenciales, cambia la cifra de servidores afectados o recomienda reinstalar, se añadirá aquí con su enlace.