cPGuard: Backdoored Update Hit Linux Servers

On November 3, 2026, OPSSHIELD, the company behind cPGuard, said an attacker used its own update channel to push a backdoor onto Linux servers. Versions 5.88.12 through 5.88.19, shipped from November 2, are affected. The fixed release is 5.88.25. It matters to anyone running cPGuard, or hosted on a server that does.

What we know

How it started: according to OPSSHIELD's advisory, at 02:06 UTC on November 2 an attacker used compromised credentials to access the network the company uses to distribute updates. Versions 5.88.12 to 5.88.19 went out from there.
What the script did: the advisory says it installed a backdoor and collected sensitive server files: system account and password hash files (/etc/shadow and /etc/passwd), root's database configuration (my.cnf), root's shell history and root's SSH key files.
Where the data went: OPSSHIELD says the script uploaded it to one of its own licensing servers through a compromised account, where the attacker picked it up.
How many: the company's preliminary estimate is 32 retrieved files, each from one customer server. The advisory stresses this is not the total number of servers that may have installed the affected versions.
Detection: OPSSHIELD says it caught the attack within 12 hours of the affected releases, cleared its infrastructure credentials and secured the compromised account.
Still unknown: how the credentials were obtained, which data left each server and whether there was further malicious activity. The company says it has found none so far, but calls its assessment provisional.
Support keys: as a precaution, OPSSHIELD is shipping an update that removes its support-access keys from servers where they had been added.

What changes and what doesn't

It changes things for anyone running a dedicated server or VPS with cPGuard: if it received one of those versions, treat it as compromised even after updating.
Updating is not enough: per the advisory, 5.88.25 removes the backdoor and the script's leftovers, but it cannot undo what was already taken. Missing files afterwards do not prove the script never ran.
Rebuilding is not the default: OPSSHIELD does not recommend a full rebuild as a routine response. If you see other signs of compromise or cannot establish the server is clean, it asks you to contact support for a case-by-case review.
Nothing changes if you don't use cPGuard. This is not a WordPress, Drupal or control panel flaw: it is a tampered update of one specific tool.

How to tell if you're affected

If you run your own server or VPS:

Check for cPGuard and its version. The advisory uses `cpgcli --version`. You need 5.88.25 or later.
Update now with the vendor's command, `cpgcli update --start`. If it fails, contact their support.
Check whether an affected version was installed. The advisory suggests `grep 'Successfully updated' /opt/cpguard/logs/install_log`. Any entry from 5.88.12 to 5.88.19 means it was installed. A missing or incomplete log rules nothing out.
If it was, rotate everything the script could read. From a trusted environment: root and local account passwords, database passwords, storage and API keys found in root's history, and root's SSH keys (removing old public keys from systems that trust them), as the advisory asks.
Then check your websites. If you change a database password, update each site's configuration file too (wp-config.php in WordPress, settings.php in Drupal), or the site will stop loading.

If your site is on someone else's hosting:

Ask in writing: "Do your servers run cPGuard? Did any install versions 5.88.12 to 5.88.19 on November 2? What have you rotated since?"
If the answer is yes, rotate your own credentials: control panel, FTP or SFTP and, with your host, your site's database password. Also review your WordPress or Drupal admin users for accounts you don't recognize.

Sources

Updates: if OPSSHIELD explains how the credentials were stolen, revises the number of affected servers or recommends rebuilding, it will be added here with a link.