A OPSSHIELD relatou que o canal de atualização do cPGuard distribuiu um script malicioso para servidores Linux nas versões 5.88.12 a 5.88.19. O script podia instalar um backdoor e coletar arquivos sensíveis. Para avaliar a exposição, verifique se uma versão afetada foi instalada, mas não trate o registro como prova de que o script foi executado ou de que dados saíram do servidor.

Como o script chegou aos servidores

Segundo o relato posterior da OPSSHIELD, um invasor obteve acesso ao servidor de faturamento e licenciamento da empresa em 1º de novembro de 2026. Na madrugada de 2 de novembro, usou a chave de publicação de atualizações para enviar o script ao sistema do cPGuard. A divulgação situou as instalações nos servidores de clientes entre 02h08 e 03h20 UTC.

O script teria instalado um shell oculto com permissões de administrador e criado uma tarefa agendada para manter a persistência. Entre os arquivos que teria tentado coletar estavam hashes de senhas, arquivos SSH do root, credenciais de banco de dados presentes em /root/.my.cnf e o histórico do shell. Em um pequeno número de servidores, também teria buscado /root/.s3cfg. Esses arquivos podem conter segredos, mas a lista não significa que todos estivessem presentes em cada máquina.

Como verificar se uma versão afetada foi instalada

A faixa relatada como afetada é 5.88.12 a 5.88.19. O comando indicado para procurar registros de atualização é:

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

Uma entrada correspondente a uma versão afetada indica que a atualização foi instalada; não confirma que o script rodou nem que houve exfiltração. Logs ausentes ou incompletos também não descartam exposição. Como uma atualização pode remover rastros, não encontrar os arquivos suspeitos depois de atualizar tampouco prova que o script nunca foi executado.

A divulgação da OPSSHIELD situou a instalação do script entre 02h08 e 03h20 UTC de 2 de novembro. Segundo esse relato, servidores que permaneceram com o cPGuard desligado durante toda essa janela não receberam o script.

Rastos a procurar e impacto relatado

Os caminhos associados aos rastros do script incluem /var/tmp/.cpg91511_sh, /etc/cron.d/i93677 e /var/tmp/.i93677/. A divulgação também citou /var/tmp/.cpg91511 e o arquivo /var/tmp/.cpg91511/loot.tgz como parte da coleta. A ausência desses caminhos após uma atualização, por si só, não elimina a possibilidade de execução anterior.

Na divulgação posterior, a OPSSHIELD estimou que cerca de 2.950 servidores de clientes executaram o script. Também informou que registros de faturamento de cerca de 7.900 contas foram levados e que cópias de três servidores em nuvem da empresa foram feitas. Uma estimativa inicial de 32 arquivos ligados a servidores de clientes dizia respeito a arquivos retirados do servidor de licenciamento, não ao total de servidores que executaram o script.

O que a sequência de correções tratou

A orientação inicial citou a versão 5.88.25 como correção. Depois, a OPSSHIELD atribuiu à versão 5.88.26 a remoção do backdoor e a uma atualização separada a remoção da tarefa agendada. A versão dessa atualização de acompanhamento não foi informada no relato.

Medidas para servidores potencialmente afetados

A resposta relatada pela OPSSHIELD separa a atualização do software da proteção dos segredos que podem ter sido copiados:

  1. Atualize o cPGuard.
  2. Verifique os caminhos associados ao backdoor, à tarefa agendada e à coleta, removendo os rastros que ainda estiverem presentes.
  3. Troque as senhas locais e reutilizadas e renove as credenciais de banco de dados e de serviços em nuvem que possam ter sido expostas. Substitua as chaves SSH potencialmente afetadas e revise authorized_keys, inclusive para remover chaves públicas antigas que ainda sejam confiáveis.
  4. Troque também as credenciais do portal de faturamento da OPSSHIELD se puderem ter sido expostas.

Atualizar o cPGuard não invalida automaticamente credenciais que possam ter sido copiadas. A OPSSHIELD não recomendou reconstruir todos os servidores como resposta rotineira: o relato indicou análise caso a caso e reconstrução a partir de um backup limpo quando a empresa confirmasse que o invasor havia feito login manualmente.