cPGuard: a hijacked update reached 2,946 servers
OPSSHIELD says a hijacked cPGuard update on November 2 reached 2,946 Linux servers, copying password hashes, database settings, and SSH trust files, and that its own billing database was copied too. Install 5.88.25 or later, then rotate every secret the update cannot revoke.
By ZeroDay Times Desk3 min read
OPSSHIELD, the company behind the cPGuard Linux web-security suite, says an attacker entered its update-distribution network on November 2, 2026, at 02:06 UTC. The entry used credentials the company has not yet traced. That access shipped a malicious script down the ordinary cPGuard update channel. Builds 5.88.12 through 5.88.19 carried it. OPSSHIELD says it found the distribution and stopped it within 12 hours, and that it has since rotated its own infrastructure credentials.
cPGuard is the malware scanner, firewall, and attack-protection package that hosting firms and server administrators run beside cPanel, DirectAdmin, and Plesk. Namecheap offers it on VPS and dedicated servers. A security product that updates itself is a trusted publisher. For those hours, the publisher was the intruder.
A spokesperson told BleepingComputer that 2,946 servers were affected and that the classes of data the script sought were copied. The company’s billing-system database was copied as well. An earlier vendor estimate put the files then known to have been pulled back from the licensing server at 32, one file for each customer server in that tally, and said the count could change. The 2,946 figure came later, and it counts servers. The two numbers measure different things.
Servers ask for updates on their own schedule. OPSSHIELD says some hosts may never have received the bad builds. A machine that stayed on an older release through the window is in a different bucket from a machine that installed 5.88.12 through 5.88.19. Both still need a person to read the version.
What left the server
On hosts that ran the script, OPSSHIELD says the collection included Linux password hashes, the root configuration for MariaDB or MySQL, root’s shell history, and the SSH authorization and known-hosts files for root. Hashes can be tested offline later. A database password or a cloud token sitting in a shell history is already readable. The script sent the collection to OPSSHIELD’s own licensing server through a compromised account, and the attacker retrieved it from there. The company says that account is now locked down.
OPSSHIELD says it has found no further malicious activity past the backdoor and the collection, and that this reading is provisional. Version 5.88.25 and later remove the backdoor and the staged files. Removal leaves stolen secrets valid. A password, a database credential, or an SSH key that was copied keeps working until it is changed.
The company is shipping a further update, as a precaution, to remove support-access keys it had placed on customer servers for troubleshooting. It has not said whether the private half of those keys was exposed. Support access is a switch customers enable so OPSSHIELD staff can help. After this incident, that switch should be a new decision.
What administrators should do
Move every cPGuard server to 5.88.25 or later and confirm the version the host reports. If the update fails, use OPSSHIELD support. Take the package from the vendor channel you already trust.
A server whose install log shows any build from 5.88.12 through 5.88.19 should be treated as having run the script. A missing or incomplete log does the same job of keeping the host on the list. OPSSHIELD has told administrators who cannot tell to open a support case.
From a recovery environment you trust, reset the password on root and on every local account that still uses a password. Where those passwords were reused, change them on the other systems in the same pass. Rotate database passwords, object-storage keys, hosting-provider tokens, and anything that may have been typed into root’s shell. Replace the SSH keys stored for root, and remove the old public keys from every machine that trusted them.
Watch the commercial account with OPSSHIELD. The company says the billing database was copied. A changed invoice or a new login on that account belongs to this incident.
OPSSHIELD is withholding a blanket order to reinstall the operating system, and it says that position can change. A host with any other sign of compromise, or a host nobody can vouch for, needs a case review with the vendor. A rebuild belongs in that review.
Hosting firms that turn cPGuard on for tenants should find those machines and pass along the version check and the rotation. The panel may be cPanel, DirectAdmin, or Plesk. The failure was one layer above the panel, in the security product’s update.
This briefing relies on public reporting by BleepingComputer and The Hacker News, and on OPSSHIELD’s advisory. It does not include exploit procedures.
Corrections and tips:[email protected]

