cPGuard: aggiornamento dirottato, backdoor su 2.950 server

Cosa è successo

Il 2 novembre 2026, fra le 02:04 e le 02:09 UTC, un attaccante ha usato una chiave di pubblicazione rubata per caricare uno script malevolo attraverso il canale con cui cPGuard distribuisce gli aggiornamenti. Lo script installava una backdoor (un accesso nascosto al server) e raccoglieva file sensibili. Le versioni coinvolte sono dalla 5.88.12 alla 5.88.19.

OPSSHIELD ha ricostruito l'intera catena nella sua divulgazione ufficiale: il 1° novembre l'attaccante ha registrato un account cliente falso con una prova gratuita, l'ha installata su un proprio server per studiare come l'agente comunica col sistema di licenze, poi (dopo essere stato bloccato due volte da cPGuard) ha inviato richieste costruite ad hoc alle pagine di callback del portale di fatturazione e ha ottenuto l'esecuzione di comandi sul server di fatturazione e licenze. Da lì ha rubato la chiave di aggiornamento usata il giorno dopo. La richiesta esatta che gli ha dato accesso non è nei log: OPSSHIELD sta verificando il codice e i componenti di terze parti del portale.

Gli agenti cPGuard hanno installato il falso aggiornamento come root tra le 02:08 e le 03:20 UTC del 2 novembre, copiando i file sensibili verso l'attaccante. OPSSHIELD ha rilevato il problema entro 12 ore, revocato la chiave rubata e pubblicato lo stesso giorno la 5.88.25, la versione che toglie la backdoor; poco dopo è uscita anche la 5.88.26, che in più revoca le chiavi di supporto OPSSHIELD dai server dove erano state aggiunte.

Cosa è stato rubato

Dai circa 2.950 server clienti che hanno eseguito il falso aggiornamento sono stati raccolti: gli hash delle password di Linux (da /etc/shadow e /etc/passwd), i file SSH di root (l'amministratore), la configurazione root di MySQL o MariaDB e la cronologia dei comandi di root. Su un numero ridotto di server è stato letto anche /root/.s3cfg, con le chiavi di accesso S3. Un hash è la password trasformata in una sequenza di caratteri: non è la password, ma può essere attaccato per ricavarla, soprattutto se semplice o già vista altrove.

L'attaccante ha anche ottenuto l'accesso al portale di fatturazione (manage.opsshield.com) e a tre server cloud interni di OPSSHIELD (non server di clienti). Dal portale sono stati esposti i dati di circa 7.900 account: nome, azienda, indirizzo postale, email e la password in forma di hash bcrypt (nessuna password in chiaro). OPSSHIELD sta riemettendo le chiavi di licenza di cPGuard, perché alcune copie potrebbero essere in mano all'attaccante.

Cosa fare se hai cPGuard

Istruzioni dell'avviso ufficiale OPSSHIELD. Un server è esposto solo se cPGuard era installato e online fra le 02:08 e le 03:20 UTC del 2 novembre; se non lo era, il falso aggiornamento non è arrivato, ma la password del portale va comunque cambiata.

1. Controlla i log con grep 'Successfully updated' /opt/cpguard/logs/install_log: una voce dalla 5.88.12 alla 5.88.19 significa server da considerare compromesso, anche se ora è aggiornato. Un log assente o incompleto non esclude la compromissione.
2. Prima di aggiornare, controlla se sono presenti: /etc/cron.d/i93677, /var/tmp/.i93677/, /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/ (contiene l'archivio loot.tgz dei dati raccolti). L'aggiornamento toglie backdoor e archivio, ma OPSSHIELD non specifica se tolga anche il lavoro programmato in /etc/cron.d/i93677 e la cartella /var/tmp/.i93677/: ricontrollali dopo l'aggiornamento ed eliminali a mano se ci sono ancora. In ogni caso, non trovarli non prova che il server sia pulito: guardali prima di aggiornare.
3. Aggiorna con cpgcli update --start e controlla la versione con cpgcli --version: deve risultare 5.88.25 o successiva (se puoi, vai almeno alla 5.88.26, che toglie anche le chiavi di supporto OPSSHIELD dal server).
4. Se il server era online nella finestra indicata o hai trovato i file del punto 2, trattalo come compromesso: da un ambiente di recupero fidato (non dal server stesso, che potrebbe essere ancora sotto controllo dell'attaccante) cambia le password di root e di tutti gli utenti locali, la password root di MySQL/MariaDB e le password dei database, ruota le chiavi S3 e i token (es. DigitalOcean) presenti nella cronologia della shell, sostituisci le chiavi SSH private di root e rimuovi le vecchie chiavi pubbliche da authorized_keys ovunque fossero accettate. Cambia anche ogni password uguale usata altrove: un hash rubato può essere decifrato, e chi ci riesce prova la stessa password su altri account.
5. Se OPSSHIELD ti segnala un accesso manuale dell'attaccante sul tuo server, o se non riesci a stabilire che sia integro, ripristina da un backup precedente al 1° novembre: OPSSHIELD non consiglia la reinstallazione completa di routine, solo in questi casi.
6. In ogni caso, anche se il server non era online nella finestra a rischio, cambia subito la password del portale manage.opsshield.com e attiva l'autenticazione a due fattori: il portale è stato comunque violato.

Cosa non si sa

Fonti lette per intero: l'avviso di sicurezza e la Security Incident Disclosure pubblicati da OPSSHIELD (fonte primaria, 3 novembre 2026), oltre a BleepingComputer e The Hacker News (3 novembre, aggiornata il 4), che riprendevano le prime comunicazioni dell'azienda.

Non risulta nemmeno nella fonte ufficiale: chi sia l'attaccante, quale richiesta esatta alle pagine di callback del portale gli abbia dato accesso (i log non la registrano), e se fra i 7.900 account di fatturazione o i 2.950 server ci siano clienti italiani.