OPSSHIELD, the vendor of the cPGuard server security suite, says an attacker pushed a malicious script to customer servers through cPGuard’s own update channel on 2 November 2026. Its disclosure of 3 November puts the number of servers that ran the fake update at about 2,950. If a server installed cPGuard 5.88.12 to 5.88.19, treat it as compromised, update, and rotate every root secret.
OPSSHIELD says the script ran as root. It sent out the password hashes in /etc/shadow, root’s SSH keys, the MySQL root file /root/.my.cnf and root’s shell history. On a small number of servers it also took /root/.s3cfg, which holds cloud storage keys.
| cPGuard version | Status | Source |
|---|---|---|
| 5.88.12 to 5.88.19 | Received the malicious script | OPSSHIELD advisory |
| 5.88.20 to 5.88.24 | Status not stated in either notice | OPSSHIELD advisory and disclosure |
| 5.88.25 or later | Minimum fixed build in the first advisory | OPSSHIELD advisory |
| 5.88.26 | Clean update named in the later disclosure | OPSSHIELD disclosure |
Why Do OPSSHIELD’s Two Notices Differ?
The first advisory says the attacker used compromised credentials on the update distribution network. It reported that the attacker had retrieved 32 collected files, which it called a preliminary figure and not the total. The later disclosure traces a longer path.
According to that disclosure, the attacker registered a customer account under a false identity on 1 November and ordered a free trial. After studying the licensing traffic, the attacker reached command execution on the billing and licensing server at 22:58 UTC. A stolen access key then let the attacker upload a fake update between 02:04 and 02:09 UTC on 2 November, and agents installed it from 02:08 to 03:20 UTC.
The disclosure adds that about 7,900 billing accounts exposed names, companies, postal addresses and emails, with passwords stored as bcrypt hashes. OPSSHIELD says it revoked the key, rotated its own credentials and is rebuilding the affected servers. In our reading the later disclosure overrides the first advisory where they differ, so the steps below follow it.
What Should Hosting Admins Do Today?
- Update cPGuard to the latest build. The first advisory named 5.88.25 as the minimum and the later disclosure names 5.88.26 as the clean update, so we would confirm 5.88.26 or later.
- Search the update history for any install between 5.88.12 and 5.88.19. OPSSHIELD says a missing log does not prove a server was untouched.
- Look for the vendor’s indicators:
cpguard-v58812-i91511.sh,/var/tmp/.cpg91511_sh,/var/tmp/.cpg91511/,/var/tmp/.i93677/and/etc/cron.d/i93677. OPSSHIELD says a follow-up update removes the scheduled task, so delete it by hand if you find it. - From a trusted machine, change the root password and every local user password. Generate new root SSH keys and remove the old public keys from each server that trusted them.
- Change the MySQL root password, and rotate every token, password or key that appears in root’s shell history or in
/root/.s3cfg. Treat any server that an exposed server’s keys could reach as exposed until its keys are replaced. - Reset your manage.opsshield.com password and enable two-factor login.
- Rebuild a server from a backup taken before 1 November if OPSSHIELD told you the attacker logged in by hand. The first advisory did not recommend a routine rebuild and called that view provisional.
How Does This Fit the Wider Supply Chain Pattern?
A security suite with root rights and an automatic update channel is the kind of tool an attacker wants to own. Here the weak point sat in the vendor’s billing system, not in the product code, which is the pattern of the Compromise Software Supply Chain technique. The entry through a web application matches Exploit Public-Facing Application. Our supply chain attack entry explains the model, and the ConnectWise case shows a similar vendor-side compromise.
What Is Still Open?
OPSSHIELD says it is still investigating how the first credentials were obtained, and it does not name an actor. It also says two possible entry points on the billing application were patched because the exact request is not in its logs. We will update this post if the vendor revises its figures or its cleanup guidance.