OPSSHIELD reported that malicious code was distributed through the cPGuard update channel in versions 5.88.12 through 5.88.19. The company estimated that about 2,950 customer servers ran the script, which installed a hidden root-level backdoor and collected sensitive files. For administrators, an affected-version log entry is a reason to investigate, not proof by itself that the script ran or data left the server.
How the malicious update reached Linux servers
OPSSHIELD’s later incident account reportedly says an attacker created a customer account under a false identity and ordered a cPGuard trial on November 1, 2026. At 22:58 UTC that day, the attacker gained command execution on the company’s billing and licensing server. The account places the upload of the malicious script to the update system between 02:04 and 02:09 UTC on November 2, with installations on customer servers from 02:08 to 03:20 UTC.
The same account estimated that billing records for about 7,900 customer accounts were taken and copies of three OPSSHIELD cloud servers were made. An earlier estimate concerned 32 files taken from the licensing server, each tied to a customer server. That figure describes a different measure from the later estimate of servers that ran the script.
Check for an affected cPGuard update
The reported affected range is 5.88.12–5.88.19. To search the cPGuard installation log for successful updates, run:
grep 'Successfully updated' /opt/cpguard/logs/install_log
A matching entry for an affected version means that update was installed. It does not establish that the malicious script executed or that data was exfiltrated. OPSSHIELD’s reported guidance also cautions that missing or incomplete logs cannot rule out exposure. Updates may remove some artifacts, so their absence afterward does not establish that the script never ran.
Files and credentials the script reportedly targeted
The script reportedly read /etc/shadow, /etc/passwd, root’s SSH files, root’s shell history and, where present, /root/.my.cnf, which may contain database credentials. On a small number of servers, it also read /root/.s3cfg. These paths identify material to investigate; they do not mean every file or secret was present on every server.
Reported persistence indicators include a hidden setuid-root shell at /var/tmp/.cpg91511_sh, a scheduled task at /etc/cron.d/i93677 and related files under /var/tmp/.i93677/. The collection directory and archive were reported at /var/tmp/.cpg91511 and /var/tmp/.cpg91511/loot.tgz.
Update, remove artifacts and rotate secrets
The reported remediation changed over the course of OPSSHIELD’s disclosures: version 5.88.26 was said to remove the backdoor, while a separate follow-up update removes the scheduled task. The follow-up version was not specified in the account. Administrators should apply the reported remediation and check for remaining artifacts rather than treating 5.88.26 alone as proof that the scheduled task is gone.
If the script may have run, rotate local and reused passwords, database credentials, cloud credentials and SSH keys. The reported guidance also includes OPSSHIELD billing-portal credentials, reviewing authorized_keys and removing old trusted public keys. Updating cPGuard does not make secrets that may have been copied safe again.
OPSSHIELD reportedly did not recommend rebuilding every server as a routine response. It described case-by-case review and a rebuild from a clean backup when the company confirmed that an attacker had logged in manually.
