cPGuard: un canal de actualización secuestrado instaló una puerta trasera en unos 2950 servidores Linux

OPSSHIELD, fabricante de la suite de seguridad para servidores cPGuard, afirma que un atacante entró en su servidor de facturación y publicó una actualización falsa con una clave robada el 2 de noviembre de 2026. Durante unos 70 minutos, el script se ejecutó como root en servidores Linux de clientes, instaló un shell oculto y copió hashes de contraseñas, claves SSH y credenciales de bases de datos.

Qué ha pasado

OPSSHIELD publica cPGuard, una suite de seguridad (antimalware, cortafuegos, cortafuegos de aplicaciones web) instalada en servidores Linux de alojamiento web. El 3 de noviembre de 2026, la empresa reconoció que su canal de actualización había sido secuestrado. Según su informe del incidente, el atacante registró el 1 de noviembre una cuenta de cliente con una identidad falsa, pidió una licencia de prueba gratuita y explotó un fallo de la aplicación de facturación para ejecutar comandos en el servidor de facturación y licencias. Desde allí, con una clave de acceso robada, subió una actualización falsa de cPGuard al almacenamiento de actualizaciones el 2 de noviembre, poco después de las 02:00 UTC.

A quién afecta

Los agentes de cPGuard instalaron la actualización falsa entre las 02:08 y las 03:20 UTC del 2 de noviembre, una ventana de unos 70 minutos. El script se ejecutó como root, dejó un shell oculto y envió al atacante archivos sensibles: /etc/shadow y /etc/passwd, las claves SSH de root, authorized_keys y known_hosts, la contraseña root de MySQL de /root/.my.cnf, el historial del shell de root y, en algunos servidores, claves S3 de /root/.s3cfg. OPSSHIELD calcula que unos 2950 servidores de clientes lo ejecutaron. Además, quedaron expuestos los datos de unas 7900 cuentas del portal de facturación (nombre, empresa, dirección postal, correo, hashes bcrypt de contraseñas). El aviso menciona las versiones 5.88.12 a 5.88.19.

Qué hacer ahora

1. Actualice cada servidor con cpgcli update --start y compruebe con cpgcli --version: OPSSHIELD exige al menos la 5.88.25, y la 5.88.26 revoca además su acceso de soporte.
2. Revise el historial con grep 'Successfully updated' /opt/cpguard/logs/install_log. Una versión entre 5.88.12 y 5.88.19, o un cPGuard activo durante la ventana, obliga a considerar el servidor comprometido.
3. Busque y elimine /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/, /etc/cron.d/i93677 y /var/tmp/.i93677/, y busque la dirección IP 94.183.188.91 en sus registros.
4. Cambie la contraseña de root y las de todas las cuentas locales, así como cualquier contraseña reutilizada en otro sitio.
5. Sustituya las claves SSH de root, retire las claves públicas antiguas de todos los servidores que confiaban en ellas y revise authorized_keys.
6. Renueve las contraseñas de MySQL y de las bases de datos, las claves S3 y cualquier token o contraseña del historial del shell de root.
7. Cambie la contraseña del portal de OPSSHIELD y active la autenticación en dos pasos, aunque sus servidores no se hayan visto expuestos.
8. Si detecta indicios de acceso manual, reconstruya el servidor desde una copia de seguridad anterior al 1 de noviembre.

Nuestra opinión

Un agente de seguridad que se actualiza como root es una vía directa hacia cada servidor que protege: la infraestructura de su fabricante pasa a formar parte de su superficie de ataque. Inventaríe estos agentes, sepa de dónde vienen sus actualizaciones y no deje secretos en el historial del shell ni en archivos de root que un solo script puede recoger.

Fuentes

• OPSSHIELD — cPGuard security advisory: update channel compromise
• OPSSHIELD — Security incident disclosure
• OPSSHIELD — cPGuard changelog
• The Hacker News — cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

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