cPGuard: a hijacked update channel pushed a root backdoor to about 2,950 Linux servers

OPSSHIELD, the vendor of the cPGuard server security suite, says an attacker broke into its billing server and used a stolen key to publish a fake update on 2 November 2026. For about 70 minutes, the script ran as root on customer Linux servers, planted a hidden shell and copied password hashes, SSH keys and database credentials.

What happened

OPSSHIELD, which publishes cPGuard, a security suite (malware scanner, firewall, web application firewall) installed on Linux web hosting servers, disclosed on 3 November 2026 that its update channel had been hijacked. According to its incident report, the attacker registered a customer account under a false identity on 1 November, ordered a free trial, then exploited a flaw in the billing application to run commands on the billing and licensing server. From there, a stolen access key let them upload a fake cPGuard update to the update storage on 2 November, shortly after 02:00 UTC.

Who is affected

cPGuard agents installed the fake update between 02:08 and 03:20 UTC on 2 November, a window of about 70 minutes. The script ran as root, dropped a hidden shell and sent sensitive files to the attacker: /etc/shadow and /etc/passwd, root SSH keys, authorized_keys and known_hosts, the MySQL root password in /root/.my.cnf, root shell history and, on a few servers, S3 keys in /root/.s3cfg. OPSSHIELD puts the number of customer servers that ran it at about 2,950. It adds that the details of around 7,900 billing portal accounts (name, company, postal address, e-mail, bcrypt password hashes) were exposed. Its advisory lists versions 5.88.12 to 5.88.19 as affected.

What to do now

1. Update every server with cpgcli update --start, then check with cpgcli --version: OPSSHIELD requires at least 5.88.25, and 5.88.26 also revokes its support access.
2. Check the update history with grep 'Successfully updated' /opt/cpguard/logs/install_log. A version between 5.88.12 and 5.88.19, or cPGuard running during the window, means the server must be treated as compromised.
3. Look for and delete /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/, /etc/cron.d/i93677 and /var/tmp/.i93677/, and search your logs for the IP address 94.183.188.91.
4. Reset the root password and every local account password, as well as any password reused elsewhere.
5. Replace root SSH keys, remove the old public keys from every server that trusted them and review authorized_keys.
6. Rotate MySQL and database passwords, S3 keys and any token or password found in the root shell history.
7. Change your OPSSHIELD portal password and turn on two-factor authentication, even if your servers were not exposed.
8. If you find signs of manual access, rebuild the server from a backup taken before 1 November.

Our take

A security agent that updates itself as root is a direct path into every server it protects: its vendor’s infrastructure becomes part of your attack surface. Keep an inventory of these agents, know where their updates come from, and keep secrets out of shell history and root-owned files that a single script can sweep up.

Sources

• 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

How we choose, verify and write our analyses →