GeoServer is vulnerable to an Unauthenticated XML External Entities (XXE) attack via WMS GetMap feature

GeoServer, servidor geoespacial open source amplamente usado por governos e empresas de infraestrutura, tem uma falha XXE não autenticada na operação GetMap do serviço WMS. Qualquer requisição que carregue XML (SLD) processado sem restrição de entidades externas permite ler arquivos do servidor, forçar requisições contra a rede interna (SSRF) ou esgotar recursos — sem login, sem interação do usuário, só rede. Está no catálogo KEV da CISA com exploração confirmada e já existe módulo Metasploit e template Nuclei públicos, o que baixa a barreira de exploração para praticamente qualquer scanner automatizado.

A causa é CWE-611 (Improper Restriction of XML External Entity Reference). A operação GetMap do WMS aceita um corpo XML (usado para definir estilo via SLD — Styled Layer Descriptor) que é processado pelo parser XML do GeoServer sem desabilitar resolução de DOCTYPE/ENTITY externas. Isso é o erro clássico de configuração de parser XML em Java: se o parser não desativa explicitamente `disallow-doctype-decl`, `external-general-entities` e `external-parameter-entities`, qualquer DOCTYPE declarado no documento de entrada é resolvido, incluindo entidades que apontam para arquivos locais (`file://`) ou URLs remotas.

O atacante controla integralmente o conteúdo do documento XML enviado ao endpoint `/geoserver/wms` na requisição GetMap. Isso dá controle total sobre a declaração de entidade externa: pode apontar para arquivos de configuração sensíveis do sistema, para serviços internos da rede (SSRF) ou para payloads que geram consumo excessivo de memória/CPU (variantes de expansão recursiva de entidade, tipo billion laughs).

O advisory do fornecedor classifica CWE-611 e nota que a falha foi originalmente detectada por uma ferramenta automatizada de descoberta de vulnerabilidades (XBOW) e validada por pesquisador humano antes da divulgação — não é uma falha descoberta manualmente por auditoria tradicional, o que ajuda a explicar por que passou tempo sem ser pega: é um padrão de configuração de parser, não um bug de lógica exótico.

O vetor é uma requisição HTTP (GET ou POST) contra `/geoserver/wms` com operação GetMap, carregando um corpo/parametro XML malformado contendo DOCTYPE com entidade externa. Não há pré-requisito de autenticação, de configuração não padrão, nem de interação do usuário — qualquer instância GeoServer exposta na rede com o endpoint WMS acessível é alvo potencial. O único requisito real é a instância estar em versão vulnerável e alcançável pelo atacante.

Com a entidade resolvida, o atacante consegue: (1) exfiltrar conteúdo de arquivos arbitrários do sistema de arquivos do servidor, incluído no XML de resposta ou em erro de parsing; (2) usar o GeoServer como proxy para SSRF contra sistemas internos que só seriam acessíveis a partir da rede onde o servidor roda; (3) causar negação de serviço por exaustão de recursos ao forçar expansão massiva de entidades. O impacto de confidencialidade é alto (C:H no CVSS), integridade não é afetada diretamente, e disponibilidade é impacto baixo/moderado (A:L).

A presença no catálogo KEV da CISA confirma exploração ativa observada; o campo 'usado em ransomware' está marcado como desconhecido pela CISA, ou seja, não há confirmação de uso em campanhas de ransomware, mas a exploração como ferramenta de reconhecimento/exfiltração é dada como fato. A existência de módulo Metasploit, template Nuclei e PoC pública torna a exploração trivial de automatizar em varredura massiva — não exige desenvolvimento de exploit, só apontar a ferramenta para instâncias expostas.

O fornecedor recomenda atualizar para GeoServer 2.25.6, 2.26.3 ou 2.27.0. Há uma divergência entre fontes: o advisory GHSA lista '2.26.2' como versão corrigida na tabela de pacotes afetados, enquanto a descrição oficial da CVE e o texto de resolução do próprio advisory citam 2.26.3 como o release correto da branch 2.26.x. Na dúvida, trate 2.26.2 como potencialmente insuficiente e mova para 2.26.3 ou para 2.27.0 diretamente.

Se a atualização imediata não for viável, o controle compensatório é restringir o acesso de rede ao endpoint `/geoserver/wms` — via firewall, proxy reverso ou ACL — a apenas clientes confiáveis, já que a falha não exige autenticação e é inteiramente explorável via rede. Um WAF ou proxy que inspecione e rejeite corpos de requisição contendo `<!DOCTYPE` e `<!ENTITY` reduz a superfície, mas é mitigação parcial e sujeita a bypass por ofuscação de encoding; não substitui o patch. Não há informação apurada sobre uma flag de configuração oficial do GeoServer para desabilitar resolução de entidades externas sem aplicar o patch — não invente essa opção, ela não está documentada nas fontes disponíveis. Restringir a rede não corrige a causa raiz no parser; é redução de superfície, não remediação.

Procure nos logs de acesso ao GeoServer por requisições GET ou POST para `/geoserver/wms` com operação GetMap cujo corpo ou parâmetros contenham as strings `<!DOCTYPE`, `<!ENTITY` e referências a `SYSTEM` apontando para `file://` ou URLs externas — isso é o padrão de payload XXE clássico e não tem uso legítimo nesse contexto. Dado que existem template Nuclei e módulo Metasploit públicos, espere também tentativas automatizadas de varredura em massa contra instâncias expostas na internet, muitas vezes como parte de scans oportunistas mais amplos, não necessariamente direcionados. Não há sinal de exploração 'silenciosa' documentado nas fontes — a técnica deixa rastro textual reconhecível na requisição, mas não há indicador único e confiável de que uma exploração tenha sido bem-sucedida além de correlacionar com exfiltração de arquivo ou tráfego de saída anômalo do servidor GeoServer para destinos inesperados (indício de SSRF).