An attacker has compromised the update infrastructure of cPGuard, a security suite for Linux web hosting servers, and pushed out a malicious update to nearly 3,000 customer servers.
OPSShield, the company behind the security suite, also confirmed that the attacker made off with customer contact information and hashed passwords from the firm’s billing and licensing server.
How the attack unfolded
The attacker uploaded fake cPGuard updates – versions 5.88.12 through 5.88.19 – to OPSShield’s update storage on November 2, 2026, between 02:04 and 02:09, UTC.
For the next 70+ minutes, cPGuard agents installed the fake update on about 2,950 customer servers and ran it as root.
The fake update was a short script that collected sensitive files and sent them to a server controlled by the attacker. In an earlier report on the incident, OPSShield said that the latter was OPSSHIELD’s own licensing server, where the stolen info was stored under a compromised account for the attacker to retrieve later.
The collected and exfiltrated data includes password hashes, root SSH keys, the MySQL root password (where present), root shell history (which may include typed passwords and tokens), and cloud storage keys.
“[The script] also left two pieces behind: a hidden root shell at /var/tmp/.cpg91511_sh with files in /var/tmp/.i93677/,” the company added.
According to OPSShield’s report, the day before the compromise of the update infrastructure the attacker probed OPSShield’s billing portal. They registered a customer account under a false identity, ordered a free cPGuard trial, and installed it to study how the agent talks to the licensing system.
An hour and a half later, the attacker sent crafted requests to the billing portal’s callback pages and, just minutes after that, gained the ability to run commands on the billing and licensing server, then started collecting client account records: the name, company, postal address, email, and bcrypt-hashed password of about 7,900 customers.
“Attacks like this one are getting faster and cheaper to run. Attackers now use AI tools to scan for weak points, read unfamiliar code and write custom tools in hours instead of weeks; the speed of this attack, from first probe to fake update in about ten hours, reflects that,” OPSShield noted.
The attackers also made copies of three of the company’s cloud servers.
What OPSShield has done so far
OPSShield has yet to determine how the attacker got ahold of the access/update key that allowed them to upload the fake cPGuard updates. They also don’t know yet how the attacker managed to run commands on their billing and licensing server.
“Our logs do not record the exact request that gave them access, so we are reviewing that code, patched two possible entry points that we found and verify the related vendor components line by line. We have ruled out SSH, the control panel, FTP, API tokens, etc,” the company shared.
The investigation is still ongoing. In the meantime, OPSShield has cut off the attacker’s access to every system it knows was reached.
The company revoked the stolen update-storage key along with all cloud API tokens and access keys; removed the attacker’s SSH key, cloned servers and snapshots from its cloud account; and enabled stronger login protection.
For customers, it has released a clean update (v5.88.26) which removes the hidden root shell planted by the malicious update, and a follow-up update removes the i93677 scheduled task.
OPSShield has also replaced every SSH key and password across its own servers, reset all billing portal sessions, and rotated its billing system and reseller API keys. It is re-issuing all cPGuard license key pairs so that any copies held by the attacker become useless.
Finally, it is rebuilding billing, licensing and internal management servers from clean images with tighter PHP and web firewall settings and full request logging.
What should customers do?
First, they need to check whether a malicious cPGuard version has been installed on their servers. If it has, they need to:
- Update to version 5.88.26 or later, confirm that the malicious scheduled task and root shell have been removed, and review their servers for any other signs of unauthorized changes: unfamiliar users, SSH keys, services and outbound connections, etc.
- Reset passwords for root and all other password-enabled local Linux accounts from a trusted recovery environment.
- Rotate affected database passwords, S3 access keys, DigitalOcean tokens, and password, API key or tokens recorded in root’s shell history, as well as any keys in /root/.s3cfg.
- Replace SSH private keys stored under /root/.ssh and remove the corresponding old public keys from every system that trusts them.
- Reset their OPSSHIELD billing portal password (as a precaution) and turn on two-factor login.
Because cPGuard checks for updates at intervals, not every customer server received the fake update. “If cPGuard was not online during that window, your server did not receive the fake update,” OPSShield said.
For customers it has contacted directly to confirm that the attacker logged in to their server by hand, the company recommends rebuilding the server from a clean backup taken before November 1.
OPSShield published a list of indicators of compromise that also include some found on their own servers, and offered to help customers go through the remediation process.
Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
