Hackers Hijacked Linux Hosting Server Security Tool cPGuard and Used It as a Backdoor

An unidentified attacker compromised the update channel for cPGuard, a security tool used on Linux hosting servers, to distribute a malicious script that installed a backdoor and collected sensitive files. OPSSHIELD confirmed that the attacker retrieved some stolen data and urged administrators to install version 5.88.25 or later immediately.

According to OPSSHIELD’s security advisory, the breach began on November 2, 2026, at 02:06 UTC. The attacker used compromised credentials to access the company’s update distribution infrastructure, or CDN. How those credentials were obtained remains under investigation.

cPGuard Supply Chain Attack

The attacker distributed the script through cPGuard versions 5.88.12 through 5.88.19. OPSSHIELD detected the attack within 12 hours of the affected updates becoming available, secured the compromised account, cleared infrastructure credentials, and stopped further distribution. Because servers check for updates at intervals, some may not have executed the malicious script.

The attack turned a trusted security update into a route for malware delivery. Related Cybersecuritynews coverage of compromised Terraform workflows shows another way attackers have used trusted software processes to deliver backdoors. The cPGuard incident specifically involved stolen access to the vendor’s distribution infrastructure.

The malicious script collected Linux account files, including /etc/shadow and /etc/passwd, root MariaDB or MySQL configuration, root shell history, and root SSH authorization and known-hosts files. OPSSHIELD has not established that every listed file was collected from every affected server.

Collected data went to OPSSHIELD’s own licensing server under a compromised account, where the attacker could retrieve it later. In a November 3 update, the company estimated that the attacker retrieved 32 collected files, each corresponding to one customer server. That preliminary figure measures confirmed retrieval, not the total number of potentially affected servers.

Linux passwords in /etc/shadow are stored as hashes rather than readable passwords. Attackers can test password guesses against stolen hashes offline, making weak or reused passwords particularly risky. Database configuration and shell history may contain other secrets without that protection.

The wider concern is credential reuse beyond the original server. Cybersecuritynews previously covered QLNX credential theft targeting Linux developers, another case highlighting the value of SSH keys and cloud credentials to attackers. No connection between these incidents has been established.

Administrators should review update history with grep 'Successfully updated' /opt/cpguard/logs/install_log. Entries showing versions 5.88.12 through 5.88.19 confirm installation of an affected update, but do not prove script execution or data transfer. Missing or incomplete logs also cannot establish that a server escaped compromise.

Known indicators include the script cpguard-v58812-i91511.sh, backdoor shell /var/tmp/.cpg91511_sh, collection directory /var/tmp/.cpg91511, and staged archive /var/tmp/.cpg91511/loot.tgz. Their absence after cleanup does not rule out earlier execution.

OPSSHIELD instructs every customer to run cpgcli update --start, then check cpgcli --version to confirm version 5.88.25 or later. Administrators whose updates fail should contact OPSSHIELD Support. The corrective update removes the known backdoor and staged files, but cannot invalidate credentials already copied.

Potentially compromised servers require password resets for root and other password-enabled local accounts from a trusted recovery environment. Administrators should rotate affected database passwords, S3 keys, DigitalOcean tokens, and exposed shell-history secrets. They should replace private keys under /root/.ssh and remove corresponding old public keys wherever trusted.

OPSSHIELD is also releasing an update to remove previously added support-access keys. It does not currently recommend routine server rebuilds, but that guidance remains provisional. Additional compromise signs or uncertain server integrity may justify rebuilding after an individual assessment.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.