Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT

Falha de path equivalence (CWE-44) no Default Servlet do Apache Tomcat que, combinada com suporte a PUT parcial, permite escrever, ler ou corromper arquivos fora do diretório de upload pretendido. O CVSS 10.0 reflete o cenário mais grave (RCE via deserialização), mas esse cenário depende de uma cadeia de pré-condições não padrão — na maioria das instalações reais o impacto prático é nulo ou limitado a disclosure/corrupção de arquivos, não execução de código.

A falha está no tratamento de nomes de arquivo com ponto interno ('file.Name') pelo Default Servlet do Tomcat quando o suporte a escrita (PUT) está habilitado. Um ponto dentro do nome do recurso faz o resolvedor de caminhos internos do Tomcat tratar dois paths como equivalentes quando não deveriam ser — classificado como CWE-44 (Path Equivalence). Isso permite que um PUT direcionado a um caminho 'público' de upload seja resolvido, na prática, para um caminho diferente e sensível, incluindo áreas usadas internamente pelo servidor, como o diretório de persistência de sessões em disco.

O vetor fica mais perigoso porque o suporte a PUT parcial (upload via cabeçalho Content-Range, para retomar uploads grandes) vem habilitado por padrão sempre que o Default Servlet tem escrita ativada. Isso dá ao atacante controle fino sobre o conteúdo final do arquivo escrito, byte a byte, o que é o que possibilita tanto a injeção de conteúdo malicioso em arquivo legítimo quanto a criação de um payload serializado Java completo dentro de um arquivo de sessão.

O caminho para RCE soma CWE-502 (Deserialization of Untrusted Data): se a aplicação usa persistência de sessão baseada em arquivo do Tomcat (FileStore/PersistentManager) com o local de armazenamento padrão, e tem no classpath alguma biblioteca explorável por gadget chain de deserialização (padrão clássico ysoserial, ex. Commons Collections), o atacante escreve um objeto serializado malicioso como se fosse um arquivo de sessão. Quando o Tomcat carrega essa 'sessão' (por exemplo, numa requisição GET normal que force a leitura do ID de sessão), ele desserializa o conteúdo e executa o gadget chain.

O advisory oficial (Mark Thomas, lista oss-security/dev@tomcat) separa explicitamente as duas classes de impacto e suas pré-condições — isso não é uma falha de RCE trivial e direta, é uma cadeia de configurações que precisa estar simultaneamente presente.

Para o cenário de disclosure/corrupção de arquivos: o Default Servlet precisa ter escrita habilitada (readonly=false — não é o padrão), suporte a PUT parcial (padrão quando escrita está ativa), uma URL de upload 'sensível' que seja subdiretório de uma URL de upload 'pública', e o atacante precisa saber o nome exato dos arquivos sensíveis sendo manipulados. Sem essas condições simultâneas, não há exploração possível — é sem autenticação apenas se o endpoint de PUT já for público, o que por si só já é uma configuração de risco.

Para RCE, soma-se: a aplicação usar persistência de sessão em arquivo com localização padrão de armazenamento, e ter no classpath uma biblioteca vulnerável a deserialização. A PoC pública (absholi7ly/GitHub) demonstra exatamente esse fluxo: envia um PUT parcial contendo um payload serializado (gerado com ysoserial) para um caminho que, por path equivalence, cai no diretório de sessões (ex. via .../uploads/../sessions/), depois força uma requisição (ex. GET a um recurso que carregue aquela sessão) para acionar a deserialização. O próprio autor da PoC chama o cenário de 'teórico' porque depende dessa combinação de fatores — não é um clique único contra qualquer Tomcat exposto.

A CVE está no catálogo KEV da CISA (adicionada em 2025-04-01, prazo 2025-04-22), confirmando exploração ativa observada, e existem módulo Metasploit e template Nuclei públicos, o que reduz drasticamente a barreira técnica para quem já tem um alvo com a configuração vulnerável. O EPSS de ~0.999 indica volume alto de tentativas de exploração/varredura na internet — mas isso mede tentativas, não necessariamente sucesso, dado que a maioria dos Tomcats expostos não tem escrita habilitada no Default Servlet por padrão.

A correção do fornecedor é atualizar para Apache Tomcat 11.0.3, 10.1.35 ou 9.0.98 (conforme publicado pela Apache), que corrigem o tratamento de path equivalence e a interação com PUT parcial. As versões EOL da série 8.5.x (8.5.0 até 8.5.100, confirmadamente afetadas) não recebem patch oficial nesse branch — quem ainda roda 8.5.x precisa migrar para uma versão suportada; distribuições com suporte estendido, como o backport feito pela Debian LTS para tomcat9 (9.0.43-2~deb11u12 no Debian 11), publicam correções próprias fora do calendário da Apache.

Se a atualização não for possível de imediato, o controle compensatório real é garantir que o Default Servlet tenha escrita desabilitada (readonly=true, que já é o padrão de fábrica) — isso por si só elimina toda a cadeia de exploração, já que sem PUT habilitado não há superfície de ataque. Onde a escrita for necessária por design da aplicação, evitar que o path de upload sensível seja subdiretório do path de upload público, e evitar persistência de sessão baseada em arquivo com o storage location padrão reduzem a exposição, mas são paliativos parciais — não fecham completamente a falha de path equivalence subjacente, apenas quebram elos específicos da cadeia até RCE.

O que não funciona como mitigação: assumir que 'meu Tomcat está seguro porque não uso upload de arquivos' sem verificar explicitamente a configuração readonly do Default Servlet em web.xml — muitas aplicações legadas habilitam escrita para funcionalidades específicas e esquecem o detalhe. WAF genérico tem eficácia limitada aqui porque o payload de exploração é um PUT com Content-Range legítimo do ponto de vista de protocolo HTTP; regras precisam ser específicas para o padrão de path equivalence com ponto interno.