OpsShield says hijacked cPGuard update channel delivered a backdoor and credential-stealing script to Linux servers

TLDR

• OpsShield says an attacker used compromised credentials on 2 November to push a malicious script through cPGuard's update channel.²
• Versions 5.88.12 to 5.88.19 carried a backdoor and script collecting password hashes, root database config, shell history and SSH files.²
• A spokesperson told BleepingComputer 2,946 servers were affected; sources differ on whether 5.88.25 or 5.88.26 is the clean version.¹²³

OpsShield, the developer of the cPGuard Linux web-server security suite, says an unidentified attacker used compromised credentials at 02:06 UTC on 2 November 2026 to gain unauthorised access to its update distribution infrastructure (CDN) and distribute a malicious script through the cPGuard update channel.² The company says the affected versions were 5.88.12 through 5.88.19, that it detected the attack within 12 hours of those updates launching, and that it is still investigating how the credentials were obtained.² Because update checks occur at intervals, OpsShield says some servers may not have run the script.² BleepingComputer reports that cPGuard offers malware scanning, firewalls and attack protection, and is commonly used by hosting firms and server administrators alongside panels such as cPanel, DirectAdmin and Plesk.¹

OpsShield's advisory says the script collected /etc/shadow and /etc/passwd, root's MariaDB or MySQL configuration, root shell history, and root's SSH authorisation and known-hosts files, and uploaded them to OpsShield's own licensing server under a compromised account for the attacker to retrieve later.² It says it has not established which files were collected from each server.² A later OpsShield disclosure also lists root SSH private keys and, on a small number of servers, cloud storage keys, and describes a hidden root shell left behind at /var/tmp/.cpg91511_sh.³ OpsShield says cPGuard 5.88.25 or later removes the known backdoor and staged files, but that credentials copied before cleanup may still be usable, so it tells administrators to reset local account passwords and rotate database passwords, S3 access keys, DigitalOcean tokens, secrets in root's shell history and root SSH keys.² It is also releasing an update to remove its own support-access keys from servers where they were added, and The Hacker News reports that OpsShield has not said whether the matching private key was exposed.²⁴

On scale, BleepingComputer reports that an OpsShield spokesperson said: "We detected 2946 servers were affected and copied the information mentioned, and our billing system database was copied over as well."¹ OpsShield's later disclosure, dated 3 November, says about 2,950 customer servers ran the fake update and that about 7,900 billing portal accounts were exposed, with name, company, postal address, email and hashed password.³ The earlier advisory had given only a preliminary estimate that the attacker retrieved 32 collected files, one per customer server, which it said was not the total number of potentially affected servers.² The Hacker News reported that OpsShield had not said how many servers installed an affected version.⁴

The two OpsShield documents describe the intrusion differently. The advisory attributes access to compromised credentials, while the later disclosure says the attacker registered a customer account under a false identity, broke into the billing and licensing server, took the keys used to publish updates, and shipped the fake update for about 70 minutes, with agents installing it between 02:08 and 03:20 UTC.²³ The disclosure adds that OpsShield's logs do not record the exact request that gave the attacker access, and names clean update 5.88.26 as the one that removes the hidden root shell, while the advisory and BleepingComputer give 5.88.25 or later as the minimum version.¹²³ Neither OpsShield document names the attacker.²³

Why it matters: an update channel for a server security tool delivered a script that collected root-level credentials, and OpsShield says credentials copied before cleanup may still be usable, so patching alone does not close the exposure.²³