Hosting servers running cPGuard: hijacked updates copied password hashes and SSH keys. Update, then rotate

cPGuard is a security suite for Linux web servers, common on hosting boxes that run cPanel, DirectAdmin or Plesk. On Monday someone used stolen credentials to break into its update system and ship a script that planted a backdoor and copied password hashes, SSH files and database settings.

The latest version removes the backdoor. It cannot take back what the script already copied, so the real work on an affected server is a round of password and key changes.

The cPGuard update removes the backdoor. It does not change the passwords and keys the script already copied.

The 5-Minute Cyber Brief

Don’t Miss the Policy Changes That Affect Security Decisions

Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.

Email addressSend me tomorrow’s brief

By subscribing you agree to our Privacy Policy.

Free. Weekday mornings. 5 minutes or less.

An attacker pushed a backdoor through cPGuard’s own updates

OPSSHIELD, which makes cPGuard, says an attacker used compromised credentials to get into its update distribution system at 02:06 UTC on November 2 and pushed the malicious script in cPGuard versions 5.88.12 through 5.88.19. The company caught it within 12 hours. It says it does not yet know how the credentials were stolen.

The script uploaded what it gathered to OPSSHIELD’s own licensing server, through a compromised account, for the attacker to collect. OPSSHIELD confirmed that some of that data was retrieved. A spokesperson told BleepingComputer that 2,946 servers were affected and that the company’s billing database was copied as well.

Hosting servers that auto-updated cPGuard on November 2

Any server that installed 5.88.12 to 5.88.19 should be treated as compromised, even if it now runs a clean version, OPSSHIELD says. The collected files include /etc/shadow and /etc/passwd, root’s MySQL or MariaDB settings, root’s shell history and root’s SSH authorized_keys and known_hosts files.

BleepingComputer says hosting firms and server administrators commonly run cPGuard, and Namecheap offers it on its VPS and dedicated servers. A database password or cloud token in root’s shell history is not hashed, so it works for whoever has the file.

Update to 5.88.25, then reset every password and key the script took

• Run cpgcli update --start on every cPGuard server, then cpgcli --version to confirm 5.88.25 or later.
• Run grep 'Successfully updated' /opt/cpguard/logs/install_log. Any line for 5.88.12 through 5.88.19 means the server took a bad update.
• On those servers, reset root and every other local password from a trusted recovery environment. Then rotate database passwords, S3 keys, DigitalOcean tokens and any secret that appears in root’s shell history.
• Replace the SSH keys under /root/.ssh and remove their old public keys from every system that trusts them.
• Pick new passwords that are long and unique, since weak ones fall quickly once hashes leak. Our password strength checker shows how long a password would hold up against guessing.

Details

• Bad versions: cPGuard 5.88.12 to 5.88.19, served November 2, 2026 from 02:06 UTC until OPSSHIELD stopped them, within 12 hours. Fixed: 5.88.25 or later removes the known backdoor and staged files.
• Data taken: /etc/shadow, /etc/passwd, root my.cnf, root shell history, root SSH authorized_keys and known_hosts. Not every file was taken from every server, OPSSHIELD says.
• Scale: 2,946 servers affected, per an OPSSHIELD spokesperson to BleepingComputer. The Hacker News reports OPSSHIELD’s early estimate that the attacker pulled 32 files, each tied to one customer server, from the licensing server.
• Rebuild: OPSSHIELD does not recommend a routine OS rebuild for now and says that view may change. A separate update will remove OPSSHIELD support-access keys from root’s authorized_keys.

Hunt / verify

• Look for the files OPSSHIELD named: cpguard-v58812-i91511.sh, /var/tmp/.cpg91511_sh and the /var/tmp/.cpg91511 folder with loot.tgz. The update deletes them, so finding none proves nothing.
• Review SSH logins to root and new entries in /root/.ssh/authorized_keys since November 2, and check database users for accounts nobody created.

Source: OPSSHIELD advisory; BleepingComputer report

Sources

• OPSSHIELD: cPGuard security advisory, update channel compromise (November 3, 2026)
• BleepingComputer: Hackers hijack cPGuard autoupdate to deploy backdoor, steal data
• The Hacker News: cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].