An attacker used compromised credentials to access the cPGuard update system at 02:06 UTC on November 2, according to an advisory from OPSSHIELD, the security tool’s maker. The compromised channel distributed a malicious script with cPGuard versions 5.88.12 through 5.88.19, potentially affecting Linux servers that installed those releases.
The script installed a backdoor and gathered files including password hashes from /etc/shadow, account details from /etc/passwd, root’s MariaDB or MySQL configuration, shell history, and SSH authorization and known-hosts files. It sent the collected data to an OPSSHIELD licensing server using a compromised account. The company says the attacker later took 32 files from that server, each associated with a customer server. That figure reflects files known to have been taken and does not establish the total number of potentially affected servers.
OPSSHIELD detected the attack within 12 hours of the affected versions being released, secured its infrastructure credentials and blocked further delivery of the script. The company has not said how many servers installed an affected version and is still investigating how the attacker obtained the credentials and what data was taken from each server. It said it has found no other malicious activity so far, while noting that its investigation is ongoing.
Administrators should update every cPGuard server by running `cpgcli update --start`, then confirm with `cpgcli --version` that it is running version 5.88.25 or later. OPSSHIELD says those releases remove the backdoor and files left by the script. However, an update does not establish that a server was never compromised, and copied credentials may remain usable.
To check update logs, administrators can search with `grep 'Successfully updated' /opt/cpguard/logs/install_log`. An entry for a version from 5.88.12 through 5.88.19 means the server installed an affected update, but does not prove that the script ran or that data was taken. A missing, incomplete or clear log may not rule out exposure; OPSSHIELD advises contacting support if the server’s status is uncertain.
For servers where the script ran or may have run, the company recommends resetting root and other local password-based account credentials from a trusted recovery environment. Passwords reused on other systems should also be changed from a trusted device. Administrators should rotate database passwords, S3 access keys, DigitalOcean tokens and secrets recorded in root’s shell history, and replace SSH private keys stored under /root/.ssh while removing their matching old public keys from systems that trust them.
OPSSHIELD is not currently recommending a routine full reset or operating system rebuild, though it says that advice could change as the investigation progresses. It recommends a case-by-case review for systems with other signs of compromise or whose status cannot be confirmed. The company is also preparing a separate precautionary update to remove its support-access SSH keys from servers where customers previously enabled that feature. It has not said whether the corresponding private key was exposed.
Sources: The Hacker News.