"The attacker took 32 files from that server, each tied to one customer server, OPSSHIELD estimated late on November 2 UTC."
The update channel and compromised credentials
At 02:06 UTC on November 2, an attacker used compromised credentials to access cPGuard's update system and push a malicious installer, OPSSHIELD said in an advisory. The malicious script was distributed in cPGuard versions 5.88.12 through 5.88.19 before the company detected the intrusion. OPSSHIELD reports the attack was discovered within 12 hours of those versions going out and that it has cleared the infrastructure credentials used to stop further delivery of the script. The company is still investigating how the credentials were obtained.
The malicious script and its artifacts
OPSSHIELD published the names of the files the script placed on affected servers. They include the installer cpguard-v58812-i91511.sh, a backdoor shell at /var/tmp/.cpg91511_sh, a collection directory /var/tmp/.cpg91511, and an archive named /var/tmp/.cpg91511/loot.tgz. cPGuard updates beginning with 5.88.25 remove the backdoor shell and the collection directory, but OPSSHIELD warns that their absence after updating does not prove a server never ran the script.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleWhat the script collected and how sensitive it was
OPSSHIELD's analysis shows the script gathered a range of sensitive files from servers where it ran. The company listed copies of /etc/shadow and /etc/passwd; root's MariaDB or MySQL configuration file (my.cnf); root's shell history; and root's SSH authorization and known-hosts files. OPSSHIELD noted the /etc/shadow file stores one-way password hashes and that weak, common, or previously leaked passwords can be recovered from those hashes by offline guessing; even strong passwords still require resetting. Database configuration files and shell history entries, the advisory states, are not protected by hashing and may contain plaintext secrets.
Data exfiltration and OPSSHIELD's containment steps
The script uploaded collected files to OPSSHIELD's own licensing server using a compromised account, the company said, enabling the attacker to retrieve them later. OPSSHIELD has secured that account and estimates the attacker removed 32 files from that server, each tied to one customer server, as of late on November 2 UTC. The company stressed that number covers only files known to have been taken and may change; it also does not indicate how many servers in total might be affected.
So far, OPSSHIELD has not found other malicious activity beyond the backdoor and data collection, but it described that finding as provisional rather than final.
OPSSHIELD's remediation instructions for cPGuard admins
- Update each cPGuard server immediately by running: cpgcli update --start
- Confirm the installed version with: cpgcli --version and ensure it reports 5.88.25 or later; if the update fails or the version remains lower, contact OPSSHIELD Support.
- To check whether a server installed an affected update, search the update log: grep 'Successfully updated' /opt/cpguard/logs/install_log. An entry for any version 5.88.12 through 5.88.19 indicates the server installed an affected update, though the entry alone does not prove the malicious script executed or data left the server.
For any server that ran or may have run the script, OPSSHIELD advises these recovery steps:
- From a trusted recovery environment, reset the passwords for root and every other local Linux account that uses a password.
- From a trusted device, change any of those passwords that are 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 under /root/.ssh and remove the corresponding old public keys from every system that trusts them.
OPSSHIELD is not recommending a routine full OS rebuild at this time but said that stance could change as the investigation continues; admins who find other signs of compromise or cannot confirm a server is clean should request a case-by-case review from OPSSHIELD Support.
What this means for cPGuard admins, affected customers, and OPSSHIELD support
cPGuard admins must assume any server that installed one of the affected versions might be compromised: update to 5.88.25 or later, inspect the install log, and follow OPSSHIELD's reset and rotation steps. Affected customers should expect to rotate credentials and keys that may have been collected; OPSSHIELD has already removed the collected artifacts from updated installations and released a precautionary update that removes its support-access public keys where they were previously added. OPSSHIELD support remains the contact point for servers with unclear status or additional indicators of compromise.
The immediate arc of this incident is clear: a hijacked update channel delivered a targeted collection-and-backdoor script, OPSSHIELD detected and halted the rollout within hours, and the company has published concrete detection and recovery actions. Several practical questions remain open in the company's advisory: how many servers ever installed an affected build, exactly how the credentials were compromised, and whether additional data exfiltration will be discovered as the investigation proceeds.
