OpsShield cPGuard: Update Channel Hijacked to Push Backdoor and Data Stealer

"An unidentified attacker broke into the update system for cPGuard and used the product's own autoupdate channel to send a malicious script to customers' Linux servers. cPGuard is a web-server security suite made by…"

An unidentified attacker broke into the update system for cPGuard and used the product's own autoupdate channel to send a malicious script to customers' Linux servers. cPGuard is a web-server security suite made by OpsShield. The script installed a backdoor and copied root-level secrets: password hashes, database configuration, shell history and SSH files. OpsShield confirmed the breach in a public alert on November 3. It said cPGuard versions 5.88.12 through 5.88.19 carried the script and that the attacker has already retrieved some of the stolen data. The company has not said how many customers were affected, and reports of the number disagree. Its alert gives an estimate of 32 retrieved files. A spokesperson later told BleepingComputer that 2,946 servers were affected, according to Mezha's account of that report. OpsShield has also told customers that updating removes the backdoor but does not protect any credentials that were already copied.

What Happened

OpsShield's alert, as reported by BleepingComputer and The Hacker News, says the attack began on November 2, 2026, at 02:06 UTC. At that point an attacker "used compromised credentials to gain unauthorized access to OpsShield's update distribution infrastructure (CDN)" and used it "to distribute a malicious script through the cPGuard update channel." OpsShield says it detected the compromise and stopped distribution within 12 hours, secured the compromised account and reset its infrastructure credentials.

A more detailed disclosure notice on OpsShield's website, covering its billing portal at manage.opsshield.com, gives a fuller timeline that partly differs from the first alert. It says:

On November 1, the attacker began probing the billing portal at 15:38 UTC. At 16:34 they registered a customer account under a false identity and ordered a free cPGuard trial. At 21:17 they installed the trial on their own server to study how the agent talks to OpsShield's licensing system.
cPGuard flagged and banned the attacker twice between 21:40 and 21:51 UTC.
At 22:50 the attacker sent crafted requests to the billing portal's callback pages. By 22:58 they could run commands on the billing and licensing server and had started collecting data.
Between 02:04 and 02:09 UTC on November 2, the attacker used a stolen access key to upload a fake cPGuard update to OpsShield's update storage.
From 02:08 to 03:20 UTC, cPGuard agents installed the fake update. It ran as root and copied sensitive files back to the attacker.
At 02:13 UTC the attacker made copies of three of OpsShield's cloud servers.

By this account the malicious update was live for about 70 minutes, not the "within 12 hours" window in the first alert. The two are not necessarily in conflict, since 12 hours may describe detection time rather than how long the update was live. OpsShield has not explained the difference.

The fixed version is also reported inconsistently. The Hacker News, webhosting.today, Cybersecurity News and PlainSec all say version 5.88.25 or later removes the backdoor. The company's disclosure notice names 5.88.26 as the clean update. Administrators should install whichever is the latest release.

What Was Taken

According to OpsShield's advisory, as reported across the security press, the script targeted:

/etc/shadow and /etc/passwd (Linux account files and password hashes)
root's MariaDB/MySQL configuration file (my.cnf)
root's shell history
root's SSH authorization and known-hosts files

OpsShield says it has not confirmed that every file type was taken from every affected server. The script uploaded the data to OpsShield's own licensing server through a compromised account, and the attacker later collected it from there.

Reports differ on how many servers were affected:

32 files. BleepingComputer says OpsShield's investigation shows the attacker retrieved "32 files from each customer." Webhosting.today, Cybersecurity News and Firewall Chronicle describe it differently: 32 collected files in total, each matching one customer server. They report that OpsShield called this a preliminary count of confirmed retrievals, not the total number of servers that ran the script.
2,946 servers. Mezha, citing BleepingComputer, reports that an OpsShield spokesperson said "2946 servers were affected." The same spokesperson said the attacker also copied OpsShield's billing-system database. That would put customer account and billing records at risk on top of server secrets.

OpsShield's published alerts do not reconcile the 32 and 2,946 figures. One possible reading is that about 2,946 servers ran the script and confirmed retrieval so far covers 32 of them. The company has not confirmed this. Until it does, defenders should plan around the higher number.

Why It Matters

The attack turned a security product into the way in. cPGuard combines malware scanning, cleanup of infected CMS files and a web application firewall. It runs with root privileges on hosting servers alongside cPanel/WHM, DirectAdmin and Plesk. BleepingComputer notes that Namecheap offers it on VPS and dedicated servers. Because the tool sits on servers that host many customer websites, the data from one compromised server can open the door to many downstream sites, databases and SSH-connected systems.

The stolen data is aimed at keeping access and moving to other machines. Password hashes can be cracked offline, and OpsShield warns that weak or reused passwords are especially easy to recover. Root database configuration often contains plaintext credentials. Shell history often exposes hostnames, tokens and passwords typed on the command line. Known-hosts and authorized_keys files map out which other machines a server trusts and is trusted by.

As The Hacker News and PlainSec stress, updating cleans the server but does not change what was stolen. An entry for an affected version in the update log does not prove that the script ran. A missing entry does not prove that it didn't.

The Attack Technique

OpsShield's first alert says only that the attacker used "compromised credentials" to reach its update CDN, and that how those credentials were obtained was still under investigation. Its later disclosure notice traces a full chain:

Reconnaissance as a customer. The attacker signed up under a false identity and ran a free cPGuard trial on their own server to learn how the agent talks to the licensing system.
Exploitation of the billing portal. Crafted requests to callback pages in the billing application at manage.opsshield.com let the attacker run commands on the shared billing and licensing server. OpsShield says its logs do not record the exact request that gave the attacker this access.
Theft of the update key. From that server, the attacker took the access key used to publish updates.
Malicious update. The attacker uploaded a fake cPGuard build to the update storage. Agents on customer servers fetched it automatically and ran it as root.
Exfiltration through vendor infrastructure. Stolen files went to OpsShield's own licensing server under a compromised account, so the traffic looked like normal agent-to-vendor communication.

Both accounts point to the same weakness: one server ran the customer-facing billing portal, held the licensing data and stored the update publishing keys. No outside party has attributed the attack, and OpsShield calls the attacker unidentified. No national CERT or regulator filing had been published at the time of writing.

What Organizations Should Do

Update every cPGuard server now. Install 5.88.25 or later, and preferably the newest release, since OpsShield's disclosure names 5.88.26 as the clean build. According to OpsShield, this removes the backdoor and the files the script left behind.
Check install history, but don't rely on it alone. Run grep 'Successfully updated' /opt/cpguard/logs/install_log and look for any version from 5.88.12 to 5.88.19. Treat any server with a match as compromised. Treat servers with missing or incomplete logs as possibly compromised, and contact OpsShield Support if unsure.
Rotate every credential the script could have copied. That means all local account passwords, MariaDB/MySQL root credentials, and any passwords, API tokens or keys found in root's shell history. Assume weak or reused passwords have already been cracked.
Rebuild SSH trust. Generate new host and user keys, and review root's authorized_keys for entries you didn't add. Use the known_hosts file to find other systems the attacker can now map, and check those systems for logins between November 2 and today.
Look for the backdoor and lateral movement. Review outbound connections, cron jobs, systemd units, new users and changes to binaries on affected hosts since 02:00 UTC on November 2. On systems with signs of tampering, rebuilding from known-good images is safer than cleaning them in place.
Prepare for phishing that uses OpsShield account details. OpsShield's spokesperson reportedly said the billing database was copied, so expect targeted emails that impersonate OpsShield and use real account details. Change your OpsShield portal passwords as well.

Sources: Hackers hijack cPGuard autoupdate to deploy backdoor, steal data | Security Incident Disclosure: manage.opsshield.com - OPSSHIELD | cPGuard Update Channel Hijacked to Backdoor Linux Servers and Colle... | cPGuard Breach: Update and Rotate Credentials - webhosting.today | Hackers Hijacked Linux Hosting Server Security Tool cPGuard and Use... | cPGuard malicious updates planted backdoors and exposed · PlainSec | cPGuard Update Channel Compromised to Distribute Linux Backdoor | Hackers compromise cPGuard updates to install backdoor and steal da...