cPGuard update channel hijacked to backdoor Linux servers

An attacker compromised the update channel of cPGuard, a Linux server security tool from OPSSHIELD, and used it to push a malicious script to customer servers. The script installed a backdoor and collected password hashes, database credentials, and SSH keys. Per the vendor's advisory, the intrusion began November 2 at 02:06 UTC using compromised credentials to reach the update CDN. The fix is in cPGuard 5.88.25.

What's affected

The malicious update shipped in cPGuard 5.88.12 through 5.88.19. OPSSHIELD says it detected the compromise within about 12 hours of those versions going out. It has not said how many servers installed an affected version or ran the script.

Running an affected version means the script was delivered. Whether it executed is a separate question — see detection below.

What the script did

On servers that ran it, the script collected:

• /etc/shadow and /etc/passwd
• root's MariaDB/MySQL config (my.cnf)
• root's shell history
• root's SSH authorized_keys and known_hosts

It uploaded the data to an OPSSHIELD licensing server through a compromised account. OPSSHIELD estimates the attacker retrieved 32 files, each tied to one customer server — a preliminary count of confirmed retrievals, not the total exposure. It notes it may not have collected every file from every server.

Indicators of compromise

OPSSHIELD published these artifacts (quoted verbatim from the advisory):

cpguard-v58812-i91511.sh      malicious script
/var/tmp/.cpg91511_sh         backdoor shell (removed by the update)
/var/tmp/.cpg91511            collection directory (removed by the update)
/var/tmp/.cpg91511/loot.tgz   staged archive of collected data

The absence of these files after the 5.88.25 cleanup does not prove the script never ran. To check the update history:

grep 'Successfully updated' /opt/cpguard/logs/install_log

Any entry for 5.88.12 through 5.88.19 means the server installed an affected update.

Action checklist

1. Run cpgcli update --start on every cPGuard server, then confirm cpgcli --version reports 5.88.25 or later.
2. If the script ran or may have run, treat the host as compromised: reset root and all password-enabled local account passwords from a trusted recovery environment.
3. Rotate database passwords, S3 access keys, DigitalOcean tokens, and any secret that appeared in root's shell history.
4. Replace SSH private keys under /root/.ssh and remove the old public keys from every system that trusts them. The update removes the backdoor, not credentials the attacker already copied.

Context

This is the same failure mode that keeps recurring: a vendor's own update or release channel becomes the delivery mechanism. We covered it when AOMEI's update server was used to push a signed backdoor (AOMEI Backupper, UNC7017). The uncomfortable part of cPGuard is the product category — a tool bought to harden servers ran as root everywhere and became the single point that collected every box's secrets at once. OPSSHIELD is also pushing a precautionary update to remove its support-access keys from servers where they were added; it has not said whether the matching private key was exposed.