cPGuard Update Channel Hijacked: A Fake Update Stole Root SSH Keys, Password Hashes and Database Credentials From About 2,950 Linux Servers

DevSecOps · 2026-11-05 · By H.A

An attacker who broke in through OPSSHIELD's billing portal used a stolen update key to push a credential-stealing backdoor to cPGuard servers running versions 5.88.12 to 5.88.19.

What Happened

OPSSHIELD, the company behind the cPGuard Linux web-server security suite, has disclosed that an attacker hijacked its automatic update channel on 2 November 2026. The attacker used it to push a malicious script to customer servers.

According to the vendor, about 2,950 servers ran the script. It collected password hashes, SSH keys and database credentials as root, and left a backdoor behind.

cPGuard provides malware scanning, a firewall and attack protection, and is used by hosting companies and server administrators alongside cPanel, DirectAdmin and Plesk. Because it runs with root privileges on shared-hosting servers, a malicious update from it reaches the most sensitive part of each machine.

How the Attack Unfolded

OPSSHIELD's updated disclosure gives this timeline, in UTC:

• 1 November: the attacker registered a customer account under a false identity and ordered a free cPGuard trial.
• 1 November, 22:58: crafted requests to billing-portal callback pages gave the attacker command execution on the vendor's billing and licensing server.
• 2 November, 02:04–02:09: using a stolen update-publishing key, the attacker uploaded the malicious script to the update system.
• 2 November, 02:08–03:20: servers that were online and checking for updates installed it.

The vendor says it detected the compromise and stopped distribution within about 12 hours. The attacker also copied three OPSSHIELD cloud servers and took billing records for about 7,900 customer accounts: names, company names, postal and email addresses, and bcrypt password hashes.

The attacker has not been identified.

What the Malicious Update Did

The script shipped in cPGuard versions 5.88.12 through 5.88.19. Per the vendor, it:

• collected /etc/shadow and /etc/passwd
• collected root's SSH private keys and other files in /root/.ssh
• read the MySQL/MariaDB root password from /root/.my.cnf
• read root's shell history
• on a few servers, read S3 keys from /root/.s3cfg
• dropped a hidden setuid-root shell at /var/tmp/.cpg91511_sh as a backdoor
• added a scheduled task at /etc/cron.d/i93677, with files in /var/tmp/.i93677/
• staged loot in /var/tmp/.cpg91511/loot.tgz before exfiltration

OPSSHIELD first said the stolen files went through its licensing server via a compromised account. Its later disclosure says they went to a server the attacker controlled. The vendor names 94.183.188[.]91 as the main attacker address.

Published SHA-256 hashes of the malicious scripts (cpguard-v58812-i91511*.sh) include:

2c2acd988da531d133d0e17f245c49bf15781278f837543d18c95e8410eabd38
ffd7a47f65fa1244429baa936ae94be54676b53d2f88bc39564f24e22011de8a
d73919af84bf46de941db85e27fd1abc65701ef9ce6cf33bb27c5397f4a41c26
6add0201e9a3d02de772d561d05e0da86eb1c538686753b7adcc3aedf7366f77

Patch Status

OPSSHIELD first named 5.88.25 as the clean release. Its later disclosure says 5.88.26 removes the backdoor, and a follow-up update removes the scheduled task. A further update removes OPSSHIELD support-access keys that had been added to root's authorized_keys. It is not yet known whether the matching private key was exposed.

The vendor has revoked the stolen update key and cloud access keys, rotated billing and reseller API keys, reset portal sessions, and is reissuing every cPGuard license key while it rebuilds its billing, licensing and internal servers.

What To Do Now

First, establish whether an affected version was installed:

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

An entry for 5.88.12 through 5.88.19 means an affected update was installed. It does not prove the script ran or that data left. A missing or incomplete log does not prove the server is clean either. Then update and verify:

cpgcli update --start
cpgcli --version
ls -la /etc/cron.d/i93677 /var/tmp/.i93677/ /var/tmp/.cpg91511_sh 2>/dev/null

The update removes these artefacts, so their absence after updating proves nothing. If any remain, delete them and treat the server as compromised.

For any server where the script ran or may have run:

• Reset root and all local password accounts from a trusted recovery environment, and change reused passwords elsewhere.
• Change the MySQL root password and any database passwords stored in /root/.my.cnf.
• Rotate cloud secrets: S3 keys, DigitalOcean tokens and anything else that appeared in shell history.
• Replace root's SSH keys, remove the old public keys from every system that trusted them, and audit authorized_keys. Treat servers reachable with those keys as exposed.
• Rebuild from a clean pre-1 November backup if there is any sign of manual attacker login.
• Reset your OPSSHIELD billing-portal password and enable two-factor login.
• Block and hunt for connections to 94.183.188[.]91 in firewall and flow logs.

Why It Matters

Security tools are a very effective supply-chain target. They run as root, update automatically, and are trusted by design. Here the way in was not a sophisticated implant but a vulnerable billing-portal callback reached from a free-trial account. That gave the attacker the update-signing key.

Vendors should keep the key that publishes software updates well away from customer-facing web applications. Hosting providers should assume that any auto-updating root agent is part of their attack surface, monitor its update traffic, and be ready to rotate every secret on a server within hours.