Hackers Hijacked cPGuard's Update Channel and Turned a Linux Server Security Tool Into a Root Password Thief

Hosting companies install cPGuard on their Linux servers to keep attackers out. For about twelve hours from early Monday, the tool's own automatic updates were the attack.

At 02:06 UTC on 2 November, an attacker using compromised credentials got into the update distribution infrastructure of OPSSHIELD, the company behind cPGuard, and pushed a malicious script out through the official update channel. OPSSHIELD says in its advisory that it is still investigating how those credentials were obtained.

What the update did

The poisoned releases were cPGuard versions 5.88.12 through 5.88.19. Once running, the script installed a backdoor shell and gathered some of the most sensitive files on a server: /etc/shadow and /etc/passwd, the root MariaDB or MySQL configuration, root's shell history, and root's SSH authorization and known hosts files.

Then it did something brazen. It uploaded the haul to OPSSHIELD's own licensing server, under a compromised account, where the attacker could collect it later.

The shadow file holds one way password hashes rather than plaintext. That is less comfort than it sounds, because weak or reused passwords are far easier to crack offline once the hashes are out.

OPSSHIELD caught the attack within 12 hours of the updates going out. Servers check for updates at intervals, so some never ran the script, and not every file was necessarily taken from every server that did.

32 servers, for now

In a 3 November update, the company estimated that the attacker retrieved 32 collected files, each matching one customer server. It stressed that this is a preliminary count of confirmed retrieval, not the number of servers potentially affected. Beyond the data theft and the backdoor, it had found no other malicious activity, which it says does not rule out activity it has yet to detect.

Defenders can look for the script cpguard-v58812-i91511.sh, a backdoor shell at /var/tmp/.cpg91511_sh, and a collection directory at /var/tmp/.cpg91511 holding an archive called loot.tgz.

OPSSHIELD secured the compromised account, cleared its infrastructure credentials, stopped distribution and released cPGuard 5.88.25, which removes the known backdoor and staged files. What it cannot do is take back credentials already copied. Any server that installed 5.88.12 through 5.88.19 should be treated as potentially compromised, it says, which means resetting root and local passwords from a trusted recovery environment, rotating database passwords, S3 keys, DigitalOcean tokens and anything else sitting in root's shell history, and replacing root SSH keys. It is not routinely recommending full rebuilds, though it calls that view provisional. As a precaution, it is also pushing an update that strips its own support access keys from customer servers.

No off switch

On the DirectAdmin forum, one admin posted logs showing cPGuard updating itself to 5.88.12 as root at 02:16, with the root SSH key files read in that same second. Another put the problem bluntly: "the moment a special update gets forced the game is over." That admin suggested turning off automatic updates. A third pointed out that cPGuard does not appear to offer that option.

That is the uncomfortable part. Trusted third party code keeps becoming the way in, just as it did when attackers poisoned a DebugBear monitoring script and drained more than $2 million from Polymarket traders days earlier. In cPGuard's case, the code had root on every server it protected, and the customers had no way to say no.

Some offers on this page may be paid placements or contain affiliate links.