Technicien qui branche des câbles réseau dans une baie de serveurs d'hébergement

cPGuard malicious update: when your web host’s security tool steals the server keys

Overnight from November 1 to 2, 2026, about 2,950 Linux servers installed an update to their security tool, as they do several times a day. Except this time, the cPGuard malicious update contained a script that copied the server’s passwords, root’s SSH keys and the MySQL root password, then left a backdoor behind. The vendor, OPSSHIELD, confirmed it in its November 3 advisory.

cPGuard is protection software for web hosting servers (often running cPanel). You may never have installed it yourself, but your web host or website provider may use it. Here’s how the attack unfolded, why a single affected server can open all your sites, and what to do depending on your type of hosting.

cPGuard malicious update: the 5-link chain

Link 1

Nov. 1

Fake customer account

The attacker signs up under a false identity and orders a free cPGuard trial.

🔗

Link 2

Nov. 1, 22:58 UTC

Billing server

Crafted requests give them control of OPSSHIELD’s billing and licensing server.

🔗

Link 3

Nov. 2, 02:04 UTC

Stolen publishing key

Using the key that publishes updates, they drop their script into the official channel.

🔗

Link 4

02:08–03:20 UTC

Installed as root

For about 70 minutes, servers checking for updates run the script with full privileges.

🔗

Link 5

Same night

Theft and backdoor

The script copies /etc/shadow, root’s SSH keys, /root/.my.cnf and command history, then installs a hidden root shell.

OPSSHIELD detected the attack within 12 hours. The attacker also copied three of the vendor’s cloud servers and the billing records of about 7,900 customer accounts (names, companies, addresses, emails and bcrypt-hashed passwords).

Why one affected server opens everything else

A security tool needs to see everything, so it runs as root. So did the fake update. And on a hosting server, a few secrets are enough to open dozens of sites:

🔑

MySQL root password + root SSH key

The two secrets copied by the script

↙ ↓ ↓ ↓ ↘

🏢

Every site’s database

readable and writable

🏢

Other servers that trust the key

reachable over SSH

🏢

Online store

orders and customers

🏢

Contact forms

personal data (Law 25)

🏢

S3 backups

if the key is in /root/.s3cfg

Root’s command history often holds passwords typed by hand: treat it as a stolen secret too.

Checking a server that runs cPGuard

If you manage your own server (VPS or dedicated) with cPGuard, or a provider does it for you, here are the checks published by the vendor:

● ● ● Linux server with cPGuard — checks

# 1. Did the server install an affected version (5.88.12 to 5.88.19)?
$ grep ‘Successfully updated’ /opt/cpguard/logs/install_log
✘ [02-11-2026 02:46:04]: Successfully updated to 5.88.12   ← treat this server as compromised
# 2. Update to the latest version, then verify
$ cpgcli update –start
$ cpgcli –version
# 3. These files left by the script must be gone
$ ls -la /etc/cron.d/i93677 /var/tmp/.i93677/ /var/tmp/.cpg91511_sh
✔ No such file or directory (for all three)

Careful: these files being gone after the update does not prove the script never ran. Neither does a missing or incomplete log. If the server installed an affected version, passwords and keys must be changed even if it’s now up to date.

What to do depending on your type of hosting

🏢

Shared hosting (cPanel at a web host)

Ask your host in writing whether it uses cPGuard and whether your servers received versions 5.88.12 to 5.88.19
Change your cPanel, FTP/SFTP and site database passwords
Change your WordPress or online store admin passwords

You don’t control the server: your job is to get a clear answer.

🖥️

VPS or server managed by a provider

Ask for the output of the grep command above and the current version
If affected: new root and local account passwords, new MySQL root password, new SSH keys
Have the old public keys removed from every server that trusts them

Ask for written confirmation of each step.

🛠️

Server you manage yourself

Run the three terminal checks
Reset passwords from a trusted recovery environment
Rotate S3 keys, cloud tokens and any secret visible in root’s history, and review authorized_keys

If OPSSHIELD tells you the attacker logged in by hand: rebuild from a backup taken before November 1.

All OPSSHIELD customers should also change their billing portal password and turn on two-factor login. For more questions to ask your host, see our article on security questions to ask your web host.

What your business should take away

Automatic updates are still a good idea, but…

🗣️ What we keep

We keep automatic updates: without them, known flaws stay open for weeks.

We know which providers have root or admin access to our systems, and we ask them how they protect their update channel.

We never reuse a server password anywhere else.

⛔ What we avoid

Plain-text passwords in scripts or in command history
A single SSH key that opens every server
Forgotten vendor “support” access in authorized_keys
Assuming a security tool can’t be the problem

This isn’t the first time a trusted provider became the way in: look back at the stolen key at ConnectWise Cloud Backup. The right answer isn’t to switch everything off, but to limit what a single stolen secret can open, and to watch what changes on your servers.

How NeoTech can help

We take inventory of the providers with privileged access to your systems, separate keys and passwords so one theft doesn’t reach everything, and our automated 24/7 monitoring with on-call technician intervention flags unusual changes: a new scheduled task, a new SSH key, a hidden file in /var/tmp. See also our cybersecurity services.

Book your free cyber check

In 30 minutes, we look with you at which providers can access your servers and website, and what should change if one of them were hacked.

👉 Book your free cyber check

Call us at 438-476-2322 or email info@neotechcloudsolutions.com.

Our office: 2572 boul. Daniel-Johnson, office 237, Laval.

Sources

Photo: Field Engineer, Pexels (Pexels licence).