cPGuard Auto-Update Shipped a Backdoor in 5.88.12-5.88.19 - Floor 5.88.25

cPGuard’s maker OPSSHIELD says an unidentified attacker used compromised credentials to reach their update CDN at 02:06 UTC on 2 November 2026, and pushed a malicious script inside cPGuard 5.88.12 through 5.88.19. They say they caught it within 12 hours, stopped further distribution, and that 5.88.25 and later remove the known backdoor and staged files. There is no CVE. Updating does not rotate anything the script copied.[1][2][3]

If you run cPGuard on cPanel, Plesk, DirectAdmin, or a bare Linux VPS, this is a hosting-stack incident: the security agent’s auto-update was the delivery path.

What it is

This is not a cPanel, Plesk, or kernel CVE. It is a compromised vendor update channel. Servers that checked for updates during that window installed a package that ran a harvest script. OPSSHIELD names the dropper cpguard-v58812-i91511.sh.[1][2]

On servers where that script ran, OPSSHIELD says it:[1][2]

Installed a backdoor shell at /var/tmp/.cpg91511_sh
Staged files under /var/tmp/.cpg91511, including loot.tgz
Collected /etc/shadow and /etc/passwd, root’s MariaDB/MySQL config (my.cnf), root’s shell history, and root SSH authorized-keys / known-hosts files
Uploaded the take to OPSSHIELD’s own licensing server, using a compromised account on that server, so the attacker could retrieve it later. OPSSHIELD says that account is now secured.

We did not reverse the script. Public facts stop at the vendor IoCs and the file classes they named.

How serious

A security scanner that auto-updates as root is a high-value supply-chain target. Password hashes in /etc/shadow can be cracked offline if the password is weak or reused. Database config, shell history, and SSH keys have no hashing in the way.

Two numbers are in circulation. Keep them labeled:

The Hacker News, citing OPSSHIELD late on 2 November UTC: the attacker took 32 files from the licensing server, each tied to one customer server. That count covers files known to have been taken and may change. It is not a total of every server that installed 5.88.12-5.88.19.[2]
BleepingComputer, quoting an OPSSHIELD spokesperson: 2,946 servers were affected, the same class of files were copied, and the billing-system database was copied. That 2,946 figure is not in the written advisory excerpts we used. Treat it as a spokesperson claim to BC, not as a CVE score.[3]

OPSSHIELD’s written guidance: a log line for 5.88.12-5.88.19 means the affected update was installed. That line does not prove the script ran or that data left. Treat those boxes as potentially compromised anyway, even if they now report 5.88.25. A missing or incomplete log is not a clean bill of health.[1][2]

This is not on CISA KEV as of catalog version 2026.11.03 (1,767 entries; the 3 November add is WordPress Core CVE-2026-119977, not this). Absence from KEV is expected - there is no CVE - and is not a reason to wait.[4]

OPSSHIELD says that beyond the harvest and the backdoor they have found no other malicious activity so far, and that finding is not final.[2]

Who is affected

In scope until you prove otherwise:

Any Linux host with cPGuard 5.88.12 through 5.88.19 in /opt/cpguard/logs/install_log (or an incomplete log and no other proof).
Hosts that auto-updated during 2 November 2026 ~02:06 UTC and the following ~12 hours. Update checks are interval-based; some boxes may have missed the bad packages, some may have run them after the vendor thought distribution had stopped.
Shared-hosting panels that ship or offer cPGuard (cPanel, DirectAdmin, Plesk, and VPS/dedicated SKUs such as Namecheap’s documented offer). The panel is not the bug. The agent is.[3]

Out of scope for this incident, unless a second advisory says otherwise: servers that never installed 5.88.12-5.88.19 and have a complete install log proving it, and show no IoCs. Still rotate if you cannot prove the log is complete.

Unsupported / no-CVE note: there is no NVD row to “patch to.” The floor is a vendor version string.

What to do now

Read the install log, then the running version. Do not trust a dashboard tile.

grep 'Successfully updated' /opt/cpguard/logs/install_log
cpgcli --version

Any Successfully updated to 5.88.12 … 5.88.19 line means treat the box as in-scope, even if cpgcli --version already shows 5.88.25+.[1][2]

Update every cPGuard host to 5.88.25 or later.

cpgcli update --start
cpgcli --version

If the update fails or the version is still below 5.88.25, OPSSHIELD says contact their support. 5.88.25 removes the known backdoor and staged files. It does not un-steal hashes, my.cnf, history, or SSH keys.[1][2]

Hunt the IoCs before you assume cleanup worked. Absence after 5.88.25 proves nothing - the update deletes them.

ls -la /var/tmp/.cpg91511_sh /var/tmp/.cpg91511 /var/tmp/.cpg91511/loot.tgz 2>/dev/null
find / -name 'cpguard-v58812-i91511.sh' 2>/dev/null

Keep copies of the log and any hits before you delete. We are not publishing script reconstruction.

Rotate from a trusted environment, for every host that installed 5.88.12-5.88.19 or might have. OPSSHIELD’s order:[1][2]
- Reset root and every other local Linux password, from a machine you trust.
- Change any of those passwords that were reused elsewhere.
- Rotate DB passwords, object-storage keys, DigitalOcean tokens, and anything sitting in root’s shell history.
- Replace SSH private keys under /root/.ssh and remove the matching old public keys from every system that trusts them.
Expect a second OPSSHIELD update that removes previously installed support-access keys (the SSH public key customers add so OPSSHIELD staff can log in as root). OPSSHIELD has not said whether the matching private key was exposed. Do not wait on that package to rotate your own keys.[2]
Do not treat “update and done” as close-out. Patching the agent is step 2. Credential and key rotation is the actual containment.

Versions with no upstream CVE

There is no php.net-style branch matrix. Floor is 5.88.25+. OPSSHIELD is not recommending a full OS rebuild as a routine step, and says that view can change. If you find extra compromise signs, or cannot confirm the box is clean, they want a case-by-case support review that may end in a rebuild.[1][2]

If you cannot update today: isolate SSH to known admin IPs, disable password SSH if you still have it, and rotate anyway. Isolation is not a substitute for 5.88.25 plus rotation.

How to spot a compromise

Vendor IoCs above. Also look for what a root harvest usually leaves behind:

New or unexpected keys in /root/.ssh/authorized_keys (including leftover vendor support keys)
New cron as root, unexpected users in /etc/passwd
Outbound copies you did not start around 2 November UTC
Logins that used passwords you are about to rotate

If you suspect more than the named dropper, isolate the server and keep /opt/cpguard/logs/ before cleanup.

FAQ

Is there a CVE? Not as of this writing. Hunt by version and IoC, not by CVE ID.

Is it on CISA KEV? No. Catalog 2026.11.03. That is not a pass.[4]

Does 5.88.25 clean the box? It removes the known backdoor and staged files. Stolen secrets still work until you rotate them.[1][2]

Did every 5.88.12-5.88.19 install run the script? OPSSHIELD says update checks are interval-based. Treat a matching log line as in-scope anyway.[1]

Should we rebuild? Not as OPSSHIELD’s default. Rebuild if you cannot confirm cleanliness or you find extra activity. Ask their support for that call.[2]

Honesty

We did not obtain or run the dropper.
Direct fetch of opsshield.com/notice/cpguard-update-channel-compromise.html from this writer returned HTTP 406. Commands, IoCs, timestamps, and “not a routine rebuild” are from that advisory as quoted by The Hacker News (3 Nov 2026) and BleepingComputer (3 Nov 2026), plus OPSSHIELD’s own URL as the primary pointer.[1][2][3]
2,946 servers and the billing-database copy are a spokesperson statement to BleepingComputer, not a numbered row in the public advisory text we could retrieve.[3]
32 files / one per customer is THN’s account of OPSSHIELD’s 2 November estimate; it may change.[2]
How the CDN credentials were stolen is unanswered by the vendor.

Sources

[1] https://opsshield.com/notice/cpguard-update-channel-compromise.html - OPSSHIELD advisory (3 Nov 2026)
[2] https://thehackernews.com/2026/11/cpguard-update-channel-hijacked-to.html - THN, 3 Nov 2026
[3] https://www.bleepingcomputer.com/news/security/hackers-hijack-cpguard-autoupdate-to-deploy-backdoor-steal-data/ - BC, 3 Nov 2026
[4] CISA KEV JSON catalogVersion 2026.11.03, 1,767 entries; newest add CVE-2026-119977