CVE-2026-106931: falha no WAF SiteGuard sob exploração ativa

Aviso do JVN e do JPCERT/CC confirma exploração em ataques reais de uma injeção de comandos na função de estatísticas do WAF, habilitada por padrão. A correção cobre até versões fora de suporte — e o fabricante pede que evidências sejam preservadas antes do patch.

Ilustração abstrata de uma barreira de proteção atravessada por um trajeto luminoso, representando a falha no WAF SiteGuard

Imagem editorial original do Plugged Ninja.

O JPCERT/CC e o portal japonês JVN publicaram em 14 de outubro de 2026 um aviso sobre uma falha de injeção de comandos no SiteGuard Server Edition, firewall de aplicação web (WAF) instalado diretamente no servidor. A vulnerabilidade recebeu o identificador CVE-2026-106931 e, segundo o próprio aviso, já foi confirmada como explorada em ataques reais.

O ponto que torna o caso incômodo é a posição do produto afetado. Um WAF existe para inspecionar o tráfego que chega à aplicação e barrar requisições maliciosas. Quando a falha está no próprio WAF — e permite executar comandos do sistema operacional com privilégios de root ou SYSTEM — o controle de segurança deixa de ser barreira e passa a ser caminho de escalada.

O fabricante, a japonesa EG Secure Solutions, avisou clientes com contrato de suporte direto em 29 de setembro de 2026 e publicou o alerta público 202610-1 em outubro. A correção já está disponível, inclusive para versões fora de suporte, e há uma recomendação pouco usual que merece atenção: preservar evidências antes de aplicar o patch.

Contexto: o que é o SiteGuard Server Edition

O SiteGuard Server Edition é um WAF do tipo host-based, ou seja, instalado no mesmo servidor que hospeda a aplicação, integrado ao servidor web. Diferente de um WAF em nuvem, que filtra o tráfego antes que ele chegue à infraestrutura, o modelo host-based roda como módulo do Apache httpd, do Nginx ou do IIS. Isso dá visibilidade sobre o tráfego já descriptografado, mas também coloca o produto dentro do perímetro que ele deveria proteger.

Segundo material comercial do fabricante citado pelo BleepingComputer, a linha SiteGuard é usada em mais de 1,5 milhão de sites. O produto é bastante difundido no mercado japonês, onde a EG Secure Solutions atua como fornecedora de segurança para hospedagem e aplicações web.

Atenção: Server Edition não é o mesmo que o plugin gratuito

Vale separar duas coisas que costumam ser confundidas, porque a marca é a mesma. O aviso do JVN trata especificamente do SiteGuard Server Edition, produto comercial instalado no servidor. Existe também o SiteGuard WP Plugin, extensão gratuita para WordPress, com base instalada na casa das centenas de milhares de sites.

O aviso oficial não lista o plugin do WordPress entre os produtos afetados, e não localizamos comunicado do fabricante estendendo a falha a ele. Administradores de WordPress que usam apenas o plugin não devem, com base nas informações públicas até 19 de outubro de 2026, assumir que estão expostos a esta CVE — mas vale acompanhar o canal de avisos do fabricante, já que a coordenação ainda está em curso.

Detalhes da CVE-2026-106931

A falha é uma injeção de comandos do sistema operacional (CWE-78) localizada na função de estatísticas do produto. Esse detalhe é relevante por um motivo prático: segundo o aviso do JVN, a função de estatísticas vem habilitada por padrão. Instalações que nunca tiveram essa configuração revisada tendem a estar na condição vulnerável.

Item Informação oficial
Identificador CVE-2026-106931
Aviso JVN#88474777 / JPCERT-AT-2026-0032 / JVNDB-2026-000148
Tipo Injeção de comandos do SO (CWE-78)
CVSS v4.0 8.5 — CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CVSS v3.0 7.8 — CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Condição Função de estatísticas ativa (padrão de fábrica)
Impacto Execução de comandos arbitrários como root ou SYSTEM
Exploração Confirmada em ambiente real pelo fabricante e pelo JPCERT/CC
Publicação do aviso 14 de outubro de 2026

Versões afetadas e versões corrigidas

  • Apache httpd, Nginx e IIS: da versão 2.20 em diante, até antes da 8.00 Update 5. A correção é a 8.00 Update 5.
  • Apache httpd e Nginx em FreeBSD: da versão 2.20 em diante, até antes da 7.00 Update 6. A correção é a 7.00 Update 6.
  • Exceção informada pelo JPCERT/CC: as edições para IIS da versão 3.10 até a 4.00 Update 4 não são afetadas.

Como ler o vetor CVSS sem exagerar o risco

Aqui entra a parte que a manchete costuma perder. Os dois vetores publicados indicam AV:L (vetor de ataque local) e PR:L (requer privilégios baixos). Em outras palavras: pelas métricas oficiais, não se trata de uma execução remota de código sem autenticação, em que qualquer pessoa na internet alcança o servidor diretamente.

O cenário descrito pelas métricas é o de um atacante que já dispõe de algum acesso ao sistema — uma conta de baixo privilégio, um shell obtido por outra falha, uma credencial de hospedagem compartilhada — e usa a função de estatísticas do WAF para saltar desse patamar até root ou SYSTEM. O valor da falha para um atacante está na escalada, não na porta de entrada.

Vale lembrar que a limitação de um WAF como camada única de defesa já apareceu em outros casos que cobrimos, como o bypass do WAF do Google por requisições POST superdimensionadas. A diferença, aqui, é que a falha não contorna o WAF: ela parte de dentro dele.

Isso não reduz a gravidade, e convém dizer por quê. Em ambientes de hospedagem compartilhada, acesso de baixo privilégio é mercadoria barata e abundante. E o alvo da escalada é justamente o componente que registra e filtra o tráfego: quem chega a root por esse caminho fica em posição de desligar o WAF, adulterar seus registros e apagar o rastro da intrusão original. Vale registrar que o aviso público não detalha o método usado nos ataques observados, nem o volume ou o perfil das vítimas — o fabricante afirma apenas que o abuso foi confirmado.

Impactos, limitações e o que ainda não se sabe

Para quem opera o produto, o efeito prático imediato é a necessidade de tratar o servidor como potencialmente comprometido, e não apenas como pendente de atualização. Há exploração confirmada e há um intervalo de pelo menos duas semanas e meia entre o aviso privado aos clientes de suporte direto (29 de setembro) e a publicação do aviso público (14 de outubro) — janela em que organizações sem contrato direto não tinham como saber do problema.

Do lado das limitações da informação disponível: não há indicadores de comprometimento publicados, não há atribuição a nenhum grupo, não há contagem de vítimas e não há detalhamento técnico da exploração. Isso é comum em coordenação feita sob o modelo japonês de divulgação, que prioriza a correção sobre o detalhamento, mas significa que a caça a ameaças precisa ser feita com base em comportamento, não em listas prontas de IoCs.

Há ainda um ponto favorável pouco comum nesse tipo de aviso: o fabricante disponibilizou correção inclusive para versões em fim de vida, via patch que substitui os arquivos de processamento estatístico. Isso remove a desculpa mais frequente para deixar um sistema legado sem tratamento e, na prática, amplia bastante o alcance da remediação.

Recomendações práticas

  1. Preserve evidências antes de corrigir. O fabricante alerta que a atualização e o patch podem apagar vestígios do ataque. Antes de mexer, baixe as informações de diagnóstico pela tela de gerenciamento web, em Informações de diagnóstico > Baixar informações de diagnóstico, e guarde uma cópia fora do servidor.
  2. Atualize para a versão corrigida — 8.00 Update 5, ou 7.00 Update 6 no caso de FreeBSD. Se a atualização não for viável, aplique o patch oficial, que também cobre versões fora de suporte.
  3. Verifique se a função de estatísticas está ativa. Como ela vem habilitada por padrão, a ausência de uma decisão explícita de desativá-la significa, muito provavelmente, que está ligada.
  4. Procure sinais de pós-exploração, já que não há IoCs públicos: processos filhos inesperados gerados pelo processo do servidor web ou do WAF, binários e tarefas agendadas criados por volta do fim de setembro em diante, contas novas com privilégio elevado, alterações em chaves SSH autorizadas e lacunas nos registros do próprio WAF.
  5. Revise a retenção de logs. Se o seu período de retenção for menor que o intervalo desde 29 de setembro de 2026, a evidência do acesso inicial pode já ter sido descartada — e isso precisa constar da avaliação de risco.
  6. Consulte o aviso oficial do JVN e o alerta do fabricante antes de concluir o tratamento, porque a coordenação segue em andamento e a página do JVN já passou por uma revisão.

Conclusão

A CVE-2026-106931 não é uma falha de execução remota aberta à internet, e tratá-la como tal seria impreciso. É algo diferente e, em certos ambientes, igualmente incômodo: um mecanismo de escalada para root embutido num produto de segurança, ativo por padrão, com exploração já confirmada e sem indicadores públicos que facilitem a detecção.

Para equipes que operam o SiteGuard Server Edition, o roteiro é curto e tem ordem definida — preservar evidência, corrigir, caçar sinais de pós-exploração. O que vale observar nas próximas semanas é se o fabricante ou o JPCERT/CC divulgarão detalhes técnicos da exploração ou indicadores, e se a coordenação se estenderá a outros produtos da família SiteGuard.

Fontes e referências

PLUGGED NINJA
Informações de privacidade

Este site usa cookies para que possamos oferecer a melhor experiência de usuário possível. As informações dos cookies são armazenadas em seu navegador e executam funções como reconhecê-lo quando você retorna ao nosso site e ajudar nossa equipe a entender quais seções do site você considera mais interessantes e úteis.