cPGuard's clean update cannot take back a stolen key

OPSSHIELD says an attacker entered its billing and licensing infrastructure, took an update publishing key and distributed a fake cPGuard update on 2 November. The vendor estimates that about 2,950 customer servers ran it. The script ran as root, collected sensitive files and left a hidden shell and scheduled task behind.

The files it targeted included local password hashes, root SSH material, database credentials and root shell history. OPSSHIELD also reports a separate copy of billing portal account records. Its figures are vendor estimates from an investigation still in progress; they should not be read as a confirmed file-by-file loss for every customer server.

1. 1

   Check the update history. Identify cPGuard servers that installed versions 5.88.12 through 5.88.19 during the incident window. Preserve logs and note gaps before relying on the absence of an entry.

2. 2

   Install the clean release. Update to the latest cPGuard version and verify it is running. Check the vendor's listed persistence paths from a trusted environment where practical.

3. 3

   Rotate reachable secrets. Reset local passwords, replace root SSH keys and remove old authorized keys on systems that trusted them. Rotate database and cloud credentials found in configuration or shell history.

Every server that trusted a copied SSH key or credential belongs in the investigation. OPSSHIELD does not recommend rebuilding every affected customer server as a routine step, but it advises an individual assessment where integrity cannot be established or other compromise signs appear. Use that distinction in the recovery record.