FlawOpen

flawopen.com/Incidents/ahsaycbs-auth-bypass-command-injection-october-2026

● Ahsay · CVE-2026-105133 · 2026-10-07 · CVSS 10.0 · Crítica
Pesquisa · FlawOpen

AhsayCBS: desvio de autenticação seguido de injeção de comandos

Em 12 de outubro de 2026, a Huntress informa que versões do AhsayCBS até a 10.3.4 são afetadas e que observou ataques desde 7 de outubro. A Ahsay agora diz que as correções anteriores 10.3.4.0 e 9.15.2.59 não resolveram totalmente as duas falhas; orienta parceiros da v10 a aplicar o hotfix 10.3.4.45 e parceiros das v7–v9 a aplicar o 9.15.2.70, seguido de reinicialização. Os detalhes dos hotfixes, restritos a parceiros, não foram verificados de forma independente; confirme a versão instalada e siga as instruções atuais da Ahsay.[1], [8], [3], [4]

💡 Explicação em Linguagem Simples (ELI5)

Imagine alguém passando pela verificação de identidade da sala de backups e depois entregando uma nota ao operador. O endpoint de recebimento tratou dados controlados pelo invasor como parte de um comando do sistema operacional, fazendo com que a nota pudesse ser interpretada como instrução, não como dado. A analogia descreve a cadeia relatada pela Huntress; a implementação exata da Ahsay não é pública.[1], [3], [4]

Conceitos Centrais e Termos

CVE-2026-105133
Falha de autenticação de gravidade média relatada na função checkSysPwd do AhsayCBS. A Huntress a descreve como a primeira etapa da cadeia observada.[3], [1]
CVE-2026-105134
Falha crítica de injeção de comandos do sistema operacional, CVSS 10.0, relatada na API Replication Receiver em /rps/api/json/UpdateReceivers.do. Segundo a Huntress, ela permitiu execução de código após o desvio de autenticação. A pontuação 10.0 se aplica a esta CVE, não às duas falhas.[4], [1]
Status dos hotfixes em 12 de outubro de 2026
Os registros CVE inicialmente indicavam a 10.3.4 como corrigida, mas a Huntress depois encontrou versões até a 10.3.4 afetadas. Os comunicados da Ahsay de 10 e 12 de outubro substituem a posição de 9 de outubro: as correções 10.3.4.0 e 9.15.2.59 não resolveram totalmente as duas falhas. A Ahsay orienta parceiros v10 a usar 10.3.4.45 e parceiros v7–v9 a usar 9.15.2.70, seguidos de reinicialização. São instruções do fornecedor; o conteúdo e a eficácia dos hotfixes restritos a parceiros não foram verificados de forma independente.[1], [8], [3], [4]

Mapeamentos de frameworks

  • Referência CWE para a fraqueza descrita neste guia: CWE-78 CWE-287

Status das versões e ação defensiva

Fonte da evidênciaO que informaDecisão operacional
Registros CVE (4 de out.)Inicialmente indicam a 10.3.4 como corrigida para as duas CVEs.Trate essa informação como contestada; confirme a correção diretamente com a Ahsay antes de encerrar a remediação.
Huntress (8 de out.)Relata exploração e diz que versões até a 10.3.4 também eram afetadas.Considere potencialmente afetados os sistemas até a 10.3.4; restrinja o acesso de gerenciamento e investigue.
Notas da versão Ahsay v10.3.4 (5 de ago.)Não mencionam nenhuma das CVEs nem uma correção de segurança para elas.Não conclua que a 10.3.4 corrigiu essas CVEs apenas com base nas notas da versão.
Notas da versão Ahsay v10.3.2 (20 jul.)Listam um “Ahsay Security Patchset - 2026/Q3” genérico, mas não identificam estas CVEs nem uma versão corrigida.Não considere o nome genérico do pacote como prova de que estas CVEs foram corrigidas. Depois, a Huntress informou que a v10.3.4 também era afetada.
Suspeita de comprometimento em qualquer versãoO número da versão não descarta exploração anterior nem persistência.Investigue o host, preserve evidências, avalie a integridade dos backups e use procedimentos de recuperação confiáveis.
Comunicados da Ahsay (10 e 12 out.)As correções anteriores 10.3.4.0 e 9.15.2.59 não resolveram totalmente as duas falhas. A Ahsay orienta parceiros v10 a usar 10.3.4.45 e parceiros v7–v9 a usar 9.15.2.70, e reiniciar.Siga a orientação do fornecedor para sua versão, reinicie e confirme a build instalada pelo canal de parceiros; o conteúdo do hotfix não foi inspecionado de forma independente.

Linha do Tempo do Incidente

2026-10-04

Os registros CVE das duas falhas do AhsayCBS foram publicados e inicialmente indicaram a versão 10.3.4 como corrigida.[3], [4]

2026-10-07 23:20:15 UTC

A Huntress começou a observar a exploração das falhas contra sistemas expostos.[1]

2026-10-08

A Huntress informou que cinco organizações foram alvo e corrigiu a avaliação anterior: também encontrou falhas na versão 10.3.4.[1]

2026-10-09

Na publicação de 9 de outubro, nenhuma versão corrigida confirmada pelo fornecedor havia sido identificada.[5]

2026-10-10

A Ahsay informou que a v10.3.4.0 não corrigiu totalmente as duas falhas e orientou parceiros v10 a usar o hotfix 10.3.4.45.[8]

2026-10-12

A Ahsay atualizou a orientação: parceiros v10 devem aplicar 10.3.4.45; parceiros v7–v9, 9.15.2.70. Reinicie após qualquer hotfix.[8]

Fluxo de Ataque Passo a Paso

Passo 1

A interface de gerenciamento exposta pode ser acessada

A Huntress afirma que a atividade observada visou interfaces web do AhsayCBS acessíveis pela internet, usado por provedores de serviços gerenciados e integradores de sistemas.[1]

Passo 2

A barreira de autenticação é contornada

A Huntress atribui a primeira etapa à CVE-2026-105133 e à função checkSysPwd em ApiStructsAction.java. Essa é a descrição da equipe de resposta; as fontes analisadas não disponibilizam o código vulnerável do fornecedor.[1], [3]

Passo 3

A falha no Replication Receiver permite execução de código

A Huntress relaciona a CVE-2026-105134 à injeção de comandos em /rps/api/json/UpdateReceivers.do. Segundo o relato, os invasores configuraram um receiver e colocaram webshells JSP no diretório servido pela aplicação. Nenhuma sintaxe de requisição ou payload é reproduzida.[1], [4]

Passo 4

Trate o caso como possível comprometimento do host

Nos casos afetados, a Huntress observou atividade de processos filhos do serviço, webshells, software de mineração disfarçado e persistência. Restrinja o acesso de gerenciamento, investigue o host e os backups e siga orientações de reconstrução confiável se confirmar o comprometimento.[1], [6]

Código-Fonte: Vulnerável vs. Seguro

O exemplo seguro usa um executável fixo, uma lista de permissões explícita e argumentos separados no ProcessBuilder; não chama um shell nem concatena a entrada do usuário em uma string de comando. Este é um padrão defensivo genérico que mostra como fechar a fronteira de interpretação de comandos do sistema operacional, não o código-fonte nem a correção da Ahsay. As fontes públicas consultadas não mostram a implementação ou a correção do fornecedor.[1], [3], [4]

IMPLEMENTAÇÃO VULNERÁVEL
// Apenas um antipadrão genérico; não é código-fonte da Ahsay.
void updateReceiver(Request request) {
    String receiver = request.parameter("receiver");
    String command = commandBuilder.forReceiverUpdate(receiver);
    operatingSystem.execute(command); // unsafe command-string boundary
}
PATCH SEGURO E ROBUSTO
// Apenas um projeto defensivo genérico; não é um patch da Ahsay.
private static final Set<String> ALLOWED_RECEIVERS = Set.of("primary", "archive");

void updateReceiver(Principal principal, ReceiverInput input) throws IOException {
    authorization.require(principal, Permission.MANAGE_RECEIVERS);
    String receiver = input.receiverId();
    if (!ALLOWED_RECEIVERS.contains(receiver)) {
        throw new IllegalArgumentException("Unsupported receiver");
    }
    new ProcessBuilder("/usr/local/bin/replication-tool", "update", "--receiver", receiver)
        .start(); // fixed executable; separate arguments; no shell
}

Lista de Verificação de Segurança para Engenharia

Fontes