cPGuard Supply-Chain Attack: Fake Update Exposes Root Credentials on Nearly 3,000 Linux Servers

What happened​

OPSSHIELD develops cPGuard, a Linux web-server security suite. OPSSHIELD said the attack began on November 2 at 02:06 UTC and affected versions 5.88.12 through 5.88.19. The attacker used unauthorized access to push a malicious script through the cPGuard update channel.

BleepingComputer reports that cPGuard is commonly used by hosting firms and server administrators alongside cPanel, DirectAdmin and Plesk. It adds that Namecheap offers it on VPS and dedicated servers.

The scale is large. A company spokesperson told BleepingComputer that 2,946 servers were affected, and that the billing database was copied too. OPSSHIELD's fuller disclosure, published November 3, rounds this to about 2,950 customer servers. It also says about 7,900 billing-portal accounts were exposed. Those records include names, company names, postal addresses, email addresses and bcrypt password hashes.

How the attacker got in: two accounts of the same incident​

OPSSHIELD's first advisory described compromised credentials used against its update distribution infrastructure. The fuller disclosure gives a more detailed chain of events. These are OPSSHIELD's own findings, and the investigation is still open.

• 1 Nov, 15:38 UTC: the attacker began probing the billing portal.
• 1 Nov, 16:34 UTC: the attacker registered a customer account under a false identity and ordered a free cPGuard trial.
• 1 Nov, 21:17 UTC: the attacker installed the trial on their own server to study how the agent talks to the licensing system. cPGuard flagged and banned the account twice between 21:40 and 21:51.
• 1 Nov, 22:50–22:58 UTC: the attacker sent crafted requests to the portal's callback pages. They then gained command execution on the billing and licensing server.
• 2 Nov, 02:04–02:09 UTC: the attacker uploaded a fake update to update storage using a stolen access key.
• 2 Nov, 02:08–03:20 UTC: cPGuard agents installed the fake update, which ran as root.

The vendor says it cannot identify the exact request that gave the attacker access. It patched two possible entry points and says it ruled out SSH, the control panel, FTP and API tokens.

OPSSHIELD also notes the speed: about ten hours from first probe to fake update. It suggests attackers are using AI tools to speed up reconnaissance and tooling. That is the vendor's own assessment, not independently verified.

Timing: 12 hours or 70 minutes?​

The two OPSSHIELD documents describe the window differently. The first advisory says the attack was detected within 12 hours of the affected updates launching. The later disclosure says the fake update was live for about 70 minutes. These measure different things: time to detection versus time the malicious file was actually served.

The practical rule from OPSSHIELD is simple. The advisory says a server that installed an affected version should be treated as potentially compromised. That applies even if it has since been updated.

What the script took​

OPSSHIELD says the script collected:

• /etc/shadow and /etc/passwd, which hold local password hashes
• /root/.ssh, including root private keys, authorized_keys and known_hosts
• /root/.my.cnf, the MySQL root configuration, where present
• root shell history, which often contains typed passwords and tokens
• /root/.s3cfg cloud storage keys, on a small number of servers

The script also left a setuid-root shell at /var/tmp/.cpg91511_sh. The attacker's staging files used the .cpg91511 and .i93677 naming patterns.

There is one discrepancy to flag. The first advisory says collected data was uploaded to OPSSHIELD's own licensing server under a compromised account. The later disclosure says the files went to a server the attacker controlled. The documents don't fully reconcile these accounts.

The "32 files" figure also needs care. OPSSHIELD called it a preliminary estimate of confirmed retrievals from its server, each corresponding to one customer server. It is not a count of affected servers. The later disclosure points to roughly 2,950 servers that ran the fake update.

Check your exposure​

OPSSHIELD's advisory gives this check of the update log:

grep 'Successfully updated' /opt/cpguard/logs/install_log

An entry for any version from 5.88.12 to 5.88.19 means the server installed an affected update. Two caveats apply:

• A match does not prove the script ran or that data left the server.
• No match, or a missing or incomplete log, does not prove the server is clean.

OPSSHIELD's later notice says that if cPGuard was online between 02:08 and 03:20 UTC on November 2, you should assume the root-level secrets are known to the attacker.

Remediation steps​

1. Update: run cpgcli update --start on every cPGuard server.
2. Verify: run cpgcli --version. The first advisory set 5.88.25 as the minimum. The later disclosure says clean update 5.88.26 was published, and a follow-up update removes a scheduled task. Aim for the latest release rather than the minimum.
3. Confirm cleanup: check that /etc/cron.d/i93677, /var/tmp/.i93677/ and /var/tmp/.cpg91511_sh are gone, and delete them if they aren't.
4. Reset passwords: change the root password and every local user password. OPSSHIELD advises doing this from a trusted recovery environment, and changing any reused passwords from a trusted device.
5. Rotate secrets: change the MySQL root password and any other database passwords. Rotate any password, API key or token that appears in root's shell history, plus any keys in /root/.s3cfg.
6. Replace SSH keys: generate new root keys and remove the old public keys from every system that trusted them.
7. Check lateral reach: treat any server reachable from the affected one with those SSH keys as exposed until its keys are replaced.
8. Secure the billing portal: reset your manage.opsshield.com password and enable two-factor login.

A successful update removes the known files, but it can't un-steal credentials. Treat the update as cleanup only, and finish the rotation.

To rebuild or not?​

OPSSHIELD's first advisory said it did not recommend a full OS rebuild as a routine response. It called that provisional, though, and left room for rebuilding if you find other signs of compromise or can't establish integrity. The later notice is firmer in one case: if OPSSHIELD told you the attacker logged in to your server by hand, rebuild it from a clean backup taken before November 1.

The vendor's own billing, licensing and internal servers are being rebuilt from clean images. Its notice says its internal implant hides from ps, netstat, ls and find. It recommends checking from a trusted boot environment or with a known-good static binary. That implant was found on OPSSHIELD's own internal server, not on customer servers.

Indicators of compromise​

OPSSHIELD published indicators for other security teams and hosting providers:

• Attacker operator IP: 94.183.188.91, which sometimes sent a fake cPGuard/5.88.11 user agent
• Fake update scripts matching cpguard-v58812-i91511*.sh, in four variants
• Probe files and web shells in the web root, such as /i90573_sh.php, following an i9xxxx naming pattern
• URL paths matching *_rx.php, which the attacker used to receive stolen data

Why this matters beyond cPGuard​

• Security tools are privileged targets. An agent that runs as root and auto-updates is an ideal delivery channel. Compromising the vendor reaches thousands of environments at once.
• Signing and storage keys need the same protection as production secrets. A single stolen storage key was enough to publish a fake update.
• A free trial gave the attacker a foothold. The attacker studied the agent from the customer side before attacking the licensing server.
• Shell history is a secrets store you didn't mean to create. Rotation lists should always include whatever was ever typed at a root prompt.
• Windows shops have the same exposure. Management agents, RMM tools and endpoint security products that update themselves with high privileges carry the same risk. Consider staged rollouts, update-channel monitoring and egress controls for such agents where you can.

OPSSHIELD says it is re-issuing all cPGuard license keys and hardening its update and signing process. The company says it will keep updating its notice as the investigation continues. Anyone running cPGuard should watch that notice.