cPGuard Update Channel Hijacked to Deploy Backdoor and Steal Password Hashes from Linux Servers
An unidentified attacker compromised the update infrastructure of cPGuard, a Linux security tool made by OPSSHIELD, and used compromised credentials to push a malicious script to customers via versions 5.88.12 through 5.88.19, released starting November 2, 2026 at 02:06 UTC. The script installed a backdoor and exfiltrated /etc/shadow, /etc/passwd, MariaDB/MySQL configuration files, root's shell history, and SSH authorization/known-hosts files to an OPSSHIELD-run licensing server using a compromised account. OPSSHIELD detected the attack within 12 hours, revoked infrastructure credentials, secured the licensing account, and released version 5.88.25 to remove the backdoor and collected files, though stolen credentials may still be valid. OPSSHIELD estimates 32 files were exfiltrated from affected customer servers, a number that may still change, and is still investigating the initial access vector.
Detalhes técnicos
The malicious script (cpguard-v58812-i91511.sh) dropped a backdoor shell at /var/tmp/.cpg91511_sh and staged stolen data in /var/tmp/.cpg91511/loot.tgz before uploading it to OPSSHIELD's licensing server. Admins can check exposure by running grep 'Successfully updated' /opt/cpguard/logs/install_log to identify affected versions, though a clean log does not guarantee the script did not run, and removal of the backdoor files by updating does not erase evidence it previously executed.
Remediação
OPSSHIELD urges all cPGuard admins to run cpgcli update --start and verify cpgcli --version reports 5.88.25 or later. For servers that ran or may have run the script, admins should reset root and local account passwords from a trusted recovery environment, rotate database passwords, S3 keys, DigitalOcean tokens, and any secrets in shell history, and replace SSH private keys under /root/.ssh while removing corresponding public keys elsewhere. OPSSHIELD is also issuing a separate update to strip its support-access SSH keys from customer servers as a precaution, and recommends contacting its support team for case-by-case review rather than a blanket OS rebuild.
Linha do tempo
-
cPGuard Update Channel Hijacked to Deploy Backdoor and Steal Password Hashes from Linux Servers
ler a análise desta fonte ocultar
An unidentified attacker compromised the update infrastructure of cPGuard, a Linux security tool made by OPSSHIELD, and used compromised credentials to push a malicious script to customers via versions 5.88.12 through 5.88.19, released starting November 2, 2026 at 02:06 UTC. The script installed a backdoor and exfiltrated /etc/shadow, /etc/passwd, MariaDB/MySQL configuration files, root's shell history, and SSH authorization/known-hosts files to an OPSSHIELD-run licensing server using a compromised account. OPSSHIELD detected the attack within 12 hours, revoked infrastructure credentials, secured the licensing account, and released version 5.88.25 to remove the backdoor and collected files, though stolen credentials may still be valid. OPSSHIELD estimates 32 files were exfiltrated from affected customer servers, a number that may still change, and is still investigating the initial access vector.
Technical Details
The malicious script (cpguard-v58812-i91511.sh) dropped a backdoor shell at /var/tmp/.cpg91511_sh and staged stolen data in /var/tmp/.cpg91511/loot.tgz before uploading it to OPSSHIELD's licensing server. Admins can check exposure by running
grep 'Successfully updated' /opt/cpguard/logs/install_logto identify affected versions, though a clean log does not guarantee the script did not run, and removal of the backdoor files by updating does not erase evidence it previously executed.Remediation
OPSSHIELD urges all cPGuard admins to run
cpgcli update --startand verifycpgcli --versionreports 5.88.25 or later. For servers that ran or may have run the script, admins should reset root and local account passwords from a trusted recovery environment, rotate database passwords, S3 keys, DigitalOcean tokens, and any secrets in shell history, and replace SSH private keys under /root/.ssh while removing corresponding public keys elsewhere. OPSSHIELD is also issuing a separate update to strip its support-access SSH keys from customer servers as a precaution, and recommends contacting its support team for case-by-case review rather than a blanket OS rebuild.