GeoServer em alerta por vulnerabilidade de dia zero em jsonArrayContains com risco real de execução remota

O projeto de código aberto GeoServer tem uma vulnerabilidade de dia zero que está sendo ativamente explorada por atacantes, segundo alertas públicos de pesquisadores e assinatura de inteligência watchTowr. A falha, divulgada pelo pesquisador que usa o alias @q1uf3ng em X em 12 de agosto de 2026 às 10:46 UTC, é uma injeção SQL na função ou filtro identificado como jsonArrayContains. O achado ainda não tem atribuído um identificador CVE e por agora não existe um adesivo oficial.

Os fatos confirmados são simples: a vulnerabilidade foi publicada publicamente, watchTowr relatou tentativas de exploração em questão de horas e a vulnerabilidade continua sem corrigir. Em seu seguimento, watchTowr observou “centos de tentativas” provenientes de um pequeno conjunto de endereços IP que buscam sistemas vulneráveis; muitos desses digitalizadores geram erros e não evoluem para exploração completa, segundo a assinatura. O pesquisador que reportou a falha afirmou que, na presença de uma base de dados com privilégios elevados,mencionou explicitamente o caso de uma conta 'sa'—, a injeção SQL poderia terminar em execução remota de código (RCE).

Tecnicamente, o que descreve a evidência disponível é um cenário clássico de injeção SQL, mas aplicado a uma expressão que processa JSON: a função jsonArrayContains aceita dados externos que o servidor incorpora em uma consulta SQL sem a validação ou escape corretos. Isto permite a um atacante introduzir fragmentos de SQL manipulados que mudam a semântica da consulta original. Se a consulta for executada com credenciais que têm privilégios amplos no sistema gestor de base de dados, o atacante pode aproveitar as funcionalidades próprias do SGBD (procedimentos estendidos, comandos de sistema, carga de extensões, BULK operations, etc.) para escalar a execução remota. Essa cadeia –injeção SQL seguida de abuso de privilégios de base de dados para RCE – é plausível e é a explicação técnica mais direta da afirmação do pesquisador, mas convém distinguir o confirmado do estimado.

O que está confirmado: A falha foi publicada e detectores de exploração registraram pesquisas ativos; a vulnerabilidade permite injeção SQL no contexto de jsonArrayContains; não há adesivo disponível no momento desta nota. O que é estimativa ou ainda está por confirmar: que exista exploração EXITOSA que derive em RCE em larga escala em ambientes produtivos, e o percurso exato de exploração para cada combinação de GeoServer + motor de base de dados (MySQL, PostgreSQL, SQL Server, H2 ou outros). A referência explícita à conta 'sa' procede do pesquisador e aponta para cenários com SQL Server, mas não implica que todos os implantaçãos de GeoServer sejam iguais ou que RCE seja automático em todos os casos.

Esta falha preocupa porque a GeoServer é usada em infra-estruturas geoespaciais, catálogos cartográficos e serviços públicos que muitas vezes estão expostos em redes corporativas ou na Internet para o consumo de mapas e dados geoespaciais. Os ambientes mais expostos são instalações com instâncias públicas sem controlo de acesso ou com a base de dados configurada com contas com privilégios excessivos. Além disso, o histórico do projeto mostra que vulnerabilidades prévias em GeoServer foram exploradas em grande escala: em 2024 uma falha crítica (CVE-2024-36401) acabou sendo usada para criar botnets, proxies residenciais e mineiros, segundo registros públicos e bases de dados de vulnerabilidades. Informações oficiais sobre o histórico de vulnerabilidades e catálogos de exploração conhecidos na base NVD e no catálogo de vulnerabilidades exploradas pela CISA: CVE-2024-36401 (NVD) e CISA Known Exploited Vulnerabilities. Para documentação e downloads oficiais do projeto, rever geoserver.org.

Quem afeta? Principalmente administradores e responsáveis pela segurança de organizações que executam o GeoServer e expõem portos ou interfaces web ao exterior. Também devem prestar atenção equipamentos que integram o GeoServer com bases de dados que usam contas administrativas ou com permissões de escrita no sistema de ficheiros, ou que permitem operações remotas de base de dados. As máquinas na nuvem, servidores públicos ou ambientes de testes com acesso aberto são vetores prioritários de risco.

O que fazer agora (medidas concretas e priorizadas): 1) Identificar e limitar exposição: descubra instâncias públicas do GeoServer no seu inventário e na Internet (Shodan, Censys, inventário interno). Se estiverem expostas, restrinja o acesso imediatamente através de regras de firewall, listas de controle de acesso ou eliminação temporária do serviço de pontos públicos. 2) Minimizar privilégios: execute GeoServer com contas de base de dados com as permissões mínimas necessárias; evite contas administrativas como 'sa' ou equivalentes e desactive funções de base de dados desnecessárias que permitam execução de comandos do sistema. 3) Monitorizar e detectar: active a inspeção de registros em GeoServer e do SGBD, procure cadeias de erro SQL invulgares, picos de solicitações para endpoints JSON e padrões de pesquisa repetidos a partir de poucos IP. Configure alertas para tentativas de injeção e tráfego saliente incomum. 4) Mitigações temporárias: use um WAF com regras para bloquear payloads de injeção SQL, coloque o GeoServer por trás de um 'proxy' inverso ou o WAF, e considere desactivar ou restringir a funcionalidade do JSON que administra o jsonArrayContains se a configuração o permitir. Se não puder mitigar, considere deixar a instância fora de serviço até que exista um adesivo. 5) Preparação para o sistema transdérmico: Fique atento a avisos oficiais do projeto GeoServer e ao seguimento de segurança; aplique o adesivo oficial enquanto estiver disponível e tente restauração de backups.

Indicadores de compromisso e detecção úteis: múltiplos pedidos aos mesmos endpoints com parâmetros JSON incomuns, respostas com erros SQL, tentativas repetidas de um conjunto reduzido de IPs, e atividade posterior de lateralização ou picos em tráfego saliente para endereços desconhecidos. Integre esses sinais em seu SIEM e regras de correlação.

Por fim, lembre-se que a situação pode evoluir rapidamente: a exploração em grande escala nem sempre ocorre imediatamente após uma divulgação, mas a combinação de uma vulnerabilidade sem adesivo, uma função que processa entrada externa e um histórico de abuso neste projeto aumenta a probabilidade de campanhas mais agressivas. Mantenha controlos de acesso rigorosos, reduza privilégios e monitorize até que exista uma correção oficial. Para acompanhar as divulgações e avisos oficiais, consulte periodicamente a documentação do projecto GeoServer ( geoserver.org) e as bases públicas de vulnerabilidades como NVD ( nvd.nist.gov) e catálogo da CISA ( cisa.gov).