Cpguard Update Channel Compromise

Published 3 November 2026 | Last updated 3 November 2026, 3:19 AM IST (UTC+05:30)

On 2 November 2026 at 02:06 UTC , 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:

Example entries for affected updates (your timestamps may differ):

If 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. 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/shadow and /etc/passwd

Root MariaDB/MySQL configuration ( my.cnf )

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, 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: Update cPGuard cpgcli update --start

Update every cPGuard server

Run this command on every cPGuard server:

Verify the installed version Verify installed version cpgcli --version Verify 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 , OPSSHIELD Support .

Verify the installed version

Verify 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 , 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/.ssh and remove the corresponding old public keys from every system that trusts them.

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/.ssh and remove the corresponding old public keys from every system that trusts them.

The absence of these files after cleanup does not establish whether the script previously ran.

3 November 2026, 2:42 AM IST (UTC+05:30)

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

3 November 2026, 3:17 AM IST (UTC+05:30)

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 OPSSHIELD Support if you need assistance. We will publish verified findings as the investigation progresses.