cPGuard: un canale di aggiornamento dirottato ha installato una backdoor su circa 2.950 server Linux

OPSSHIELD, produttore della suite di sicurezza per server cPGuard, riferisce che un attaccante è entrato nel suo server di fatturazione e, con una chiave rubata, ha pubblicato un falso aggiornamento il 2 novembre 2026. Per circa 70 minuti lo script è stato eseguito come root sui server Linux dei clienti, ha installato una shell nascosta e ha copiato hash delle password, chiavi SSH e credenziali dei database.

Cosa è successo

OPSSHIELD pubblica cPGuard, una suite di sicurezza (antimalware, firewall, web application firewall) installata su server Linux di web hosting. Il 3 novembre 2026 l’azienda ha comunicato che il suo canale di aggiornamento era stato dirottato. Secondo il suo rapporto sull’incidente, l’attaccante ha registrato il 1° novembre un account cliente con un’identità falsa, ha richiesto una licenza di prova gratuita e ha poi sfruttato una falla dell’applicazione di fatturazione per eseguire comandi sul server di fatturazione e licenze. Da lì, con una chiave di accesso rubata, ha caricato un falso aggiornamento di cPGuard nello spazio di distribuzione il 2 novembre, poco dopo le 02:00 UTC.

Chi è coinvolto

Gli agenti cPGuard hanno installato il falso aggiornamento tra le 02:08 e le 03:20 UTC del 2 novembre, una finestra di circa 70 minuti. Lo script, eseguito come root, ha lasciato una shell nascosta e inviato all’attaccante file sensibili: /etc/shadow e /etc/passwd, le chiavi SSH di root, authorized_keys e known_hosts, la password root di MySQL in /root/.my.cnf, la cronologia della shell di root e, su alcuni server, le chiavi S3 di /root/.s3cfg. OPSSHIELD stima in circa 2.950 i server dei clienti coinvolti. Sono stati inoltre esposti i dati di circa 7.900 account del portale di fatturazione (nome, azienda, indirizzo postale, e-mail, hash bcrypt delle password). L’avviso indica le versioni dalla 5.88.12 alla 5.88.19.

Cosa fare ora

1. Aggiornate ogni server con cpgcli update --start e verificate con cpgcli --version: OPSSHIELD richiede almeno la 5.88.25, e la 5.88.26 revoca anche il proprio accesso di supporto.
2. Controllate la cronologia con grep 'Successfully updated' /opt/cpguard/logs/install_log. Una versione tra 5.88.12 e 5.88.19, o un cPGuard attivo durante la finestra, impone di considerare il server compromesso.
3. Cercate ed eliminate /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/, /etc/cron.d/i93677 e /var/tmp/.i93677/, e cercate l’indirizzo IP 94.183.188.91 nei log.
4. Cambiate la password di root e quelle di tutti gli account locali, oltre a ogni password riutilizzata altrove.
5. Sostituite le chiavi SSH di root, rimuovete le vecchie chiavi pubbliche da tutti i server che le accettavano e controllate authorized_keys.
6. Rinnovate le password di MySQL e dei database, le chiavi S3 e ogni token o password presente nella cronologia della shell di root.
7. Modificate la password del portale OPSSHIELD e attivate l’autenticazione a due fattori, anche se i vostri server non sono stati esposti.
8. In presenza di tracce di accesso manuale, ricostruite il server da un backup precedente al 1° novembre.

Il nostro parere

Un agente di sicurezza che si aggiorna come root è una via diretta verso ogni server che protegge: l’infrastruttura del suo produttore diventa parte della vostra superficie di attacco. Censite questi agenti, sappiate da dove arrivano i loro aggiornamenti e non lasciate segreti nella cronologia della shell o in file di root che un solo script può raccogliere.

Fonti

• 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

Come scegliamo, verifichiamo e scriviamo le nostre analisi →