OpsShield cPGuard Supply Chain Attack Pushed Backdoored Updates to 2,950 Hosting Servers

An attacker hijacked the update channel of cPGuard, a security suite used by web hosting companies to protect Linux servers, and pushed a fake update that ran as root on about 2,950 customer servers. Vendor OpsShield says the poisoned versions, 5.88.12 through 5.88.19, copied password hashes, root SSH keys, MySQL root passwords and shell history from affected machines on November 2, 2026.

The attacker also reached OpsShield’s billing and licensing server and took a copy of about 7,900 billing portal account records, including names, company names, postal addresses, email addresses and bcrypt-hashed passwords, according to the company’s incident disclosure.

From a free trial to a poisoned update in about 10 hours

OpsShield’s timeline shows how fast the intrusion moved. All times are UTC. On November 1 at 15:38, the attacker began probing the billing portal at manage.opsshield.com. Less than an hour later, they registered a customer account under a false identity and ordered a free cPGuard trial, then installed it on their own server to study how the agent talks to the licensing system. cPGuard flagged and banned the attacker twice that evening.

At 22:50, the attacker sent crafted requests to the billing portal’s callback pages and, by 22:58, could run commands on the billing and licensing server. Between 02:04 and 02:09 on November 2, they used a stolen access key to upload a fake update to OpsShield’s update storage. cPGuard agents installed it between 02:08 and 03:20. At 02:13, the attacker also made copies of 3 of the company’s cloud servers.

OpsShield says its logs do not record the exact request that gave the attacker access. The company has patched two possible entry points in the billing application and ruled out SSH, the control panel, FTP and API tokens. An earlier version of its security advisory described the entry as the use of compromised credentials against its update distribution infrastructure.

What the fake update collected

The malicious update was a short collection script, not a long-term implant, according to the vendor. On servers that ran it, it read /etc/shadow and /etc/passwd, root SSH private keys, authorized_keys and known_hosts, the MySQL root password in /root/.my.cnf where present, and root shell history. On a small number of servers it also took cloud storage keys from /root/.s3cfg.

The script left a setuid-root shell at /var/tmp/.cpg91511_sh and a scheduled task at /etc/cron.d/i93677 with files in /var/tmp/.i93677/. OpsShield’s earlier advisory said the attacker had retrieved about 32 collected files, each tied to a customer server, as a preliminary estimate, and that the full scope was still being verified.

Indicators of compromise

• Fake update scripts: cpguard-v58812-i91511.sh plus variants ending in b, c and d (SHA-256 for the first: 2c2acd988da531d133d0e17f245c49bf15781278f837543d18c95e8410eabd38)
• Staging archive: /var/tmp/.cpg91511/loot.tgz
• Attacker IP: 94.183.188.91, which sometimes sent a fake cPGuard/5.88.11 user agent
• Web shells and probe files following an i9xxxx naming pattern, such as /i90573_sh.php, and data-receiving endpoints matching *_rx.php

OpsShield also listed a gsocket backdoor and a Go implant found on its own internal server, not on customer servers, and advises checking from a trusted boot environment because the implant hides itself from standard tools.

What hosting providers should do now

Admins can check whether a server installed a poisoned build by searching the install log with grep 'Successfully updated' /opt/cpguard/logs/install_log. Any entry from 5.88.12 to 5.88.19 means the server should be treated as compromised. OpsShield says a server that was not online during the 02:08 to 03:20 window did not receive the fake update.

• Update with cpgcli update --start and confirm with cpgcli --version that the server runs 5.88.26 or later, the clean build that removes the hidden root shell.
• Confirm /etc/cron.d/i93677, /var/tmp/.i93677/ and /var/tmp/.cpg91511_sh are gone.
• Reset root and all local user passwords, generate new root SSH keys and remove the old public keys from every system that trusted them.
• Rotate the MySQL root password, any S3 or DigitalOcean keys, and every secret that appears in root’s shell history.
• Reset the OpsShield billing portal password and turn on two-factor login.

OpsShield says it revoked the stolen update key and all cloud tokens, replaced its own SSH keys and passwords, reset billing portal sessions, and is re-issuing all cPGuard license key pairs. It is rebuilding its billing, licensing and management servers from clean images. Customers the company told were accessed by hand should rebuild from a backup taken before November 1.

Why security software makes a prized target

Server security agents run with root privileges and update themselves, so one poisoned build reaches thousands of machines at once. For hosting providers, a single cPGuard server can carry hundreds of customer websites, which turns stolen root SSH keys into access far beyond one company. OpsShield said AI tools are making attacks like this faster and cheaper to run.

The incident follows a run of trusted-update compromises. Attackers recently shipped a trojanized Daemon Tools Lite build, a backdoored Claude Code extension that planted SSH keys, and a credential stealer through LiteLLM’s hijacked pipeline. A compromised third-party script also led to $2.7 million in Polymarket trader losses. Hosting control panels have been a recurring target as well, including a cPanel zero-day that gave attackers admin access without a login.

OpsShield says its investigation is ongoing and that it will update its disclosure as findings are verified.