A trojanised update to cPGuard, a security suite that many smaller hosting firms rely on, ran as root on roughly 2,950 Linux servers and copied the credentials that matter most. If any of your servers were online in the early hours of 2 November, treat this as an incident to investigate, not a routine patch.
What happened
OPSShield, which develops the cPGuard malware scanner and firewall for Linux web servers, has disclosed that an attacker took over its update channel and pushed fake releases to customers. cPGuard sits alongside control panels such as cPanel, Plesk and DirectAdmin, and BleepingComputer notes that Namecheap sells it with its VPS and dedicated plans.
According to OPSShield’s own incident disclosure, the intrusion began with a customer sign-up. On 1 November the attacker created an account under a false identity, started a free trial and installed the product to learn how its agent communicates with licensing. About ninety minutes later they sent crafted requests to callback pages on the billing portal at manage.opsshield.com and, within minutes, could execute commands on the billing and licensing server. From there they copied around 7,900 customer records, including names, company and postal details, email addresses and bcrypt-hashed passwords, cloned three of the company’s cloud servers and obtained the key used to publish updates, although OPSShield says it is still establishing exactly how.
Early on 2 November, between about 02:04 and 02:09 UTC, the attacker uploaded fake builds numbered 5.88.12 to 5.88.19. OPSShield tells customers whose cPGuard was online between 02:08 and 03:20 UTC to assume their root-level secrets are known to the attacker. A company spokesperson told BleepingComputer that 2,946 servers were affected. OPSShield says it spotted the activity within 12 hours and estimates that the whole operation, from first probe to poisoned release, took about ten hours.
The technical picture
The malicious update was a short script, not a sophisticated implant. Running as root, it gathered the files an intruder needs to come back later or move sideways: /etc/shadow and /etc/passwd, the contents of /root/.ssh (private keys, authorized_keys and known_hosts), the MySQL root credentials in /root/.my.cnf, root’s shell history and, on a small number of machines, S3 credentials in /root/.s3cfg.
Rather than use its own infrastructure, the script uploaded the haul to OPSShield’s licensing server under a compromised account, where the attacker collected it; to a defender, that traffic looks like normal vendor chatter. OPSShield’s preliminary figure is that 32 customer servers’ worth of collected data was actually pulled down, but the company stresses that this is confirmed retrieval, not the full count of exposed hosts.
The script also left a way back in. OPSShield lists a concealed root shell, /var/tmp/.cpg91511_sh, staging files under /var/tmp/.i93677/ and a scheduled task at /etc/cron.d/i93677. The company warns that the implant conceals itself from standard tools, so checks should be run from a trusted boot environment or with a known-good static binary rather than the server’s own utilities.
One point needs care. OPSShield’s earlier advisory tells administrators to move to 5.88.25 or later, while its later incident disclosure names 5.88.26 as the clean build that removes the root shell, with a further release removing the i93677 scheduled task. My advice: take the newest release available, then confirm by hand that all three artefacts have gone.
Why it matters for UK organisations
A great deal of the UK’s small business web presence runs on exactly this kind of server: a cPanel or Plesk VPS looked after by a local agency, a reseller or a two-person hosting firm. Those operators are often least able to spare a day for incident response. Because one root SSH key frequently opens several neighbouring machines, the exposure can easily reach beyond the server that installed the update.
There is also a data protection dimension. Web servers commonly hold customer databases, and a stolen MySQL root password gives direct access to them. Any controller who finds that personal data was reachable should assess, promptly, whether the breach must be reported to the ICO within 72 hours under UK GDPR.
This is a textbook supply chain case: the protective tool becomes the delivery mechanism. Security agents run with top privileges by design, so their update pipelines deserve equal scrutiny.
Expert view
What strikes me most is how ordinary the entry point was. The attacker did not need a zero-day in a hardened appliance; they became a customer, studied the product, and found weaknesses in a billing web application that happened to share a home with the update signing material. In my experience, billing and licensing systems at smaller vendors get far less attention than the product itself, even though they often hold the keys to everything.
The vendor’s own reasoning is that tooling has made this kind of attack quicker and cheaper; OPSShield writes that attackers now produce custom tools “in hours instead of weeks”. Ten hours from reconnaissance to mass compromise leaves no room for weekly log reviews.
OPSShield has been unusually open, publishing indicators and a timeline and admitting it still does not know exactly how the billing server was breached. That is welcome, but the core lesson stands: when a privileged agent may have run hostile code, patching the agent is the start of the response, not the end of it. OPSShield says it is not recommending routine rebuilds, but that guidance is explicitly provisional, and where you cannot establish a server’s integrity a rebuild remains the cleaner option.
What to do now
- Establish exposure. Check each server’s cPGuard update history for any build from 5.88.12 to 5.88.19. OPSShield notes that a missing or incomplete log does not prove a server was untouched, so record cPGuard’s online status for the morning of 2 November too.
- Update and verify. Install the latest cPGuard release (at least 5.88.26, which supersedes the earlier 5.88.25 advice), then confirm /var/tmp/.cpg91511_sh, /var/tmp/.i93677/ and /etc/cron.d/i93677 are gone, checking from a trusted environment.
- Rotate root-level secrets. Reset root and every password-enabled local account from a trusted recovery environment; issue new MySQL root and database passwords; rotate S3 keys, DigitalOcean tokens and anything visible in root’s shell history.
- Replace SSH keys estate-wide. Generate new keys, remove the old public keys from every system that trusted them and audit authorized_keys for entries you do not recognise. This maps directly to the Cyber Essentials secure configuration and user access control requirements.
- Hunt for follow-on activity. Look for new users, unfamiliar services, unexpected cron entries and outbound connections since 2 November, and review authentication logs on any host reachable with the old keys.
- Rebuild where needed. If OPSShield has told you the attacker logged in by hand, or you cannot establish integrity, rebuild from a backup taken before 1 November.
- Close the account side. Reset your OPSShield billing portal password and enable two-factor authentication.
- Consider notification. Decide, and document, whether personal data exposure triggers an ICO report or customer notice.
Bottom line
This was a short, noisy smash-and-grab, but what it grabbed was root passwords, database credentials and SSH keys, which stay useful long after the malicious files are deleted. Updating cPGuard removes the backdoor; only rotating every exposed secret, and hunting for signs that someone has already used them, closes the incident.
