Attackers hijacked the update channel for cPGuard, a security add-on for Linux hosting servers, and on November 2, 2026 pushed a fake update that copied root password hashes, SSH keys and database logins. According to OpsShield’s incident disclosure, about 2,950 customer servers ran it.
cPGuard is sold for servers run with cPanel, DirectAdmin, Plesk and several other control panels, so the people affected range from hosting companies to agencies running their own VPS. This post covers what happened, how the vendor’s two notices differ, how to check a server, what to rotate, and what to ask your host. Facts are as of November 4, 2026; OpsShield says its numbers are still being checked.
The short version: if a server had cPGuard installed and online between 02:08 and 03:20 UTC on November 2, OpsShield says to assume the attacker knows its root-level secrets. Update cPGuard, confirm the backdoor files are gone, then change root and local user passwords, replace root SSH keys, change database passwords and rotate any keys in root’s shell history. Updating alone does not undo the theft.
What happened to the cPGuard update channel
OpsShield’s disclosure, published November 3, lays out the timeline in UTC. On November 1 the attacker probed the billing portal, registered a customer account under a false identity and ordered a free trial. That evening, crafted requests to the billing portal’s callback pages gave the attacker the ability to run commands on the billing and licensing server.
From there, the attacker stole the keys used to publish updates. Between 02:04 and 02:09 UTC on November 2, a fake update was uploaded with a stolen access key. cPGuard agents installed it between 02:08 and 03:20 UTC. OpsShield says the fake update shipped for about 70 minutes before it was found and stopped.
The fake update was a short script that ran as root. It collected sensitive files and sent them to a server the attacker controlled. It also left a hidden root shell and a scheduled task behind.
OpsShield revoked the stolen key and published a clean update the same day. The disclosure adds that the attacker copied three OpsShield cloud servers, and an older, separate backdoor turned up on an internal server.
Two OpsShield notices, and which numbers to use
OpsShield has published two notices, and they do not match on every detail. The first is the cPGuard update channel advisory, also dated November 3. It points readers to the later disclosure for the latest findings.
| Detail | Update channel advisory | Incident disclosure |
|---|---|---|
| How the attacker got in | Compromised credentials for the update CDN; source under investigation | Command execution on the billing and licensing server, then stolen update keys |
| Exposure window | Starting 02:06 UTC; detected within 12 hours | Agents installed it 02:08 to 03:20 UTC, about 70 minutes |
| Servers affected | 32 collected files retrieved, each from one customer server; not a total | About 2,950 servers ran the fake update |
| Fixed version | 5.88.25 or later | Clean update 5.88.26, plus a follow-up that removes the scheduled task |
The advisory lists the affected versions as 5.88.12 through 5.88.19. BleepingComputer reported on November 3 that an OpsShield spokesperson put the count at 2,946 servers and said the billing database was copied. Our advice: work from the later disclosure, and treat every count as preliminary.
What the cPGuard fake update took
According to the disclosure, the script read these files from each server that ran it. Not every file existed on every server.
| What was read | Why it matters | What to change |
|---|---|---|
/etc/shadow and /etc/passwd |
Password hashes for root and local users; weak passwords can be cracked offline | Root and every local user password |
/root/.ssh |
Root’s private keys, authorized_keys and known_hosts |
New root SSH keys; remove old public keys everywhere |
/root/.my.cnf |
The MySQL root password, where present | MySQL root and any database passwords in it |
| Root shell history | Commands may contain typed passwords and tokens | Every secret that appears in it |
/root/.s3cfg |
Cloud storage keys, on a small number of servers | Those access keys |
The advisory adds that shadow entries are one-way hashes, not plain text. Long, unique passwords are much harder to crack. OpsShield still requires resets, because hashing does nothing for database secrets or shell history.
The billing system was hit too. The disclosure says about 7,900 billing accounts were copied: name, company, postal address, email and a bcrypt password hash.
How to tell if a server runs cPGuard, and which version
Start with an inventory of every server you or your clients run. OpsShield’s product pages cover cPanel/WHM, DirectAdmin, Plesk and a standalone install, plus panels such as CyberPanel, Webuzo and Enhance.
On each server, the advisory gives two commands. The first shows the installed version:
cpgcli --versionThe second shows the update history:
grep 'Successfully updated' /opt/cpguard/logs/install_logIf the history shows any version from 5.88.12 through 5.88.19, OpsShield says to treat the server as potentially compromised. That holds even if it now runs a fixed version. Missing or incomplete log entries do not prove the server was safe.
OpsShield also offers a lookup page that checks servers against its incident records. The disclosure is clear on its limits: assume a server is exposed if cPGuard was online during the window, even if the lookup shows no match.
Update to the fixed cPGuard version and clean up
Run the update on every server:
cpgcli update --startThen confirm the version again. The cPGuard changelog lists two security patches on November 2. Version 5.88.25 patched the compromised update. Version 5.88.26 revoked OpsShield’s support access to servers where it was enabled. The disclosure names 5.88.26 as the clean update that removes the hidden root shell.
Next, check by hand that these paths are gone, and delete them if not:
/etc/cron.d/i93677(the scheduled task; a follow-up update removes it)/var/tmp/.i93677//var/tmp/.cpg91511_sh(the hidden root shell)/var/tmp/.cpg91511/, including a staged archive namedloot.tgz
The advisory warns that missing files do not show the script never ran. If an update fails or the version will not move, open a ticket with OpsShield.
Rotate root, database and SSH credentials
OpsShield says these steps take most admins under an hour per server. The advisory says to work from a trusted recovery environment. Here is the list from its two notices:
- Change the root password and every local user password.
- From a trusted device, change any of those passwords that are reused on other systems.
- Generate new root SSH keys. Remove the old public keys from
authorized_keyson every server that trusted them. Look for unknown entries while you are there. - Change the MySQL root password and any database passwords stored in
/root/.my.cnf. - Rotate passwords, API keys and tokens found in root’s shell history. The advisory names S3 access keys and DigitalOcean tokens as examples.
- Rotate any keys in
/root/.s3cfg. - Treat other servers this one could reach over SSH as exposed until their keys are replaced.
- Reset your OpsShield billing portal password and turn on two-factor login.
On rebuilds, the advisory says a routine OS rebuild is not currently recommended. That position is provisional. The disclosure adds one firm rule: if OpsShield told you the attacker logged in to your server by hand, rebuild it from a clean backup taken before November 1.
One addition of ours: MySQL root can read every database on the server. If a site’s database password appears in root’s history, change it and update the site’s config file.
On shared or managed hosting? Questions for your host
If you host client sites on shared or managed plans, you cannot run these commands. Your host can. Send them these questions:
- Does any server hosting our sites run cPGuard?
- Was it online between 02:08 and 03:20 UTC on November 2, or did it install 5.88.12 through 5.88.19?
- Is it now on 5.88.26 or later, with the scheduled task removed?
- Have you rotated root passwords, the MySQL root password and root SSH keys?
- Did OpsShield report a hands-on login to that server?
- Should we change our control panel and database passwords?
That last question matters. OpsShield tells admins to change every local user password. On control-panel servers, hosting accounts are usually local Linux users, so your account’s hash may have been in the copied file. Use a long, unique password, as covered in our password basics for small business.
Turn on multi-factor authentication for the control panel if your host offers it. The billing data also included names and email addresses. Expect phishing that mentions OpsShield, cPGuard or your host, and confirm any request through a channel you already trust.
Why a security tool’s update channel is a target
Server security agents run as root and update themselves on a schedule. That makes their update channel a direct route to every server they protect. The same channel shipped cPGuard’s emergency PHP2Shell patches on October 21.
This is the same pattern we saw in the npm supply chain attack on build servers and in package registry security.
A few habits limit the damage next time: keep secrets out of root shell history, do not reuse root passwords, and limit which servers trust one root SSH key. Blocking PHP execution in upload folders still helps too. If client data was exposed, follow your data breach response plan.
Frequently Asked Questions
What is cPGuard?
cPGuard is a security product from OpsShield for Linux web hosting servers. It combines a malware scanner, a ModSecurity web application firewall and a firewall with an abusive IP blocklist. It runs with cPanel/WHM, DirectAdmin, Plesk and other control panels, or standalone.
Which cPGuard versions were affected?
OpsShield’s advisory lists 5.88.12 through 5.88.19. The incident disclosure frames it by time instead: any server with cPGuard installed and online between 02:08 and 03:20 UTC on November 2, 2026 should be treated as exposed.
Which version should I be on now?
At least 5.88.26. The advisory says 5.88.25 or later, but the disclosure names 5.88.26 as the clean update that removes the hidden root shell. Run cpgcli update --start, then check with cpgcli --version.
Is updating cPGuard enough?
No. The update removes the known backdoor files. Copied passwords, keys and database logins still work until you change them.
How many servers were affected?
OpsShield’s disclosure says about 2,950 servers ran the fake update. BleepingComputer reported a spokesperson figure of 2,946. Both were preliminary as of November 4, 2026.
Do I need to rebuild my server?
OpsShield does not currently recommend a routine rebuild, and says that may change. Rebuild from a clean backup taken before November 1 if OpsShield told you the attacker logged in to your server by hand, or if you cannot establish the server’s integrity.
I am on shared hosting. What should I do?
Ask your host whether your server runs cPGuard, whether it was online during the window, and whether they rotated root, database and SSH credentials. Ask whether you should change your control panel and database passwords. Then change them anyway if the answer is unclear.
Was OpsShield’s billing data exposed?
Yes. The disclosure says about 7,900 billing portal accounts were copied, including name, company, postal address, email and a bcrypt password hash. OpsShield tells customers to reset their billing portal password and turn on two-factor login.
How did the attacker get the update keys?
According to OpsShield’s disclosure, the attacker registered a customer account, then used crafted requests to billing portal callback pages to run commands on the billing and licensing server. The update keys were stolen from there.
