cPGuard Update Attack Backdoored Linux Servers and Stole Credentials
OPSSHIELD said an attacker compromised the cPGuard update system on November 2 and used it to send a malicious script to customer Linux servers. The script installed a backdoor and collected password hashes and sensitive files. The affected update versions were 5.88.12 through 5.88.19, while cPGuard 5.88.25 and later removes the backdoor and files left by the script.
OPSSHIELD said the attacker entered its update system at 02:06 UTC using compromised credentials. The company detected the attack within 12 hours of the affected versions being distributed, cleared its infrastructure credentials and stopped the script from reaching additional servers. It has not said how many servers installed an affected version, because cPGuard checks for updates at intervals and some systems may not have run the script.
The script collected /etc/shadow and /etc/passwd, root's MariaDB or MySQL configuration, root's shell history and root's SSH authorization and known-hosts files, according to OPSSHIELD. The company said the collected material was uploaded to an OPSSHIELD licensing server through a compromised account. It estimated that the attacker took 32 files from that server, each linked to one customer server, but said the figure may change and does not establish the total number of affected systems.
Administrators should check the cPGuard update log for entries showing versions 5.88.12 through 5.88.19, OPSSHIELD wrote in its advisory. A matching entry does not prove that the script ran or that data left the server, but the company says the system should still be treated as potentially compromised. A missing or incomplete log also cannot establish that the server was unaffected.
OPSSHIELD asks administrators to run cpgcli update –start on every cPGuard server and verify with cpgcli –version that the result is 5.88.25 or later. For any server where the script ran or may have run, the company advises resetting root and other local Linux passwords from a trusted recovery environment, changing reused passwords on other systems, rotating database passwords, S3 access keys and DigitalOcean tokens, and replacing SSH private keys stored under /root/.ssh. Matching old public keys should be removed from systems that trust them.
OPSSHIELD is not recommending a routine operating-system rebuild, although it said that could change as the investigation continues. The company has found no other malicious activity so far, but said that finding is not final. It also has not said whether the private key corresponding to its earlier support-access key was exposed.