---
title: "cPGuard Update Hijack: Root Backdoor on ~2,950 Servers"
url: https://erroneo.us/security/briefs/cpguard-5-88-update-channel-supply-chain-compromise/
description: "A fake cPGuard update (5.88.12-5.88.19) ran as root on about 2,950 servers on Nov 2 and stole SSH keys and DB passwords. Update to 5.88.25+ and rotate."
type: security-brief
section: "Security Digest"
date_published: 2026-11-02
date_modified: 2026-11-04
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Act now"
cves: []
severity: "critical"
exploited: "in-the-wild"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# cPGuard Update Hijack: Root Backdoor on ~2,950 Servers

**Verdict: Act now.** If any server's cPGuard install log shows a version from 5.88.12 to 5.88.19, treat that server's root secrets as stolen: update, remove the backdoor files, and rotate passwords, SSH keys and database credentials today.

- **Who must act:** Hosting providers, resellers and admins running cPGuard on cPanel, DirectAdmin or Plesk servers that were online on November 2, 2026, plus every OpsShield billing portal account holder.
- **Who can relax:** Anyone not running cPGuard, and cPGuard users whose install logs show no 5.88.12 to 5.88.19 update, though they should still reset their OpsShield portal password.
- **Affected:** cPGuard 5.88.12 through 5.88.19 (malicious builds pushed through the official update channel); Servers that polled for updates roughly 02:08 to 03:20 UTC on November 2, 2026 (about 2,950, per OpsShield); About 7,900 OpsShield billing portal accounts (name, company, postal address, email, bcrypt password hash)
- **Fixed:** cPGuard 5.88.25 or later removes the backdoor and staged files (OpsShield's disclosure names 5.88.26 as the clean release published November 2); No update undoes the theft: stolen credentials must be rotated
- **CVEs:** none
- **CISA KEV:** no · **Exploitation:** Exploited in the wild

## What to do

1. Run grep 'Successfully updated' /opt/cpguard/logs/install_log on every cPGuard server; any 5.88.12 to 5.88.19 entry means treat the server as compromised, even if it now runs a newer version.
2. Update with cpgcli update --start, confirm with cpgcli --version, and make sure /etc/cron.d/i93677, /var/tmp/.i93677/, /var/tmp/.cpg91511/ and /var/tmp/.cpg91511_sh are gone.
3. Change the root password and every local account password, and any password reused elsewhere.
4. Generate new root SSH keys, remove the old public keys from authorized_keys on every host that trusted them, and review authorized_keys for entries you did not add.
5. Rotate the MySQL/MariaDB root password, credentials in /root/.my.cnf, keys in /root/.s3cfg, and any token or password that appears in root's shell history.
6. Reset your OpsShield billing portal password and enable two-factor login, even if cPGuard was offline during the window.
7. If you find signs of a manual login, rebuild the server from a backup taken before November 1, 2026.

### How to check if you are affected

- grep 'Successfully updated' /opt/cpguard/logs/install_log for versions 5.88.12 to 5.88.19.
- Look for cpguard-v58812-i91511.sh, /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/loot.tgz, /etc/cron.d/i93677 and /var/tmp/.i93677/; their absence does not prove the script never ran.
- Check lastlog, /var/log/secure or auth.log and wtmp for root or SSH logins after 02:00 UTC on November 2 from addresses you do not recognize.
- On hosts reachable with the server's root SSH key, review authentication logs for logins using that key since November 2.

## What happened

On November 2, 2026, an attacker pushed a malicious update through the official update channel of cPGuard, OpsShield's malware and intrusion protection suite for Linux web servers. cPGuard is widely used alongside cPanel, DirectAdmin and Plesk, and [BleepingComputer](https://www.bleepingcomputer.com/news/security/hackers-hijack-cpguard-autoupdate-to-deploy-backdoor-steal-data/) notes that Namecheap offers it on its VPS and dedicated servers. The fake builds carry version numbers 5.88.12 through 5.88.19. Because cPGuard updates itself and runs as root, every server that picked up one of them ran the attacker's script as root.

According to OpsShield's [incident disclosure](https://opsshield.com/notice/security-incident-disclosure-servermanage.html), the attack started at the vendor's billing portal. On November 1 the attacker registered a customer account under a false identity, ordered a free trial, and at 22:58 UTC gained command execution on the billing and licensing server. From there they obtained an access key for the update storage. They uploaded the fake update between 02:04 and 02:09 UTC on November 2, and cPGuard agents installed it between 02:08 and 03:20 UTC. OpsShield revoked the key and published a clean release the same day.

The script collected `/etc/shadow` and `/etc/passwd`, root's MySQL/MariaDB configuration, root's shell history, and root's SSH `authorized_keys` and `known_hosts` files. On a small number of servers it also took cloud keys in `/root/.s3cfg`. The data was uploaded to OpsShield's own licensing server under a compromised account, where the attacker collected it. The script also left a hidden root shell, per the vendor's [update channel notice](https://opsshield.com/notice/cpguard-update-channel-compromise.html).

OpsShield estimates that about 2,950 servers ran the fake update (a spokesperson gave BleepingComputer a figure of 2,946). The attacker retrieved 32 collected files, each from a different customer server. The attacker also copied three OpsShield cloud servers and about 7,900 billing portal account records, which hold names, companies, postal addresses, emails and bcrypt password hashes. OpsShield is reissuing all cPGuard license key pairs, and [SecurityWeek](https://www.securityweek.com/malicious-cpguard-updates-served-in-opsshield-supply-chain-attack/) reports it is rebuilding its billing, licensing and internal management servers. No threat actor has been named as of November 4.

## Who is affected

Any server that had cPGuard running and online during the roughly 70-minute window on the morning of November 2 (UTC). OpsShield puts it plainly: "If cPGuard was not online during that window, your server did not receive the fake update." The install log is the reliable test, because a server that took a bad build and then updated again now shows a clean version number.

Separately, every OpsShield billing portal account is exposed, whether or not its servers took the update.

## Do you really need to act?

If the log shows 5.88.12 to 5.88.19, yes, and today. This is not a theoretical vulnerability; attacker code ran as root. OpsShield's guidance is to "assume its root-level secrets are known to the attacker." Only 32 servers' data is known to have been retrieved, but OpsShield has not said which ones, so every server that ran the script has to be handled as if it were one of them. Root SSH keys are the biggest worry. If a server's key is trusted by backup hosts, other servers in a fleet, or Git deploy targets, those systems are exposed too.

The vendor does not recommend a routine OS rebuild. It reserves that for servers with further signs of compromise or whose integrity you cannot verify. That is reasonable for a script that collected files and dropped a shell, provided you remove the shell, rotate everything it could read, and check for logins. Shared-hosting providers should also plan to tell customers whose database passwords lived in root's configuration.

If you do not run cPGuard, there is nothing to do beyond the usual lesson: a security agent with root and auto-update is a single point of failure.

## What to do now

1. Check the history on every server: `grep 'Successfully updated' /opt/cpguard/logs/install_log`.
2. Update and verify: `cpgcli update --start`, then `cpgcli --version` (5.88.25 or later). Confirm that `/etc/cron.d/i93677`, `/var/tmp/.i93677/`, `/var/tmp/.cpg91511/` and `/var/tmp/.cpg91511_sh` no longer exist.
3. On affected servers, change the root password and all local passwords, ideally from a console or recovery session rather than over the existing SSH trust.
4. Replace root's SSH keys: `ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519`, then remove the old public key from every `authorized_keys` that trusted it, and audit the server's own `authorized_keys`.
5. Rotate the database root password and anything in `/root/.my.cnf`, revoke the keys in `/root/.s3cfg` at the cloud provider, and rotate every token or password visible in `/root/.bash_history`.
6. Reset the OpsShield billing portal password and turn on two-factor login.

## How to tell if you were hit

The install log entry is the main signal. Then look for the vendor's indicators: the script `cpguard-v58812-i91511.sh`, the shell `/var/tmp/.cpg91511_sh`, the staging archive `/var/tmp/.cpg91511/loot.tgz`, and `/etc/cron.d/i93677`. OpsShield warns that their absence does not prove the script never ran, since a later update removes them. Review `last`, `lastb` and `/var/log/secure` or `auth.log` for SSH sessions since November 2 that you cannot account for, on this server and on every host its root key could reach. A manual login is OpsShield's trigger for restoring from a backup taken before November 1.

## Timeline

- Nov 1, 2026 — Attacker probes the OpsShield billing portal, registers a trial account and gains command execution on the billing and licensing server at 22:58 UTC.
- Nov 2, 2026 — Fake cPGuard update uploaded 02:04 to 02:09 UTC and installed by agents 02:08 to 03:20 UTC. Three OpsShield cloud servers are copied. The stolen key is revoked, a clean release is published, and OpsShield announces an update to remove its own support-access keys from customer servers.
- Nov 3, 2026 — OpsShield traces the entry point and publishes its notice and disclosure: about 2,950 servers ran the fake update and about 7,900 billing accounts were copied.
- Nov 4, 2026 — SecurityWeek reports that OpsShield is reissuing all license key pairs and rebuilding its billing, licensing and management servers. No attacker has been named.

## Sources

1. [OpsShield — cPGuard update channel compromise](https://opsshield.com/notice/cpguard-update-channel-compromise.html)
2. [OpsShield — Security incident disclosure](https://opsshield.com/notice/security-incident-disclosure-servermanage.html)
3. [BleepingComputer — Hackers hijack cPGuard autoupdate to deploy backdoor, steal data](https://www.bleepingcomputer.com/news/security/hackers-hijack-cpguard-autoupdate-to-deploy-backdoor-steal-data/)
4. [SecurityWeek — Malicious cPGuard Updates Served in OpsShield Supply Chain Attack](https://www.securityweek.com/malicious-cpguard-updates-served-in-opsshield-supply-chain-attack/)

---
Source page: https://erroneo.us/security/briefs/cpguard-5-88-update-channel-supply-chain-compromise/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt