AhsayCBS: a versão instalada não é evidência suficiente de correção

A Huntress observou ataques que combinam duas falhas no AhsayCBS para ultrapassar a autenticação e executar comandos em servidores de backup.[3] O detalhe que exige atenção é a correção: enquanto registros da NVD apontavam a versão 10.3.4 como solução, a Huntress informou que essa mesma versão permanecia afetada.[3]

Para a operação, isso desmonta um critério de encerramento comum demais: comparar o número instalado com uma tabela e marcar o risco como resolvido. O inventário é uma entrada da análise, não o resultado dela.

O que muda para quem desenvolve

A CVE-2026-105133 envolve autenticação inadequada em checkSysPwd(), enquanto a CVE-2026-105134 permite injeção de comandos no Replication Receiver.[3] A combinação observada conecta uma falha de controle de acesso à execução no sistema.[3]

Nos incidentes descritos, os invasores fizeram reconhecimento, implantaram web shells e executaram mineração de criptomoedas.[3] O XMRig apareceu como edge.exe, e um script chamado Taskgmr.ps1 buscava reduzir a visibilidade da mineração quando o Gerenciador de Tarefas era aberto.[3]

A consequência arquitetural é tratar a administração do backup como uma fronteira própria. Um serviço que protege a recuperação do ambiente não deve receber acesso amplo apenas porque precisa conversar com outras máquinas. Separe as necessidades de replicação das necessidades de administração e documente quem realmente precisa de cada caminho.

Como aplicar

Primeiro, localize instalações do AhsayCBS sob responsabilidade da equipe e verifique a exposição da interface administrativa. A mitigação indicada na reportagem é restringir esse acesso a IPs confiáveis ou a uma VPN e investigar sinais de comprometimento.[3] Não espere uma discussão sobre versão terminar para aplicar uma contenção de rede apropriada.

Depois, confira processos, alterações na aplicação web, scripts PowerShell e downloads de drivers no período relevante. Preserve os registros e compare com uma referência conhecida do ambiente. Um nome parecido com software legítimo não deve bastar para liberar um executável desconhecido.

Para validar uma futura correção, defina antes o critério de aceite: a cadeia indevida precisa ser bloqueada, e a função legítima de replicação precisa continuar funcionando. Faça essa avaliação somente em ambiente de homologação autorizado, com dados descartáveis e procedimento aprovado. Não transforme a investigação numa tentativa improvisada contra produção.

Um exercício adicional é testar a restauração a partir de uma cópia isolada e medir se ela atende ao prazo esperado. Isso não valida o patch, mas verifica uma capacidade diferente que o incidente coloca em risco: recuperar o serviço mesmo quando o servidor de backup precisa ser retirado de operação.

Cuidados e limites

Até 8 de outubro, a investigação estimava cinco organizações afetadas; uma atualização relatou outro incidente, sem demonstrar exploração generalizada.[3] A suspeita de uso de IA na criação do script não foi apresentada como autoria comprovada.[3]

O texto trata as falhas como sem correção efetiva no cenário observado e não sustenta que instalar a 10.3.4 seja suficiente.[3] Essa é uma informação datada da investigação, não uma declaração sobre toda atualização que possa surgir depois.

Restringir a rede também não prova ausência de invasão anterior. Contenção, investigação e recuperação são entregas distintas. O risco só deve ser encerrado quando houver evidência para cada uma delas, não quando o painel de versões ficar verde.

Fonte

[3] Fonte: The Hacker News | Publicação: 09/10/2026 às 09:47:26