cPGuard · Security advisory
cPGuard security advisory: Update channel compromise
Published Last updated
What happened
On , an unidentified attacker used compromised credentials to gain unauthorized access to OPSSHIELD’s update distribution infrastructure (CDN). The attacker used this access to distribute a malicious script through the cPGuard update channel. We are investigating how the credentials were obtained.
We detected the attack within 12 hours of the launch of the updates in question, cPGuard versions 5.88.12–5.88.19. Because update checks occur at intervals, some servers may not have run the malicious script. This timing does not establish whether data was transferred from servers where the script ran.
The script collected data and uploaded it to OPSSHIELD’s own licensing server under a compromised account for the attacker to retrieve later. We have confirmed that the attacker retrieved some collected data from that server and are investigating the extent of that retrieval. Upon discovering the breach, OPSSHIELD secured that account, cleared its infrastructure credentials, and stopped further distribution of the script.
cPGuard 5.88.25 or later includes the corrective update to remove the known backdoor and the files staged by the script.
Administrators can use the update-history check below to identify whether their server installed an affected version (5.88.12–5.88.19). This confirms installation of an affected update, but does not by itself confirm script execution or data transfer. Our investigation continues into how the attacker gained access, what data was transferred from individual servers, and the extent of the data retrieved by the attacker from our licensing server.
Advisory update · Affected versions and collected data
Check whether your server installed an affected update
cPGuard versions 5.88.12 through 5.88.19, inclusive, are affected updates. Check your server’s update history with:
grep 'Successfully updated' /opt/cpguard/logs/install_logExample entries for affected updates (your timestamps may differ):
[02-11-2026 02:46:04]: Successfully updated to 5.88.12
[02-11-2026 04:46:01]: Successfully updated to 5.88.15
[02-11-2026 08:46:02]: Successfully updated to 5.88.17
[02-11-2026 10:46:01]: Successfully updated to 5.88.18
[02-11-2026 12:46:01]: Successfully updated to 5.88.19If any entry shows a version from 5.88.12 through 5.88.19, your server installed an affected update. Treat it as potentially compromised and follow the update and credential-rotation instructions below, even if it now runs 5.88.25 or later.
These entries confirm installation of an affected update; they do not establish which files were collected or transferred from that server. No matching entries, or a missing or incomplete log, do not by themselves establish that the server was unaffected. Contact OPSSHIELD Support if you are unsure.
What data was collected
Our findings confirm that the script collected the following types of data and uploaded collected data to our licensing server for later retrieval by the attacker:
/etc/shadowand/etc/passwd- Root MariaDB/MySQL configuration (
my.cnf) - Root shell history
- Root SSH authorization and known-hosts files
This does not establish that all listed files were collected from every server. We are still determining the data transferred from individual servers and the extent of the data retrieved by the attacker from our licensing server.
Local Linux account passwords in /etc/shadow are stored as one-way password hashes, not plaintext passwords. These hashes cannot ordinarily be entered directly as passwords to log in. Simple, common, or previously exposed passwords are easier to recover by testing known password lists against the hashes offline. Long, unique, randomly generated passwords are much harder to crack when protected by modern password hashing, but the risk also depends on the hashing method and its settings. Strong passwords reduce the risk; they do not establish that an exposed account is safe. Password resets remain necessary for potentially affected accounts. This protection does not apply to other secrets that may be present in database configuration or shell history.
Is a full server reset or rebuild needed?
Based on the data currently available to OPSSHIELD, we are not recommending a full server reset or operating-system rebuild as a routine response to this incident. Administrators should update cPGuard, verify the installed version, and complete the credential resets and rotations below.
This assessment is provisional while the investigation continues. If you find additional signs of compromise or cannot establish the integrity of your server, contact OPSSHIELD Support for an individual assessment; a rebuild may be appropriate in those circumstances. We will update this guidance if verified findings change our assessment.
What administrators should do now
-
Update every cPGuard server
Run this command on every cPGuard server:
cpgcli update --start -
Verify the installed version
cpgcli --versionVerify that the installed version is 5.88.25 or later. If the update fails or the server has not reached 5.88.25 or later, contact OPSSHIELD Support.
-
If the script ran or may have run, treat the server as compromised
A successful update removes the known files, but credentials copied before cleanup may still be usable.
- The script targeted
/etc/shadow. Reset passwords for root and all other password-enabled local Linux accounts from a trusted recovery environment. From a trusted device, change passwords reused on other systems. - Rotate affected database passwords, S3 access keys, DigitalOcean tokens, and secrets recorded in root’s shell history.
- Replace SSH private keys stored under
/root/.sshand remove the corresponding old public keys from every system that trusts them.
- The script targeted
Known indicators
- Malicious script filename
cpguard-v58812-i91511.sh- Backdoor shell removed by the corrective update
/var/tmp/.cpg91511_sh- Collection directory removed by the corrective update
/var/tmp/.cpg91511- Archive staged by the script
/var/tmp/.cpg91511/loot.tgz
The absence of these files after cleanup does not establish whether the script previously ran.
Investigation update
Based on the evidence reviewed so far, we estimate that the attacker retrieved 32 collected files from data uploaded to OPSSHIELD’s server, each corresponding to a customer server. This is a preliminary estimate of confirmed data retrieval, not the total number of potentially affected servers. We are continuing to verify the scope.
Beyond the data collection described above and the known backdoor installed by the script, we have not identified additional malicious activity at this stage. This finding is preliminary and does not rule out activity that has not yet been detected.
Further action: Removing OPSSHIELD support-access keys
As a precaution, OPSSHIELD is releasing an update to remove our support-access keys from any cPGuard servers where they were previously added. This is an additional precautionary measure and does not replace the update and credential-rotation instructions above.
Support and further updates
We apologize for this incident and the concern and disruption it has caused. Please contact OPSSHIELD Support if you need assistance. We will publish verified findings as the investigation progresses.
Contact OPSSHIELD Support