Malicious cPGuard Updates Distributed in OPSSHIELD Supply Chain Attack

TL;DR - OPSSHIELD says an attacker accessed its update distribution infrastructure on 2 November 2026 at 02:06 UTC and distributed a malicious script through the cPGuard update channel. - cPGuard versions 5.88.12 through 5.88.19 are identified as affected updates. - The script collected sensitive files, including /etc/shadow, /etc/passwd, root SSH files, database configuration and root shell history. - OPSSHIELD says cPGuard 5.88.25 or later includes a corrective update. A later OPSSHIELD disclosure says clean update v 5.88.26 was published. - The vendor’s investigation remains ongoing, and its notices provide different details about the attack window and scope.

What happened#

OPSSHIELD says an unidentified attacker used compromised credentials to gain unauthorized access to its update distribution infrastructure, described as a CDN, on 2 November 2026 at 02:06 UTC. The attacker then distributed a malicious script through the cPGuard update channel. OPSSHIELD says it detected the attack within 12 hours of the launch of the affected updates.

The vendor identifies cPGuard versions 5.88.12 through 5.88.19, inclusive, as affected updates. Because update checks occur at intervals, OPSSHIELD says some servers may not have run the script.

The script collected data and uploaded it to OPSSHIELD’s licensing server under a compromised account for later retrieval. OPSSHIELD says it confirmed that the attacker retrieved some collected data and is investigating the extent of that retrieval. The vendor says it secured the account, cleared its infrastructure credentials and stopped further distribution.

The collected data types listed in OPSSHIELD’s advisory are:

• /etc/shadow and /etc/passwd
• Root MariaDB/MySQL configuration, my.cnf
• Root shell history
• Root SSH authorization and known-hosts files

A separate OPSSHIELD disclosure says the attacker accessed part of the company’s infrastructure through its billing and licensing server, used a stolen access key to upload a fake update, and that the fake update ran as root. That notice says a clean update, v 5.88.26, was published and that a follow-up update removes an i93677 scheduled task. OPSSHIELD’s security incident disclosure

Are you affected#

Administrators can review cPGuard’s installation history using the command published in OPSSHIELD’s advisory:

grep 'Successfully updated' /opt/cpguard/logs/install_log

The advisory provides example entries for versions 5.88.12, 5.88.15, 5.88.17, 5.88.18 and 5.88.19. OPSSHIELD says that an entry showing a version from 5.88.12 through 5.88.19 means the server installed an affected update.

The vendor also says that installation of an affected update does not by itself confirm script execution or data transfer. No matching entries, or a missing or incomplete log, do not by themselves establish that a server was unaffected.

OPSSHIELD says administrators should treat a server that installed an affected update as potentially compromised and follow its update and credential-rotation instructions, even if the server now runs cPGuard 5.88.25 or later.

The later OPSSHIELD disclosure gives a different operational criterion, stating that servers with cPGuard installed and online between 02:08 and 03:20 UTC on 2 November received the fake update. The same notice estimates that about 2,950 customer servers executed the fake updates. These details differ from the first advisory’s account, which identifies affected versions and says update checks occurred at intervals.

What is confirmed and what is reported#

The two OPSSHIELD notices provide different details about the attack window and cleanup. The advisory identifies 5.88.12 through 5.88.19 as affected updates and recommends 5.88.25 or later. The later disclosure describes a 02:08 to 03:20 UTC window and identifies v 5.88.26 as a clean update. OPSSHIELD says the investigation continues.

No CVE ID has been published in the available notices.

What defenders should do now#

1. Update every cPGuard server using the vendor’s command:

bash cpgcli update --start

2. Verify the installed version:

bash cpgcli --version

OPSSHIELD says to 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, the vendor says to contact OPSSHIELD Support.

3. Review /opt/cpguard/logs/install_log for entries showing versions 5.88.12 through 5.88.19. Treat a server with an affected installation as potentially compromised, even if it has since been updated.

4. Reset passwords for root and all other password-enabled local Linux accounts from a trusted recovery environment, as OPSSHIELD recommends for servers where the script ran or may have run.

5. Rotate database passwords, S3 access keys, DigitalOcean tokens and secrets recorded in root’s shell history.

6. Replace SSH private keys stored under /root/.ssh and remove the corresponding old public keys from systems that trust them.

7. Review for the indicators listed by OPSSHIELD, including /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/loot.tgz and /etc/cron.d/i93677. The vendor warns that absence after cleanup does not establish whether the files previously existed.

8. Reset the OPSSHIELD billing portal password and turn on two-factor login, following the later OPSSHIELD disclosure.

9. Contact OPSSHIELD Support if the update fails, the server’s integrity cannot be established, or additional signs of compromise are found. The vendor says a rebuild may be appropriate in those circumstances, while not recommending a full reset or operating-system rebuild as a routine response based on the information currently available.

This advisory is informational and is updated as vendors publish details. Confirm versions and actions against the vendor’s own guidance for your environment.

Sources

• Primary notice: opsshield.com
• Primary notice: opsshield.com
• Research: securitysummits.com
• Research: securitysummits.com
• Report: securityweek.com