cPGuard 5.88.12 to 5.88.19 update channel hijacked: backdoor and root secrets stolen, update to 5.88.25

Attackers who got hold of credentials for OpsShield's update system pushed a malicious script through the cPGuard update channel on 2 November 2026. The script collected password hashes, root database settings, shell history and SSH files from Linux servers running cPGuard 5.88.12 to 5.88.19, left a backdoor, and uploaded the haul to OpsShield's own licensing server. If you run cPGuard, update to 5.88.25 or later, check your install log, and treat any server that installed an affected build as potentially compromised.

Key points

• Affected: cPGuard 5.88.12 through 5.88.19, delivered by the product's auto-update channel from 2 November 2026 at 02:06 UTC.
• OpsShield says it detected the attack and stopped distribution within 12 hours of the malicious versions launching.
• Fixed: cPGuard 5.88.25 or later, which OpsShield says removes the backdoor and staged files. Updating does not invalidate stolen secrets.
• OpsShield's advisory counts 32 collected files (one per customer server) retrieved so far; a company spokesperson told BleepingComputer that 2,946 servers were affected. These figures measure different things and neither is final.
• OpsShield's own billing-system database was also copied, according to the company spokesperson quoted by BleepingComputer.

What to do

1. Check whether you installed an affected build. Run grep 'Successfully updated' /opt/cpguard/logs/install_log. A line showing any version from 5.88.12 to 5.88.19 means the server installed an affected update, and OpsShield says to treat it as potentially compromised even if it now runs a fixed version. A matching line does not prove the script ran, and a missing or incomplete log does not prove it did not.
2. Update. Run cpgcli update --start, then confirm with cpgcli --version that the version is 5.88.25 or later. Contact OpsShield support if the update fails.
3. Look for the indicators OpsShield published: the script cpguard-v58812-i91511.sh, the backdoor shell /var/tmp/.cpg91511_sh, the collection directory /var/tmp/.cpg91511 and the staged archive /var/tmp/.cpg91511/loot.tgz. The fix removes the backdoor and directory, so their absence does not clear a server.
4. If the script ran or may have run, rotate secrets, working from a trusted recovery environment: reset passwords for root and every other local account with a password; change any password reused elsewhere; rotate database passwords, S3 access keys, DigitalOcean tokens and anything else sitting in root's shell history; replace the SSH private keys under /root/.ssh and remove the old public keys from every system that trusted them. Our guide to rotating leaked environment variables and API keys after a platform breach covers the general routine.
5. Support keys. If you enabled OpsShield support access, an OpsShield SSH public key sits in root's authorized_keys. OpsShield is shipping a precautionary update to remove those keys; it says this does not replace the steps above, and it has not said whether the matching private key was exposed.

OpsShield says a full server rebuild is not recommended as routine on current data, but may be appropriate if you find more signs of compromise or cannot verify the server's integrity.

What happened

cPGuard is a server security suite from OpsShield that runs on cPanel, DirectAdmin and similar Linux hosting servers. In its advisory dated 3 November 2026, OpsShield says an attacker used compromised credentials to reach its update distribution CDN at 02:06 UTC on 2 November and pushed a malicious script through the cPGuard update channel. BleepingComputer, which reported the incident the same day, says how the credentials were obtained is unknown.

The script gathered files from each server it ran on and uploaded them to OpsShield's licensing server, through a compromised account there, so the attacker could fetch them later. OpsShield lists the targets: /etc/shadow and /etc/passwd, the root MariaDB/MySQL configuration (my.cnf), root's shell history, and root's SSH authorization and known-hosts files. It also installed a backdoor shell and staged an archive of the collected data on the server.

OpsShield says it caught the activity within 12 hours of the affected versions going out and halted distribution. Because the product checks for updates at set intervals, it says some servers may never have received the script, though it could not confirm this.

Background

An update channel is trusted by design: a security tool running as root fetches and runs code from its vendor automatically. That makes the vendor's distribution infrastructure a high-value target, since one compromised account reaches every customer at once. The risk is not new, but it is awkward for a product whose job is protecting servers.

The numbers

Figure	Value	Source
Malicious builds	5.88.12 to 5.88.19	OpsShield advisory
Time to detection	within 12 hours of launch	OpsShield advisory
Minimum safe version	5.88.25	OpsShield advisory
Files retrieved, one per customer server	32 (preliminary)	OpsShield advisory
Servers affected, per a company spokesperson	2,946	BleepingComputer

The 32 and the 2,946 should not be read as contradicting each other. OpsShield's advisory says its 32-file count is not the total number of potentially affected servers and that it is still verifying scope; the 2,946 is a spokesperson's statement to a journalist, and we have not seen the method behind it. BleepingComputer also reports that OpsShield has not determined what data was taken from each server.

What it means

For hosting providers and server admins the immediate task is the one above: audit the install log, update, and rotate. Because the script targeted root credentials, the exposure is not limited to the hosting panel: anything root could reach, including databases and cloud accounts whose keys were in shell history, is in scope.

For cPGuard customers who reuse credentials the risk compounds. Password hashes in /etc/shadow can be cracked offline, and weak or reused passwords are the first to fall, which is why OpsShield tells customers to change passwords reused on other systems.

For vendors, the incident repeats a standard lesson: separate the credentials that publish updates from everyday accounts, require multi-factor sign-in on distribution systems, and sign updates so clients can reject a script that was not built by the vendor. None of the sources says whether cPGuard signs its updates; we are not claiming it does or does not.

What we don't know yet

• How the credentials were stolen. BleepingComputer says this is unknown.
• The real scope. OpsShield is still verifying how many servers ran the script and what each lost.
• Who is responsible. BleepingComputer's report gives no attribution and no malware family name.
• Whether a later release changes the advice. Some secondary reports mention a follow-up release (5.88.26) that revokes support access; we could not confirm that against OpsShield's advisory, which names 5.88.25 as the minimum. Check OpsShield's notice for the current recommended version.
• Whether the support-access private key was exposed. OpsShield has not said.

What to watch next

Watch OpsShield's incident page for updated counts and a post-mortem, any additional indicators of compromise, and the update that removes support-access keys. If you run cPGuard, check the install log today rather than waiting for the final tally.

Sources

• cPGuard update channel compromise, OpsShield advisory (primary source)
• Hackers hijack cPGuard autoupdate to deploy backdoor, steal data, BleepingComputer
• cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes, The Hacker News