Anyone who runs cPGuard on a Linux server has to treat that machine as possibly compromised. On 2 November an attacker used stolen credentials to reach the update distribution infrastructure behind cPGuard and pushed a malicious script through the product's own update channel, according to the vendor, OPSSHIELD.
What happened
The intrusion started at 02:06 UTC on 2 November. With access to the update CDN, the attacker was able to serve a script as part of normal cPGuard updates, covering builds 5.88.12 through 5.88.19.
That script ran with the privileges cPGuard has, which is root on the host. It collected local data and pushed it to OPSSHIELD's own licensing server under a compromised account, where the attacker could collect it later. OPSSHIELD says some of that data was retrieved.
Reporting on the incident states the script took /etc/shadow and /etc/passwd, the root MariaDB or MySQL configuration, root's shell history, and root's SSH authorised-keys and known-hosts files. OPSSHIELD detected the activity within 12 hours, cut distribution and shipped 5.88.25, which removes the backdoor and the files the script staged.
Who is affected
Any Linux server that installed a cPGuard update between 5.88.12 and 5.88.19, whether or not it has since been updated.
- Hosting providers running cPGuard across shared or reseller servers, where one poisoned build can land on every machine in the fleet.
- Businesses whose website or mail sits on a cPanel-style host that manages its own server security.
- Any server where cPGuard updates run automatically, which is the default posture for a security agent.
What to do now
Assume the box was touched, upgrade to 5.88.25 or later, then rotate every credential that lived on it. Fixing the agent does not undo a hash dump.
- Check the update history:
grep 'Successfully updated' /opt/cpguard/logs/install_log. Any entry between 5.88.12 and 5.88.19 means an affected build was installed. - Upgrade to 5.88.25 or later immediately, then confirm the version on each host rather than trusting the panel.
- Rotate root and panel passwords, the MySQL or MariaDB root password, and every SSH key authorised on the server. Replace keys, do not just re-permit them.
- Read root's shell history and authorised-keys file for entries you cannot account for, and check for outbound connections or scheduled jobs the script may have left behind.
What this means for South African businesses
Most South African SMEs do not install cPGuard themselves, but a large share of local websites and mail domains sit on hosting accounts where the provider does. If your site is on a shared or managed Linux host, the question to ask this week is which security agent runs on that server and whether it installed an update on 2 November.
The uncomfortable part is structural: a security agent holds root, and it updates itself over the network. Compromise the update channel and you bypass every integrity check the agent would otherwise apply to the rest of the system, so the tool that is supposed to detect a backdoor is the thing that installed it.
Read the vendor advisory: OPSSHIELD cPGuard update channel compromise.