On November 2, an attacker compromised the update channel of cPGuard, a security tool for Linux web servers, and used it to distribute a malicious script that installed a backdoor and collected password hashes and other root-level data on servers where it ran. OPSSHIELD, which makes cPGuard, advises administrators to treat any server that installed versions 5.88.12 through 5.88.19 as potentially compromised and to update every server to version 5.88.25 or later.
According to OPSSHIELD’s advisory, the attacker gained access to the company’s update distribution infrastructure at 02:06 UTC using compromised credentials. The company detected the attack within 12 hours of the affected updates going out. Because cPGuard checks for updates at intervals, some servers may never have run the script.
cPGuard combines a malware scanner, automatic cleanup of infected CMS files and a web application firewall. OPSSHIELD offers it for cPanel/WHM, DirectAdmin, Plesk, other control panels and standalone servers, and markets it to hosting companies and small businesses.
What the Script Collected
The advisory lists four types of data the script collected, though not necessarily from every server:
- the system account files /etc/shadow and /etc/passwd,
- the root MariaDB/MySQL configuration file, my.cnf,
- root’s shell history,
- root’s SSH authorization and known-hosts files.
The /etc/shadow file holds one-way password hashes, not plaintext passwords. OPSSHIELD notes that simple, common or previously exposed passwords are easier to recover from them offline, and that password resets remain necessary.
The script uploaded the data to OPSSHIELD’s own licensing server under a compromised account, from where the attacker could retrieve it later. In an update on November 3, OPSSHIELD estimated that the attacker had retrieved 32 collected files, each corresponding to one customer server. The company calls this a preliminary estimate of confirmed retrieval, not the total number of potentially affected servers.
Beyond the data collection and the backdoor installed by the script, OPSSHIELD has not identified other malicious activity so far. It describes that finding as preliminary as well.
Update cPGuard, Then Rotate Credentials
OPSSHIELD asks administrators to run cpgcli update --start on every cPGuard server and to confirm with cpgcli --version that it reports 5.88.25 or later. That version removes the known backdoor and the files the script staged, but credentials copied before the cleanup may still be usable. To check whether a server installed an affected update, the advisory points to the update history:
grep 'Successfully updated' /opt/cpguard/logs/install_log
Any entry from 5.88.12 through 5.88.19 means the server should be treated as potentially compromised, even if it now runs a fixed version. A missing or incomplete log does not prove the server was unaffected. The advisory also lists these indicators of the attack:
- malicious script: cpguard-v58812-i91511.sh,
- backdoor shell: /var/tmp/.cpg91511_sh,
- collection directory: /var/tmp/.cpg91511,
- staged archive: /var/tmp/.cpg91511/loot.tgz.
Because the update removes the backdoor shell and the collection directory, the absence of these files afterwards does not show whether the script ran. For servers that installed an affected version, the advisory recommends that administrators:
- reset the passwords of root and all other password-enabled local accounts from a trusted recovery environment,
- change passwords reused on other systems,
- rotate database passwords, S3 access keys, DigitalOcean tokens and any secrets recorded in root’s shell history,
- replace SSH private keys stored under /root/.ssh and remove the old public keys from every system that trusts them.
OPSSHIELD is not recommending a full server rebuild as a routine response, but it calls that assessment provisional and advises contacting its support where a server’s integrity cannot be established.
As a further precaution, OPSSHIELD has released version 5.88.26, which revokes its support access on servers where it was enabled. Its investigation continues into how the attacker obtained the credentials, what data left individual servers and how much the attacker retrieved. The company plans to publish verified findings as the investigation progresses.
