An attacker broke into the update system of OPSShield, the company behind cPGuard, a security suite for Linux web hosting servers, and shipped fake updates that customer servers installed and ran as root. OPSShield estimates that about 2,950 servers executed the malicious code during a window of roughly 70 minutes on 2 November.
The case is a sharp reminder that a security agent with root access and automatic updates is a high-value target in its own right. For anyone who runs or rents hosting servers protected by cPGuard, the stolen data includes exactly the secrets that open the rest of the infrastructure: root SSH keys, database passwords and cloud storage keys.
How the attack unfolded
According to OPSShield's own account, as reported by Help Net Security and SecurityWeek, the attacker started at the company's billing portal. They signed up for a customer account under a false identity, took a free cPGuard trial and installed it to learn how the agent communicates with the licensing system. Crafted requests to the portal's callback pages then gave them the ability to run commands on the billing and licensing server.
From there the attacker collected roughly 7,900 client account records, including names, companies, postal addresses, emails and bcrypt-hashed passwords, and copied three of the company's cloud servers. Using a stolen access key, they uploaded fake cPGuard versions 5.88.12 through 5.88.19 to the update storage on 2 November, between 02:04 and 02:09 UTC. SecurityWeek says the company attributes the access to compromised credentials and found the problem within 12 hours.
OPSShield says it still does not know how the attacker obtained the update key or exactly which request let them run commands on the billing server, because its logs did not capture it. It has patched two possible entry points and says it has ruled out SSH, the control panel, FTP and API tokens. The company estimates the whole operation, from first probe to fake update, took about ten hours, and argues that AI tools are making such attacks faster and cheaper.
What the fake update did
The malicious update was a short script that gathered sensitive files and sent them to OPSShield's own licensing server, where they sat under a compromised account until the attacker collected them. The data included password hashes, root SSH keys, the MySQL root password where one existed, root's shell history, which can contain typed passwords and tokens, and cloud storage keys. SecurityWeek reports that the attacker retrieved 32 collected files, each from a different customer server.
The script also left a hidden root shell at /var/tmp/.cpg91511_sh and files in /var/tmp/.i93677/, plus a scheduled task. Because cPGuard only checks for updates at intervals, servers that were not online during the window did not receive the fake version.
OPSShield's response
The company says it has cut the attacker off from every system it knows was reached, revoked the stolen update-storage key and all cloud API tokens, removed the attacker's SSH key and cloned servers, and replaced SSH keys and passwords across its own servers. It is reissuing every cPGuard license key pair, has reset billing portal sessions and is rebuilding its billing, licensing and management servers from clean images with full request logging.
For customers it released a clean update that removes the hidden root shell, with a follow-up that removes the scheduled task. The two reports differ slightly on the version: Help Net Security names 5.88.26, while SecurityWeek says 5.88.25 and later. OPSShield has also published indicators of compromise. Customers the company has told that the attacker logged in to their server by hand are advised to rebuild from a clean backup made before 1 November.
What to do
- Check whether any server ran cPGuard versions 5.88.12 to 5.88.19, and if so update to 5.88.26 and confirm the hidden shell, the files in /var/tmp/.i93677/ and the scheduled task are gone.
- On affected servers, reset root and other local account passwords from a trusted recovery environment, and look for unfamiliar users, SSH keys, services and outbound connections.
- Replace the SSH keys under /root/.ssh, remove their old public keys everywhere they are trusted, and rotate database passwords, S3 keys, DigitalOcean tokens and any secrets found in root's shell history or /root/.s3cfg.
- Reset your OPSShield billing portal password and turn on two-factor login, even if your servers did not receive the fake update.