HomeOctober 2026 patch cyclecPGuard 5.88.12-5.88.19: update channel pushed a backdoor
Call: Patch nowCategory: Enterprisefrom 2026-10
cPGuard 5.88.12-5.88.19: update channel pushed a backdoor
Part of October 2026 patch cycle
- Vendor
- OPSSHIELD
- Products
- cPGuard 5.88.12-5.88.19 and cPGuard 5.88.25
- Published
- Status
- Open
Call: Patch now, then rotate. cPGuard is a firewall and malware scanner for Linux hosting servers. On Nov 2 its own update channel delivered a backdoor. OPSSHIELD, the vendor, says an attacker used stolen credentials to get into its update CDN at 02:06 UTC and pushed a malicious script out as cPGuard 5.88.12 through 5.88.19. The fix is 5.88.25. Updating removes the backdoor. It doesn’t un-steal anything the script already collected.
What breaks: Your trust model, mostly. According to OPSSHIELD, the script dropped a backdoor shell and collected:
/etc/shadowand/etc/passwd- root’s MariaDB/MySQL config (
my.cnf) - root’s shell history
- root’s SSH
authorized_keysandknown_hosts
It uploaded the haul to OPSSHIELD’s own licensing server, under a compromised account, for the attacker to pick up later. OPSSHIELD caught it within 12 hours and confirms the attacker retrieved some of it. Its preliminary estimate is 32 collected files, one per customer server. That counts confirmed retrievals, not servers hit. Because servers check for updates on a schedule, some never ran the script.
Who’s hit: Any server that installed 5.88.12 through 5.88.19 on Nov 2, including servers that have since moved to 5.88.25. Check the update history:
grep 'Successfully updated' /opt/cpguard/logs/install_log
Any version from 5.88.12 to 5.88.19 in there means the server installed a bad update. OPSSHIELD says to treat it as potentially compromised. A clean or missing log doesn’t prove the server is fine.
What to do:
- Update everywhere:
cpgcli update --start, then confirmcpgcli --versionshows 5.88.25 or later. - If an affected version was installed: from a trusted recovery environment, reset passwords for root and every local account that has one. Change those passwords anywhere else they were reused. The hashes are one-way, but weak passwords crack offline.
- Rotate the rest: database passwords, S3 access keys, DigitalOcean tokens, and any secret sitting in root’s shell history.
- Replace root’s SSH keys: generate new keys to replace the ones in
/root/.ssh, and remove the old public keys from every system that trusts them. - Look for the leftovers: the script was
cpguard-v58812-i91511.sh. The backdoor was/var/tmp/.cpg91511_sh, collected data went in/var/tmp/.cpg91511/, and the archive wasloot.tgz. 5.88.25 removes them, so not finding them proves nothing.
OPSSHIELD isn’t recommending an OS rebuild for now, and calls that assessment provisional. It’s also pushing an update that removes its own support-access keys from customer servers. If you find other signs of compromise, or can’t establish that a server is intact, OPSSHIELD says a rebuild may be appropriate. On a server whose security agent was the intruder, we’d lean that way.
Sources: OPSSHIELD advisory (opens in a new tab), DirectAdmin forum (opens in a new tab), SecurityOnline (opens in a new tab).