cPGuard Update Hack: What Site Owners on Affected Servers Must Do

The cPGuard update hack began at 02:06 UTC on 2 November 2026, when an attacker used stolen credentials to push a data-stealing script through the update channel of OpsShield's Linux server security suite. OpsShield says 2,946 servers were affected. If your site lives on one of them, someone may already have your database password, and updating cPGuard does not change that.

Does the cPGuard update hack affect my site if I never installed it?

It can. cPGuard is a Linux web-server security suite (malware scanning, firewall, attack protection) that hosting firms and server administrators commonly run alongside cPanel, DirectAdmin and Plesk. Namecheap offers it on its VPS and dedicated servers. A WordPress or Joomla site can run behind it without the owner ever seeing its name.

In an alert published the day after the attack began, OpsShield said the attacker logged into its update CDN with compromised but legitimate credentials. How they were obtained, and by whom, is unclear. Customer servers downloaded the poisoned builds during normal update checks. No flaw in cPGuard’s code was exploited, no CVE has been assigned as of publication and no indicators of compromise have been published. Only root can read the files the script took; we covered why root access on a hosting box matters when a cPanel account became a root shell.

Which cPGuard versions carried the malicious update?

Versions 5.88.12 through 5.88.19. OpsShield says it stopped distribution within 12 hours of the first push but has not given an exact stop time. Because cPGuard checks for updates at set intervals, a server that did not check in during that window may never have run the script, and OpsShield cannot confirm which servers did.

An OpsShield spokesperson told BleepingComputer that the attacker also copied the company’s billing-system database. The vendor has not said which customer details it held.

What could the script have copied from the server my site lives on?

OpsShield lists four root-owned targets:

• Linux password hashes for system accounts.
• MariaDB/MySQL root configuration, which can open every database on the server, including your site’s.
• Root shell history, where passwords typed on the command line end up.
• Root SSH authorized_keys and known_hosts files: who can log in and which machines the admin connects to.

The script uploaded the data to OpsShield’s own licensing server through a compromised account, and the attacker retrieved it the same way. Our read: firewalls usually allow a security tool to reach its vendor’s licensing server, so this route was unlikely to trigger outbound alerts. The attacker pulled 32 files per customer, contents not yet established, and the update also installed a backdoor.

Is cPGuard 5.88.25 enough, or do passwords still need to change?

No. Version 5.88.25 or later removes the backdoor and staged files, but copied credentials stay valid until someone changes them. OpsShield tells customers to reset passwords and rotate database credentials, cloud secrets and SSH keys. A stolen SSH key keeps working until its public half is removed from authorized_keys, so a new keypair is only half the job. The full routine is in what to check after a host-side password incident. OpsShield also plans a separate update that removes previously installed support-access keys.

From our hack recovery work: reinfection after a vendor-side breach usually comes from access nobody revoked, such as a forgotten database user, an extra SSH key or a cron job added during the compromise window.

What should I ask my host before I assume the site is clean?

Get written answers to four questions:

1. Was cPGuard on my server at 5.88.12 through 5.88.19 at any point after 02:06 UTC on 2 November?
2. Do the update logs show that an affected build was downloaded and run?
3. Is the server now on 5.88.25 or later, and will you apply the support-key removal update?
4. If an affected build ran, will you rebuild the server rather than just upgrade the package?

If you manage your own VPS, check the installed cPGuard version and your update history for 2 November.

If the answer is yes or unknown, rotate now: CMS admin passwords and WordPress salts, the database password in wp-config.php or Joomla’s configuration.php, panel, SFTP and SSH credentials, plus any payment, SMTP or storage API keys on the server. Delete any authorized_keys entry you cannot identify. If your host will not answer, assume exposure and consider moving to a clean server. Then watch for new admin users, unfamiliar PHP files in uploads and unexpected outbound connections. File monitoring such as SiteGuarding Antivirus flags those changes.

Do I need to tell my own customers?

Possibly. If your database holds customer records and an affected build ran, the stolen MySQL root configuration could have opened that data. Under GDPR, for example, a notifiable breach must be reported to the regulator within 72 hours of becoming aware of it. Keep a record of what your host tells you and when. If you buy cPGuard directly from OpsShield, treat any email about this incident with suspicion and do not follow its links to reset credentials.

FAQ

Did every cPGuard server download the malicious script?

Not necessarily. Servers that did not check for updates during the window of up to 12 hours may never have received it, so ask your host to check the update logs.

Was a CVE assigned to the cPGuard update compromise?

No CVE has been assigned as of publication. The attacker hijacked the update channel rather than exploiting a software flaw.

What if my host will not tell me which cPGuard version was installed?

Assume the server was exposed and change every credential tied to it.

If your host confirmed that an affected cPGuard build ran on your server and you are not sure what was left behind, we can get your site checked and protected while you rotate credentials.