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/shadow and /etc/passwd
  • root’s MariaDB/MySQL config (my.cnf)
  • root’s shell history
  • root’s SSH authorized_keys and known_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 confirm cpgcli --version shows 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 was loot.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).

Sources

More from October 2026 patch cycle