MAG212 CYBER ORIGINAL ARTICLE

cPGuard Update Channel Hijacked: What Ran on 2,950 Linux Servers and How to Rotate Every Exposed Secret

November 4, 2026 · El Mostafa Ouchen

An attacker posing as a customer broke into OPSSHIELD’s billing and licensing server, took the key used to publish cPGuard updates, and shipped a fake update. On November 2, 2026, between 02:08 and 03:20 UTC, cPGuard agents on about 2,950 Linux hosting servers installed it and ran it as root. The script copied root password hashes, SSH keys, MySQL credentials and shell history, and left a hidden root shell behind.

cPGuard is a security suite for Linux web hosting servers. Updating it removes the attacker’s files, but it does not un-leak a private key. This guide covers what happened, how to tell whether your server ran the script, and how to rotate every secret it could have taken.

Key facts

Item	Detail
Product	cPGuard (OPSSHIELD), Linux hosting security suite
Poisoned builds	5.88.12 – 5.88.19, per the vendor advisory and press reports
Install window	November 2, 2026, 02:08 – 03:20 UTC
Servers affected	About 2,950 (one early count said 2,946)
Runs as	root
Also exposed	About 7,900 billing-portal records: name, company, address, email, bcrypt password hash
Clean build	5.88.26 per the incident disclosure (the earlier advisory said “5.88.25 or later”); use the latest

How the attack unfolded

OPSSHIELD’s incident disclosure lays out the timeline. On November 1 the attacker probed the billing portal, registered a customer account under a false identity, and installed a free trial to study how the agent talks to the licensing system. That evening, crafted requests to the portal’s callback pages gave the attacker command execution on the billing and licensing server. Early on November 2, using a stolen access key, the attacker uploaded fake update scripts to OPSSHIELD’s update storage. cPGuard agents that checked in during the next 70 minutes installed one.

Stages 1–2 follow OPSSHIELD’s disclosure; stage 3 shows the downstream exposure MAG212 recommends assessing. Times UTC. MAG212 CYBER original diagram.

What the fake update took

/etc/shadow and /etc/passwd (local password hashes)
/root/.ssh: private keys, authorized_keys and known_hosts
/root/.my.cnf: the MySQL root password, where present
Root shell history, including anything typed on the command line
/root/.s3cfg cloud storage keys, on a small number of servers

The script uploaded the data to OPSSHIELD’s own licensing server under a compromised account, for the attacker to collect later. It also left a setuid root shell and a cron task. OPSSHIELD describes it as a short script, not a long-term implant. It has not said how the update key was first obtained.

Was my server affected?

If cPGuard was online and checked for updates between 02:08 and 03:20 UTC on November 2, OPSSHIELD says to assume the root-level secrets are known to the attacker. Agents poll at intervals, so some servers never received the script. The vendor also warns that a missing record in its lookup tool does not prove a server was safe.

Check for the published artifacts. Preserve the output in your case notes, and never run anything you find:

sudo stat /etc/cron.d/i93677 /var/tmp/.i93677 /var/tmp/.cpg91511_sh
sudo find / -xdev -name 'cpguard-v58812-i91511*.sh' -exec sha256sum {} + 2>/dev/null
sudo find /var/tmp /tmp -xdev -perm -4000 -type f -ls   # unexpected setuid files
sudo last -Fai | head -40                                # recent logins with IPs

A “No such file” result is not proof of safety: the clean update removes these files. Also check network and authentication logs for the attacker addresses OPSSHIELD published (94.183.188.91, 5.182.208.167, 5.182.208.206) and the fake user agent cPGuard/5.88.11. The vendor publishes SHA-256 hashes for the four fake update scripts. Copy them from its disclosure before you build detections.

How to recover, in order

Scope. Record whether the server was online during the window, and convert all timestamps to UTC in your notes.
Preserve. Capture artifact metadata, hashes and auth logs before cleanup.
Update. Upgrade through the vendor channel to the latest build. 5.88.26 removes the hidden root shell, and a follow-up removes the i93677 cron task. Confirm the artifacts are gone.
Rotate. Change root and local passwords. Generate new root SSH keys and remove the old public key from every server that trusted it. Change the MySQL root password and the credentials in /root/.my.cnf. Rotate anything typed into shell history and the keys in .s3cfg.
Rebuild if needed. OPSSHIELD does not advise a routine OS rebuild. It does advise restoring from a clean backup taken before November 1 if the attacker logged in to a server manually.
Account hygiene. Reset the billing-portal password, turn on two-factor login, and expect targeted phishing that uses the leaked billing data.

Credential rotation worksheet

Exposed item	Where it is trusted	Proof it is closed
Root & local passwords	Console, sudo, any reuse elsewhere	Old hashes gone; no reuse found
Root SSH private key	Every authorized_keys holding its public key	Old key refused on all hosts
MySQL root / .my.cnf	Databases, backups, monitoring	Old credentials fail; apps healthy
Cloud keys (.s3cfg, history)	Buckets and provider APIs	No use of old key IDs in audit logs
Billing-portal login	OPSSHIELD account	Sessions reset; 2FA on

Commands were checked against documentation but not run against live systems for this article. Use them only on servers you are authorized to manage.

Frequently asked questions

Is updating cPGuard enough?

No. Updating removes the attacker’s files, but passwords and keys the script copied stay valid until you change them, both on this server and on every system that trusts them.

Should I rebuild my server?

OPSSHIELD does not recommend it as a routine step. Rebuild from a clean, pre-November 1 backup if there is evidence the attacker logged in manually, or if you cannot establish the host’s integrity.

Did the attacker use the stolen secrets?

That is not established. The disclosure confirms the script ran and collected files; whether stolen credentials were later used against a given customer is unknown. Check your own authentication logs.

Read today’s full MAG212 CYBER Daily (free) →

Subscribe free