cPGuard Update-Channel Compromise: What Hosting Teams Should Do Now

cPGuard is a server-security agent from OPSSHIELD that many web hosts run on Linux and cPanel servers. On 3 November 2026, OPSSHIELD disclosed that an attacker got into its billing and licensing systems, took the key used to publish updates, and pushed a fake cPGuard update to customer servers on 2 November. The fake update ran as root, copied root-level secrets, and left a hidden root shell behind.

OPSSHIELD's full disclosure estimates that about 2,950 customer servers ran the fake update and that about 7,900 billing portal accounts were copied (name, company, postal address, email and bcrypt-hashed password). Those figures are OPSSHIELD's own. No CVE has been assigned. This is a supply-chain incident, not a software flaw, so there is no CVSS score or KEV listing.

OPSSHIELD's guidance is clear: if your server had cPGuard installed and online between 02:08 and 03:20 UTC on 2 November, assume the attacker has its root-level secrets.

Technical Information

OPSSHIELD's timeline (all times UTC):

On servers that ran it, the script read /etc/shadow and /etc/passwd, root SSH keys and authorized_keys under /root/.ssh, /root/.my.cnf (MySQL root password) where present, and root shell history. On a small number of servers it also read /root/.s3cfg cloud storage keys. OPSSHIELD's earlier advisory said the collected data was uploaded to OPSSHIELD's own licensing server under a compromised account for the attacker to collect later. The later disclosure describes it as sent to a server the attacker controlled.

OPSSHIELD calls the script short-lived collection, not a long-term implant. It did leave a setuid-root shell at /var/tmp/.cpg91511_sh and a scheduled task at /etc/cron.d/i93677 with files in /var/tmp/.i93677/. OPSSHIELD says its logs do not record the exact request that gave the attacker access. It has patched two possible entry points and ruled out SSH, the control panel, FTP and API tokens.

Affected Product Versions

• Affected updates: cPGuard 5.88.12 through 5.88.19, inclusive.
• Fixed: OPSSHIELD's first advisory named 5.88.25 or later. The later disclosure says v5.88.26 removes the hidden root shell, and a follow-up update removes the i93677 scheduled task. Update to the latest release, at least 5.88.26.
• OPSSHIELD says servers where cPGuard was not online during the 02:08–03:20 UTC window did not receive the fake update.

To check update history, OPSSHIELD publishes:

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

Any entry from 5.88.12 to 5.88.19 means the server installed an affected update. OPSSHIELD notes that a missing or incomplete log does not prove the server was unaffected.

Workaround and Mitigation

From OPSSHIELD's published steps:

1. Update every cPGuard server with cpgcli update --start, then confirm the version with cpgcli --version.
2. Confirm the leftovers are gone: /etc/cron.d/i93677, /var/tmp/.i93677/ and /var/tmp/.cpg91511_sh. Delete them if they remain.
3. Change the root password and every local user password, using a trusted recovery environment.
4. Generate new root SSH keys, remove the old ones from authorized_keys on every server that trusted them, and review authorized_keys for entries you don't recognize.
5. Rotate the MySQL root password and any database passwords in /root/.my.cnf.
6. Rotate any password, API key or token in root's shell history, plus keys in /root/.s3cfg.
7. Treat servers reachable by SSH key from an affected host as exposed until their keys are replaced.
8. Reset your manage.opsshield.com password and turn on two-factor login.
9. If OPSSHIELD told you the attacker logged in to your server by hand, rebuild from a clean backup taken before 1 November.

Indicators of Compromise

All indicators below come from OPSSHIELD's disclosure. We have not added any.

OPSSHIELD also lists implant files found on its own internal server (/usr/bin/defunct, /usr/sbin/pythno3, /etc/profile.d/gateway.sh and related paths). It says the implant hides from standard tools, so check from a trusted boot environment or a known-good static binary.

What to Do With Your Hosting Suppliers Today

This incident turned a security agent's own update channel into the delivery route. Your organization may not run cPGuard, but a hosting provider, agency or managed-server supplier running your sites may. If they do, root passwords, SSH keys and database credentials on servers holding your data may have been copied.

Questions worth sending to hosting and server-management suppliers this week:

1. Do you run cPGuard on any server that hosts our sites, data or email?
2. Did any of those servers install 5.88.12–5.88.19, and are they now on 5.88.26 or later with the leftover files confirmed gone?
3. Have root, local user and database passwords, SSH keys and any cloud keys on those servers been rotated?
4. Were any of our credentials (FTP, database, API keys) stored on or reachable from those servers?
5. How do you vet the update channels of the third-party security agents you install with root access?

Need help working through hosting and server-security suppliers exposed to this update-channel compromise? Our team can help you prioritize them and track their answers. Talk to an expert

Sources

• OPSSHIELD, "Security Incident Disclosure: manage.opsshield.com" (3 Nov 2026): https://opsshield.com/notice/security-incident-disclosure-servermanage.html
• OPSSHIELD, "cPGuard security advisory: Update channel compromise" (3 Nov 2026): https://opsshield.com/notice/cpguard-update-channel-compromise.html
• The Hacker News (corroboration): https://thehackernews.com/2026/11/cpguard-update-channel-hijacked-to.html
• Help Net Security (corroboration): https://www.helpnetsecurity.com/2026/11/04/cpguard-update-supply-chain-compromised/
• BleepingComputer (corroboration): https://www.bleepingcomputer.com/news/security/hackers-hijack-cpguard-autoupdate-to-deploy-backdoor-steal-data/