← Voltar ao feed
critical hosting it

cPGuard update channel hijacked to push backdoor and steal SSH and database credentials from about 2,946 Linux servers

2 fonte(s) · 2 atualização(ões) · publicado 03/11/2026 12:16 · coletado há 4 horas

Matéria consolidada. Reúne 2 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que as 2 fontes trouxeram em 04/11/2026 00:01; os links antigos trazem para cá.

Fontes: bleepingcomputer.com ↗ thehackernews.com ↗

Attackers compromised the update infrastructure of cPGuard, a Linux server security suite made by OPSSHIELD (also written OpsShield), and on November 2, 2026 at 02:06 UTC used stolen legitimate credentials to push a malicious script to customers running versions 5.88.12 through 5.88.19 (thehackernews.com, bleepingcomputer.com). The script installed a backdoor and exfiltrated sensitive files to a compromised account on OPSSHIELD's licensing server. OpsShield told BleepingComputer that 2,946 servers were affected and that its own billing database was also copied (bleepingcomputer.com). The vendor detected the attack and halted distribution within 12 hours, revoked infrastructure credentials, secured the licensing account and released version 5.88.25, which removes the backdoor and the collected files. Stolen credentials remain valid until rotated, and the initial access vector is still under investigation. The attacker is unidentified.

Detalhes técnicos

  • The attacker abused compromised credentials, of unknown origin, to access OpsShield's update distribution CDN and disguise the payload as a legitimate cPGuard update (bleepingcomputer.com). cPGuard is used alongside cPanel, DirectAdmin and Plesk and is offered by hosts such as Namecheap (bleepingcomputer.com).
  • The malicious script was cpguard-v58812-i91511.sh. It dropped a backdoor shell at /var/tmp/.cpg91511_sh and staged loot in /var/tmp/.cpg91511/loot.tgz before uploading it to the licensing server (thehackernews.com).
  • Targeted data: /etc/shadow, /etc/passwd, MariaDB/MySQL configuration files, root's shell history, and SSH authorization and known-hosts files (thehackernews.com, bleepingcomputer.com).
  • The attackers then accessed the licensing server to retrieve the exfiltrated files (bleepingcomputer.com).
  • Some servers may have escaped infection because of update-check timing intervals (bleepingcomputer.com).
  • To check exposure, run grep 'Successfully updated' /opt/cpguard/logs/install_log. A clean log does not prove the script did not run, and updating removes the backdoor files but not evidence of earlier execution (thehackernews.com).

Remediação

  • Run cpgcli update --start and confirm cpgcli --version reports 5.88.25 or later (thehackernews.com, bleepingcomputer.com).
  • On servers that ran or may have run the script, reset root and local account passwords from a trusted recovery environment (thehackernews.com).
  • Rotate database passwords, S3 keys, DigitalOcean tokens and any secrets in shell history (thehackernews.com). Rotate cloud secrets and SSH keys generally (bleepingcomputer.com).
  • Replace SSH private keys under /root/.ssh and remove the corresponding public keys elsewhere (thehackernews.com).
  • OPSSHIELD is issuing a separate update to strip its support-access SSH keys from customer servers as a precaution (thehackernews.com, bleepingcomputer.com).
  • The vendor recommends contacting its support team for case-by-case review rather than a blanket OS rebuild (thehackernews.com).

Relatos divergentes

  • Scale and file count: thehackernews.com (earlier) says OPSSHIELD estimates 32 files were exfiltrated from affected customer servers and that the figure may still change. bleepingcomputer.com (later) says 32 files were stolen per customer on average and gives a total of 2,946 affected servers. The later BleepingComputer report, which cites the vendor directly, is the more specific one. The total number of files is not stated.
  • Compromised component: thehackernews.com describes the update infrastructure and credentials generally. bleepingcomputer.com specifies the update distribution CDN.
  • Billing database: only bleepingcomputer.com reports that OpsShield's billing database was copied. thehackernews.com does not mention it.

Linha do tempo

  1. bleepingcomputer.com ↗ · pub. 03/11/2026 19:18 · coletado 03/11 21:00

    cPGuard Update Infrastructure Hijacked to Push Backdoor, Steal SSH/DB Credentials from ~2,946 Servers

    ler a análise desta fonte

    Attackers compromised OpsShield's update distribution CDN for cPGuard, a Linux web-server security suite used alongside cPanel, DirectAdmin, and Plesk, and widely offered by hosts like Namecheap. Using stolen legitimate credentials, the attacker pushed a malicious script via the cPGuard update channel on November 2, 2026 at 02:06 UTC, affecting versions 5.88.12 through 5.88.19. The script harvested root MariaDB/MySQL configuration and root SSH authorization/known-hosts files, exfiltrating the data through a compromised account on OpsShield's licensing server. OpsShield confirmed to BleepingComputer that 2,946 servers were affected, with 32 files stolen per customer on average, and that its own billing database was also copied.

    Technical Details

    The attacker gained unauthorized access to OpsShield's CDN using compromised credentials (origin unknown) and used it to distribute a backdoor and data-stealing script disguised as a legitimate cPGuard update. The malicious payload targeted root-level database configuration and SSH credentials, uploading stolen data to OpsShield's own licensing server infrastructure, which the attackers then accessed to retrieve the exfiltrated files. OpsShield detected and halted the malicious distribution within 12 hours, though some servers may have avoided infection due to update-check timing intervals.

    Remediation

    OpsShield urges all customers to update cPGuard to version 5.88.25 or later, which removes the backdoor and staged malicious files, and to immediately reset passwords and rotate database credentials, cloud secrets, and SSH keys, since stolen credentials remain valid until invalidated. The vendor also plans to release an additional update removing previously installed OpsShield support-access keys as a further precaution.

  2. thehackernews.com ↗ · pub. 03/11/2026 12:16 · coletado 03/11 14:00 primeiro registro

    cPGuard Update Channel Hijacked to Deploy Backdoor and Steal Password Hashes from Linux Servers

    ler a análise desta fonte

    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_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.

    Remediation

    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.