OPSSHIELD · Security incident disclosure
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 about 70 minutes on 2 November. All times are UTC.
| When (UTC) | What happened |
|---|---|
| 1 Nov, 15:38 | Attacker begins probing our billing portal (manage.opsshield.com) |
| 1 Nov, 16:34 | Attacker registers a customer account under a false identity and orders a free cPGuard trial |
| 1 Nov, 21:17 | Attacker installs the trial on their own server to study how the agent talks to our licensing system |
| 1 Nov, 21:40–21:51 | cPGuard flags and bans the attacker twice |
| 1 Nov, 22:50 | Attacker sends crafted requests to the billing portal's callback pages |
| 1 Nov, 22:58 | Attacker gains the ability to run commands on the billing and licensing server and starts collecting data |
| 2 Nov, 02:04–02:09 | Attacker uploads a fake cPGuard update to our update storage, using a stolen access key |
| 2 Nov, 02:08–03:20 | cPGuard agents install the fake update; it runs as root and copies sensitive files back to the attacker |
| 2 Nov, 02:13 | Attacker makes copies of three of our cloud servers |
| 2 Nov | Stolen update key revoked; clean update v 5.88.26 published to remove the attacker's tools |
| 3 Nov | Entry point traced; this notice published |
What we found
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/shadowand/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/.s3cfgcloud 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.
| Who | Count | What was exposed |
|---|---|---|
| Customer servers that ran the fake update | about 2,950 | Password hashes, root SSH keys, MySQL root password, shell history |
| Billing portal accounts | about 7,900 | Name, company, postal address, email, hashed password |
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.
What we have done
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
i93677scheduled 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_share 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_keyson every server that trusted them, and reviewauthorized_keysfor 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, reply 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.
| Type | Indicator | Notes |
|---|---|---|
| IP | 94.183.188.91 | Main attacker operator address; sometimes sent a fake cPGuard/5.88.11 user agent |
| File | /i90248_probe.txt, /i90573_probe.txt, /i90573_sh.php, /i90573_x.php in the web root | Probe files and web shells; the attacker's file names follow an i9xxxx pattern |
| URL path | *_rx.php | Endpoints the attacker used to receive stolen data |
| File | /etc/cron.d/i93677, /var/tmp/.i93677/ | Scheduled task left by the fake update |
| File | /var/tmp/.cpg91511_sh | Setuid-root shell left by the fake update |
| File | cpguard-v58812-i91511*.sh | Fake update scripts (four variants) |
| SHA-256 | 2c2acd988da531d133d0e17f245c49bf15781278f837543d18c95e8410eabd38 | cpguard-v58812-i91511.sh |
| SHA-256 | ffd7a47f65fa1244429baa936ae94be54676b53d2f88bc39564f24e22011de8a | cpguard-v58812-i91511b.sh |
| SHA-256 | d73919af84bf46de941db85e27fd1abc65701ef9ce6cf33bb27c5397f4a41c26 | cpguard-v58812-i91511c.sh |
| SHA-256 | 6add0201e9a3d02de772d561d05e0da86eb1c538686753b7adcc3aedf7366f77 | cpguard-v58812-i91511d.sh |
| File | /usr/bin/defunct, defunct.service, /lib/systemd/system/defunct.dat | gsocket backdoor; process shown as [slub_flushwq] |
| File | /usr/sbin/pythno3, /usr/sbin/netstat.cfg, /etc/profile.d/bash.cfg, /usr/lib/system.mark, /usr/lib/libgdi.so.0.8.2, /boot/system.pub | Go implant copies; process shown as [rcu_gp] |
| File | /etc/profile.d/gateway.sh | Hides the implant from ps, netstat, ls and find |
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.
A word from the team
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 about 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, reply 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.
— The OPSSHIELD team