cPGuard: canal de atualização sequestrado instalou backdoor em cerca de 2.950 servidores Linux

A OPSSHIELD, fabricante da suíte de segurança para servidores cPGuard, afirma que um atacante invadiu seu servidor de cobrança e publicou uma atualização falsa com uma chave roubada em 2 de novembro de 2026. Durante cerca de 70 minutos, o script rodou como root em servidores Linux de clientes, instalou um shell oculto e copiou hashes de senhas, chaves SSH e credenciais de bancos de dados.

O que aconteceu

A OPSSHIELD publica o cPGuard, uma suíte de segurança (antimalware, firewall, firewall de aplicações web) instalada em servidores Linux de hospedagem de sites. Em 3 de novembro de 2026, a empresa reconheceu que seu canal de atualização tinha sido sequestrado. Segundo o relatório do incidente, o atacante criou em 1º de novembro uma conta de cliente com identidade falsa, pediu uma licença de teste gratuita e explorou uma falha do aplicativo de cobrança para executar comandos no servidor de cobrança e licenças. A partir dali, com uma chave de acesso roubada, enviou uma atualização falsa do cPGuard para o armazenamento de atualizações em 2 de novembro, pouco depois das 02:00 UTC.

Quem é afetado

Os agentes do cPGuard instalaram a atualização falsa entre 02:08 e 03:20 UTC de 2 de novembro, uma janela de cerca de 70 minutos. Executado como root, o script deixou um shell oculto e enviou ao atacante arquivos sensíveis: /etc/shadow e /etc/passwd, as chaves SSH do root, authorized_keys e known_hosts, a senha root do MySQL em /root/.my.cnf, o histórico do shell do root e, em alguns servidores, chaves S3 de /root/.s3cfg. A OPSSHIELD estima em cerca de 2.950 os servidores de clientes afetados. Também foram expostos os dados de cerca de 7.900 contas do portal de cobrança (nome, empresa, endereço postal, e-mail, hashes bcrypt das senhas). O boletim cita as versões 5.88.12 a 5.88.19.

O que fazer agora

1. Atualize cada servidor com cpgcli update --start e confira com cpgcli --version: a OPSSHIELD exige no mínimo a 5.88.25, e a 5.88.26 também revoga o acesso de suporte da empresa.
2. Verifique o histórico com grep 'Successfully updated' /opt/cpguard/logs/install_log. Uma versão entre 5.88.12 e 5.88.19, ou um cPGuard ativo durante a janela, exige tratar o servidor como comprometido.
3. Procure e apague /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/, /etc/cron.d/i93677 e /var/tmp/.i93677/, e procure o endereço IP 94.183.188.91 nos seus logs.
4. Troque a senha do root e de todas as contas locais, além de qualquer senha reutilizada em outros sistemas.
5. Substitua as chaves SSH do root, remova as chaves públicas antigas de todos os servidores que confiavam nelas e revise o authorized_keys.
6. Renove as senhas do MySQL e dos bancos de dados, as chaves S3 e qualquer token ou senha presente no histórico do shell do root.
7. Altere a senha do portal da OPSSHIELD e ative a autenticação em dois fatores, mesmo que seus servidores não tenham sido expostos.
8. Se encontrar sinais de acesso manual, reconstrua o servidor a partir de um backup anterior a 1º de novembro.

Nossa opinião

Um agente de segurança que se atualiza como root é um caminho direto para cada servidor que ele protege: a infraestrutura do fabricante passa a fazer parte da sua superfície de ataque. Mantenha um inventário desses agentes, saiba de onde vêm as atualizações e não deixe segredos no histórico do shell nem em arquivos do root que um único script consegue recolher.

Fontes

• OPSSHIELD — cPGuard security advisory: update channel compromise
• OPSSHIELD — Security incident disclosure
• OPSSHIELD — cPGuard changelog
• The Hacker News — cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

Como escolhemos, verificamos e escrevemos nossas análises →