Nikolay Georgiev · November 3, 2026

cPGuard Update Compromise: What Linux Admins Must Do

OPSSHIELD says a compromised cPGuard update channel delivered malware to Linux servers. Administrators should install clean version 5.88.26, then check for exposed credentials and affected systems.

A security update is supposed to close a door. For some cPGuard users, one opened it instead.

OPSSHIELD says attackers compromised its billing and licensing server, then used a stolen key to distribute a fake cPGuard update. It ran as root and collected sensitive files. The vendor reports about 2,950 servers ran the update, and information from about 7,900 billing-portal accounts was copied. These figures are vendor-reported and not independently verified.

Illustration of the cPGuard update-channel compromise
Image via The Hacker News.

What OPSSHIELD says happened

OPSSHIELD’s incident disclosure identifies cPGuard versions 5.88.12 through 5.88.19 as affected. Treat servers with cPGuard installed and online between 02:08 and 03:20 UTC on November 2 as exposed.

The script read local password files, root SSH files, MySQL configuration where present, and root shell history. On a small number of servers, it also accessed cloud-storage keys. OPSSHIELD identifies 5.88.26 as the clean release. Earlier reports mentioned 5.88.25, so follow the vendor’s latest update guidance.

What administrators should do now

Check your version with cpgcli --version, update to the latest release, and follow OPSSHIELD’s response guidance:

  • Reset root and local user passwords, database passwords, and other secrets accessible from the server.
  • Replace root SSH keys, remove old trusted keys from other systems, and review authorized_keys.
  • Rotate cloud-storage keys if /root/.s3cfg is present.
  • Check that /etc/cron.d/i93677, /var/tmp/.i93677/, and /var/tmp/.cpg91511_sh are gone. Remove them if they remain.
  • Reset your OPSSHIELD billing-portal password and enable two-factor authentication.

If OPSSHIELD told you an attacker logged in to your server manually, rebuild from a clean backup taken before November 1. Also review connected systems and shared credentials. Our guide to third-party risk explains why a supplier’s security is part of yours.

If you’re unsure what to check first, a clear incident checklist beats rotating passwords at random. See what to do in the first hour after an incident.


Book a 15-minute incident-response check
We’ll help you identify the first systems and credentials to review, with no obligation.