Security Incident Disclosure: manage.opsshield.com

Between 1 and 2 November 2026, an attacker broke into part of the OPSSHIELD infrastructure and used our cPGuard update channel to push a malicious update to customer servers. We found it, stopped it, and are telling you directly, in full, before anyone else does.

We would rather you hear the hard parts from us. This post covers what happened, what it means for your servers, what we have already done, and the exact steps we need you to take today.

What our investigation points to

The attacker signed up as a customer, used that account to break into our billing and licensing server, took the keys we use to publish updates, and shipped a fake cPGuard update for 70 minutes on 2 November. All times are UTC.

How they got in. The attacker came in through our billing application at manage.opsshield.com, logged in to a customer account they had registered that afternoon. 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

What the fake update did

The fake update was a short script, not a long-term implant: it collected sensitive files and sent them to a server the attacker controlled. On the servers that ran it, it read:

/etc/shadow and /etc/passwd (local password hashes)

/root/.ssh (root SSH private keys, authorized_keys , known_hosts )

/root/.my.cnf (MySQL root password), where present

root shell history, which often contains typed passwords and tokens

/root/.s3cfg cloud storage keys, on a small number of servers

It also left two pieces behind: a hidden root shell at /var/tmp/.cpg91511_sh with files in /var/tmp/.i93677/ .

On our side, the attacker reached our billing system and took a copy of client account records, which we cover below. The affected servers are being rebuilt from scratch.

What it means for you

If your server had cPGuard installed and online between 02:08 and 03:20 UTC on 2 November, assume its root-level secrets are known to the attacker.

Passwords: billing portal passwords were stored as bcrypt hashes, not plain text. We request everyone to reset your manage.opsshield.com account password as a precaution.

If cPGuard was not online during that window, your server did not receive the fake update. You should still reset your billing portal password.

We have shut the attacker out of every system we know they reached, and we are rebuilding the ones we cannot fully trust.

Revoked the stolen update-storage key and every cloud API token and access key on our account.

Removed the attacker's SSH key, cloned servers and snapshots from our cloud account, and turned on stronger login protection.

Published clean update v 5.88.26, which removes the hidden root shell. A follow-up update also removes the i93677 scheduled task.

Replaced every SSH key and password used across our own servers.

Started re-issuing all cPGuard license private/public keys, so the copies the attacker holds stop working.

Reset every billing portal login session, and rotated all billing system and reseller API keys.

Rebuilding our billing, licensing and internal management servers from clean images, with tighter PHP and web firewall settings and full request logging, so any repeat is recorded in full.

Closed the attacker's fake customer account and trial license, and fixing cPGuard so temporary bans are enforced on nftables firewalls.

What you should do, if you haven’t already

These steps take most admins under an hour per server and close off everything the attacker took.

Update cPGuard to the latest version, then confirm /etc/cron.d/i93677 , /var/tmp/.i93677/ and /var/tmp/.cpg91511_sh are gone; delete them if not.

Change the root password and every local user password on the server.

Generate new root SSH keys, remove the old ones from authorized_keys on every server that trusted them, and review authorized_keys for anything you don't recognise.

Change the MySQL root password and any database passwords stored in /root/.my.cnf .

Rotate any password, API key or token that appears in your root shell history, plus any keys in /root/.s3cfg .

Check other servers you reach from this one with SSH keys; treat them as exposed until their keys are replaced.

Reset your OPSSHIELD billing portal password and turn on two-factor login.

If we told you the attacker logged in to your server by hand, rebuild it from a clean backup taken before 1 November.

If you would rather we walk you through it, to our email or open a ticket. We will help at no charge, for as long as it takes.

Indicators of compromise

We are sharing these so other security teams and hosting providers can check their own systems.

The last three rows come from our own internal server, not from customer servers. Because the implant hides itself from standard tools, check from a trusted boot environment or a known-good static binary.

We are sorry. You trusted cPGuard to protect your servers, and this time our own systems were used against you. We own that, and we are not going to hide behind it.

OPSSHIELD is a small team. We have never spent much on marketing; most of you found us through a colleague or a forum thread, because the product did its job at a price smaller hosts could afford. That is still the promise: the best protection we can build, at the lowest price we can offer it. This incident does not change that promise. It raises the bar we hold ourselves to.

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 ten hours, reflects that. Small vendors and the hosts who rely on them are exactly the targets they are counting on. Our answer is to harden our own update and signing process first, and then to put what we learned here straight back into cPGuard for you.

We will keep this post updated as the investigation continues. If you have questions, to our email or open a support ticket, and a member of the team, not a bot, will answer.

Thank you for staying with us.