• Check: grep 'Successfully updated' /opt/cpguard/logs/install_log. Any entry for 5.88.12 through 5.88.19 means the server installed an affected update; treat it as potentially compromised even if it now runs 5.88.25+. A missing or empty log does not prove the server is clean.
• Fix: cpgcli update --start, then confirm cpgcli --version is 5.88.25 or later.
• Rotate (per OPSSHIELD): reset passwords for root and every password-enabled local account from a trusted environment; rotate database passwords, S3 keys, DigitalOcean tokens and any secret in root's shell history; replace SSH keys under /root/.ssh and remove the old public keys everywhere they're trusted.
• Known indicators: script cpguard-v58812-i91511.sh; backdoor /var/tmp/.cpg91511_sh; staging directory /var/tmp/.cpg91511 with loot.tgz. Their absence after cleanup doesn't prove the script never ran.
• Still unknown: how the CDN credentials were obtained and the full number of servers whose data was taken. OPSSHIELD is also pushing an update that removes its own support-access keys from customer servers as a precaution.

Security agents that run as root and auto-update are high-value targets. Where you can, pin or stage their updates rather than letting every server pull a new build within minutes of release.