O que você precisa fazer: levantar onde há SiteGuard Server Edition na casa, incluindo instalação feita por integrador, e checar duas coisas em cada uma: a versão e se a função de estatística está habilitada. Se a versão é 2.20 ou superior e a estatística está ligada, você está na lista. Antes de tocar no software, salvar a Informação de Diagnóstico pela tela de administração web, porque a atualização substitui os arquivos de processamento estatístico e leva o rastro com eles.
Depois disso, atualizar para a 8.00 Update 5 em Apache httpd, Nginx ou IIS, ou para a 7.00 Update 6 em Apache httpd e Nginx no FreeBSD. Onde a atualização não cabe agora, aplicar o patch do fabricante, que existe até para versão fora de suporte, ou desabilitar a estatística como contorno. E tratar o servidor como suspeito: como a execução acontece com privilégio máximo, a verificação precisa olhar para fora da caixa, em log de rede, registro de firewall e telemetria de endpoint.
O SiteGuard Server Edition é um firewall de aplicação web da EG Secure Solutions, de Tóquio, com bastante presença no Japão. A característica que importa aqui é arquitetural: ele não fica na frente do servidor web, ele roda dentro dele, como módulo do Apache httpd, do Nginx ou do IIS. Isso dá a ele o privilégio do processo que inspeciona o tráfego.
A falha está na função de processamento estatístico, aquela que monta o relatório de requisições bloqueadas. É injeção de comando de sistema, CWE-78, e a função vem habilitada por padrão. O resultado é comando arbitrário executado com privilégio de root no Linux e no FreeBSD, ou de SYSTEM no Windows.
Local não quer dizer pequeno
O vetor atribuído pelo IPA é AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8 em CVSS v3 e 8.5 em v4. Acesso local e privilégio baixo. Alguém vai olhar esses dois campos e empurrar o item para o fim da fila, e é aí que o raciocínio falha.
Privilégio baixo, num servidor web, é a conta sob a qual o PHP roda. É o que um atacante tem depois de qualquer upload mal validado, qualquer execução remota em CMS, qualquer plugin de WordPress furado. Essa falha é o degrau seguinte, e um degrau curto: tira o atacante da conta limitada e entrega root. Com root num servidor que roda WAF, o atacante passa a controlar o que o WAF registra e o que ele bloqueia. A defesa vira ferramenta do outro lado.
Vale medir o que isso significa em quem opera hospedagem compartilhada ou multi-site. Uma única aplicação comprometida dentro de um servidor com SiteGuard deixa de ser incidente de um cliente e passa a ser incidente da máquina inteira.
Atualizar apaga a prova
Esta é a parte do aviso que merece ser lida duas vezes. O patch substitui os arquivos usados no processamento estatístico. É justamente onde o rastro de uma exploração bem-sucedida estaria. Por isso o fabricante pede, antes de qualquer coisa, que a Informação de Diagnóstico seja exportada pela tela de administração web.
Quem atualizar primeiro e investigar depois vai encontrar um servidor limpo e não vai poder concluir nada disso. E como a execução acontece como root, log local não serve de prova nem na melhor das hipóteses: quem tem root reescreve log. A confirmação precisa vir de fonte externa, como fluxo de rede, registro de firewall de borda, log do balanceador e telemetria de endpoint enviada para fora da máquina.
Exploração confirmada, origem não
O JVN registra, com todas as letras, que a exploração foi confirmada. Nem o aviso do fabricante nem o boletim do JPCERT/CC dizem quem está explorando, contra quem, por qual caminho de acesso inicial ou em quantos servidores. Também não há número público de instalações expostas.
Isso tem uma consequência prática desagradável para quem administra: não existe indicador de comprometimento publicado, nem assinatura, nem endereço de origem para bloquear. A caça tem que ser por comportamento, procurando execução de processo filho inesperado a partir do processo do servidor web, escrita em diretório de sistema e criação de conta ou chave de acesso na janela entre o fim de setembro e hoje.
O recorte brasileiro é pequeno, e a lição não é
Nem o fabricante nem o JPCERT/CC publicaram número de instalações, e a base do SiteGuard está concentrada no Japão. É honesto dizer que a exposição direta no Brasil é pequena, e provável que apareça onde costuma aparecer: subsidiária de grupo japonês com infraestrutura padronizada pela matriz, hospedagem contratada de provedor japonês e ambiente herdado em aquisição.
O que atravessa a fronteira é a classe de risco. WAF hospedado no próprio servidor que protege não é uma particularidade desse produto, é o modelo de qualquer módulo de segurança que roda dentro do Apache, do Nginx ou do IIS, do ModSecurity a plugin de proteção de CMS. Todos herdam privilégio do processo que inspecionam, e todos têm componente acessório, como relatório, estatística e painel, que recebe menos revisão de código do que o motor de regras. Vale olhar o inventário com essa pergunta: quais módulos de segurança rodam dentro dos seus servidores web, quem os atualiza e por qual canal o aviso de vulnerabilidade deles chega.
Quem recebeu o aviso, e quando
A cronologia é o segundo ponto desconfortável. O fabricante notificou clientes com contrato direto de suporte em 29 de setembro. O alerta público, o aviso no JVN e o boletim do JPCERT/CC vieram em 14 de outubro. Cerca de duas semanas separam os dois grupos, e nesse intervalo a falha já era explorada no mundo real.
Para quem compra software de segurança por revenda, integrador ou dentro de um pacote de hospedagem, e isso descreve boa parte do mercado brasileiro de médio porte, a lição é contratual antes de ser técnica. Vale perguntar ao fornecedor por qual canal o aviso de vulnerabilidade chega, em quanto tempo, e se existe alguém do lado dele responsável por repassar. Sem essa resposta, o prazo de resposta a incidente não começa quando o fabricante descobre, começa quando a notícia vence o atraso da cadeia de distribuição.
Outros sinais do dia
- Condição
Só é vulnerável quem está com a função de estatística ligada, e ela vem ligada
A exposição depende da função de processamento estatístico estar habilitada, que é o padrão de instalação. Afeta a 2.20 e versões posteriores em Apache httpd, Nginx e IIS. A linha de IIS entre a 3.10 e a 4.00 Update 4 não é afetada. No FreeBSD, com Apache ou Nginx, o corte é na 7.00 Update 6.
- Vetor
O vetor é local e exige privilégio baixo, o que faz desta a segunda etapa e não a porta de entrada
O vetor registrado pelo IPA é AV:L/AC:L/PR:L, ou seja, acesso local com privilégio baixo. Na prática é o que um atacante já dentro do servidor web usa para sair da conta limitada do processo e virar root. É exatamente o tipo de falha que fecha uma cadeia iniciada em qualquer upload ou RCE de aplicação, e a nota 8.5 em CVSS v4 vem da perda total de confidencialidade, integridade e disponibilidade do sistema.
- Forense
Atualizar apaga a prova, então a coleta vem antes do patch
O aviso do fabricante pede que a Informação de Diagnóstico seja salva pela tela de administração web antes de qualquer atualização. O patch substitui justamente os arquivos usados no processamento estatístico, que é onde o rastro do ataque estaria. Servidor limpo depois da atualização não prova que estava limpo antes.
- Paliativo
Quem não consegue atualizar agora desliga a estatística, nessa ordem
O JPCERT/CC indica desabilitar a função de estatística como contorno. Como desligar também mexe no caminho que guardaria o rastro, a sequência correta é salvar o diagnóstico, desligar a função e só então agendar a atualização. Há patch disponível até para versões fora de suporte, o que remove a desculpa do fim de vida.
- Divulgação
Duas semanas de diferença entre quem paga suporte direto e quem não paga
O fabricante avisou clientes com contrato direto em 29 de setembro. O alerta público, o aviso no JVN e o boletim do JPCERT/CC saíram em 14 de outubro. Quem compra por revenda ou integrador ficou duas semanas atrás na fila, com uma falha que o próprio fabricante já sabia estar sendo explorada.
Fontes e aprofundamento
- JVN iPedia · JVNDB-2026-000148: SiteGuard Server Edition vulnerable to OS command injection, com os vetores CVSS v3 e v4 atribuídos pelo IPA, a classificação CWE-78, a lista de versões afetadas e corrigidas e a coordenação do JPCERT/CC.
- JPCERT/CC · SiteGuard Server Edition の脆弱性に関する注意喚起 (JPCERT-AT-2026-0032), com o contorno de desabilitar a estatística, a confirmação de exploração atribuída ao fabricante e a ordem de salvar o diagnóstico antes de atualizar.
- Security Affairs · Japan's SiteGuard WAF flaw CVE-2026-106931 is already being exploited, com a confirmação de exploração pelo fabricante, a linha do tempo do aviso e a orientação de preservar o diagnóstico antes de atualizar.
- RuntimeWire · EG Secure patches exploited SiteGuard flaw that can grant full server control, com o contorno de desabilitar a estatística indicado pelo JPCERT/CC e o reconhecimento de que o número de instalações expostas é desconhecido.
- INTERNET Watch · EGセキュアソリューションズのホスト型WAF「SiteGuard Server Edition」に脆弱性、最新バージョンに更新を, com o alerta de emergência do fabricante em 14 de outubro, as notas CVSS 3.1 de 7.8 e 4.0 de 8.5 e a cobertura do patch para versão fora de suporte.