O que são as vulnerabilidades do Apache Tomcat: detecção, correções e dicas

Principais conclusões

• A maior parte dos riscos do Tomcat provém de vulnerabilidades (CVEs) conhecidas e sem correção em versões antigas ou que chegaram ao fim da vida útil.
• Vulnerabilidades de alto impacto, como a CVE-2025-24813 e a Ghostcat, exigem configurações específicas de alto risco para serem acionadas.
• A detecção começa com o conhecimento de todas as versões do Tomcat que você executa e quais configurações de risco estão ativadas.
• Atualize sempre que possível, aplique medidas de mitigação na configuração quando não for possível e nunca deixe versões em fim de vida expostas.

Uma equipe habilita o acesso de gravação no servlet padrão do Tomcat para oferecer suporte a um recurso de envio de arquivos, lança a versão e segue em frente. O que eles não percebem é que o PUT parcial está ativado por padrão, de modo que uma das pré-condições por trás da vulnerabilidade CVE-2025-24813 já está presente. Se essa aplicação também utilizar a persistência de sessão baseada em arquivos do Tomcat no local de armazenamento padrão e, por acaso, incluir uma biblioteca que possa ser explorada para deserialização, o resultado será a execução remota de código sem autenticação. A CISA mantém essa vulnerabilidade no catálogo de Vulnerabilidades Exploradas Conhecidas desde 1º de abril de 2025.

Esse é o padrão recorrente por trás dos incidentes envolvendo o Tomcat. Raramente se trata de um novo ataque engenhoso. Geralmente, é um problema conhecido que ficou sem correção em uma versão antiga, ou uma configuração arriscada que ninguém voltou a revisar.

Este guia apresenta os riscos, os CVEs que vale a pena conhecer e como detectar, aplicar correções e fortalecer seus servidores.

Quais são os riscos das vulnerabilidades do Apache Tomcat?

O Tomcat é um dos contêineres de servlets Java mais amplamente implantados, o que o torna um alvo constante. Quando surge uma vulnerabilidade, o impacto raramente se limita a apenas um servidor.

O pior cenário é a execução remota de código, em que um invasor executa comandos arbitrários no host. Um nível abaixo disso está a divulgação de informações, em que arquivos como o web.xml, código-fonte ou segredos de configuração são lidos sem autenticação. Em seguida, há a injeção de conteúdo, em que dados maliciosos são inseridos em arquivos enviados ou em dados de sessão. E qualquer instância comprometida do Tomcat serve como um ponto de apoio conveniente para o movimento lateral pelo restante da rede.

Análise da realidade: a ideia de que “já fizemos a atualização, então estamos bem” não se sustenta se algumas instâncias estiverem rodando uma versão cujo ciclo de vida já chegou ao fim. O Tomcat 8.5 atingiu o fim do ciclo de vida (EOL) no código-fonte em 31 de março de 2024 e nunca recebeu uma correção do código-fonte para a vulnerabilidade CVE-2025-24813. Sem um fornecedor que ofereça patches após o EOL, esses servidores permanecem vulneráveis, independentemente de quantos outros servidores você tenha atualizado.

Vulnerabilidades comuns do Apache Tomcat

As vulnerabilidades (CVEs) do Tomcat concentram-se em alguns temas específicos. O tratamento inseguro de solicitações, a confiança no protocolo, a resolução de caminhos, a lógica de autenticação e as configurações padrão inseguras de criptografia abrangem a maioria delas. Aqui estão as que vale a pena conhecer, com as versões afetadas e corrigidas publicadas pelo Apache.

CVE-2025-24813 (RCE parcial via PUT)

Este caso combina um bug de equivalência de caminho com uma deserialização insegura, e as pré-condições são específicas, mas totalmente realistas. As gravações precisam estar habilitadas no servlet padrão, o que, por padrão, está desativado. O PUT parcial precisa estar ativado, o que, por padrão, já está.

O aplicativo precisa utilizar a persistência de sessão baseada em arquivo do Tomcat no local de armazenamento padrão. Além disso, o aplicativo precisa incluir uma biblioteca que possa ser explorada em um ataque de desserialização. Se todos esses quatro fatores estiverem presentes, um invasor poderá preparar uma carga serializada por meio de uma chamada PUT parcial e, em seguida, acionar a execução com uma solicitação subsequente contendo o JSESSIONID correspondente.

A informação foi divulgada em 10 de março de 2025, e a CISA a incluiu no catálogo de Vulnerabilidades Exploradas Conhecidas em 1º de abril de 2025.

CVE-2020-1938 (Ghostcat)

O Ghostcat é uma vulnerabilidade de leitura e inclusão de arquivos no conector AJP, que historicamente era fornecido ativado na porta 8009 e vinculado a todos os endereços configurados. Um invasor remoto e não autenticado que conseguisse acessar essa porta era capaz de recuperar arquivos arbitrários de qualquer local da aplicação web, inclusive nas pastas WEB-INF e META-INF, e fazer com que o Tomcat processasse qualquer arquivo da aplicação como um JSP. A vulnerabilidade se agrava, levando à execução de código, quando a aplicação também armazena arquivos enviados dentro da aplicação web. As correções foram implementadas nas versões 7.0.100, 8.5.51 e 9.0.31, nas quais o Apache também comentou o conector no arquivo server.xml padrão, mudou seu endereço de ligação padrão para loopback e tornou obrigatória a utilização de uma chave secreta AJP. A vulnerabilidade está no catálogo KEV desde 3 de março de 2022.

CVE-2025-55752 (Traversal de diretório)

Uma falha na Rewrite Valve normalizava as URLs reescritas antes de decodificá-las. Nos casos em que as regras de reescrita transferem parâmetros de consulta para a URL, um invasor poderia manipular o URI da solicitação para contornar as proteções em /WEB-INF/ e /META-INF/, com a possibilidade de execução de código caso o método PUT também estivesse habilitado. O Apache observa que essa combinação é improvável, já que o método PUT é normalmente restrito a usuários confiáveis, mas ainda assim vale a pena conhecer o caso. Isso mostra como uma correção em uma versão pode, discretamente, reintroduzir um risco em outra.

CVE-2026-29146 (Padding Oracle no EncryptInterceptor)

Um bom lembrete de que uma configuração padrão pode ser uma vulnerabilidade. O EncryptInterceptor, usado para criptografar o tráfego do cluster, vinha configurado por padrão no modo CBC, que está sujeito a ataques de oráculo de preenchimento. Qualquer implantação que executasse esse interceptador no modo de criptografia padrão estava potencialmente exposta, mesmo que o administrador não tivesse selecionado nenhuma configuração incomum. Para as versões cobertas pelo Suporte de Ciclo de Vida Ilimitado da TuxCare, as correções retroativas são rastreadas por versão no rastreador CVE, que mostra exatamente quais versões cobertas têm a correção disponível.

CVE-2026-34486 (Contornamento do EncryptInterceptor)

A correção para a vulnerabilidade CVE-2026-29146 foi lançada nas versões 9.0.116, 10.1.53 e 11.0.20, mas continha um erro que permitia que o EncryptInterceptor fosse totalmente contornado. Observe o número do Tomcat 11 aqui. A correção foi desenvolvida para a versão 11.0.19, mas a votação para o lançamento foi rejeitada; portanto, a 11.0.20 foi a primeira versão que realmente pôde ser baixada. Exatamente essas três versões são afetadas, e as versões 9.0.117, 10.1.54 e 11.0.21 corrigem a vulnerabilidade. A CISA adicionou essa vulnerabilidade ao catálogo KEV em 4 de agosto de 2026; portanto, uma atualização de cluster que parou na primeira correção não está concluída.

CVE-2026-55957 (Contorno da autenticação do GSSAPI)

Quando o JNDIRealm era configurado para autenticar ligações usando GSSAPI, um invasor poderia se autenticar sem a senha correta. Sem ataque de força bruta, sem credenciais roubadas. A lógica de autenticação simplesmente falhou em aplicar a verificação. O mais estranho é a linha do tempo. A correção foi discretamente lançada nas versões 9.0.102, 10.1.39 e 11.0.5, e a falha só foi divulgada publicamente em 29 de junho de 2026, mais de um ano depois. Qualquer versão igual ou anterior à 9.0.100, 10.1.36 ou 11.0.4 requer atenção. Versões mais recentes já estavam protegidas antes mesmo de o CVE receber um número.

CVE-2026-43512 (Senha “null” na autenticação por Digest)

O modo de falha, neste caso, é quase simples demais para acreditar. O autenticador Digest do Tomcat aceitava a sequência de caracteres “null” como senha válida para qualquer nome de usuário que não existisse no Realm configurado. Assim, um usuário que não estivesse no sistema poderia se autenticar adivinhando essa sequência. O alcance do impacto depende do que estiver por trás da autenticação Digest, mas a pré-condição é trivial de ser atendida. A vulnerabilidade foi divulgada em 12 de maio de 2026 e corrigida nas versões 9.0.118, 10.1.55 e 11.0.22.

Você sabia? Em março de 2025, a Palo Alto Networks bloqueou 125.856 varreduras, sondagens e tentativas de exploração relacionadas ao CVE-2025-24813 e a duas vulnerabilidades relacionadas ao Apache Camel, originadas em mais de 70 países, nas três semanas seguintes à divulgação.

Como detectar e avaliar vulnerabilidades do Apache Tomcat

A detecção é, em grande parte, uma questão de inventário. Não é possível aplicar patches no que não foi identificado, e ambientes maiores costumam acumular instâncias do Tomcat que nunca foram incluídas em nenhuma lista. Siga estas três etapas na ordem indicada.

Fazer um inventário de todas as instâncias e versões

Identifique todas as instalações do Tomcat, incluindo os aplicativos que o incorporam, como os aplicativos Spring Boot que executam o servidor Tomcat incorporado. Anote a versão exata, e não o nome da pasta. As instalações podem ser copiadas e renomeadas, portanto, o caminho pode induzir a erro.

Dica profissional: execute o script de versão incluído no pacote, em vez de tentar adivinhar a partir do caminho de instalação. O comando $CATALINA_HOME/bin/version.sh exibe as versões exatas do Tomcat e da JVM, que são os dados necessários para qualquer avaliação concreta.

Correlacionar versões com CVEs conhecidos

Compare cada versão com o NVD, os alertas de segurança do Tomcat para a sua versão e o catálogo KEV da CISA. Qualquer item presente no KEV deve ser tratado como uma vulnerabilidade ativamente explorada e colocado no início da fila.

Verifique os indicadores de configuração de risco

Várias vulnerabilidades CVE do Tomcat só se tornam perigosas quando determinadas configurações estão ativadas. Verifique se o servlet padrão tem a propriedade `readonly` definida como `false`, se a opção `allowPartialPut` está habilitada, se o conector AJP está acessível e se o `JNDIRealm`, a autenticação Digest ou o `EncryptInterceptor` estão, de fato, em uso. Esse panorama de configuração é o que distingue uma vulnerabilidade CVE que está meramente presente de uma que é genuinamente explorável.

Como corrigir e aplicar patches nas vulnerabilidades do Apache Tomcat

A aplicação de patches no Tomcat costuma ser simples quando existe uma versão corrigida disponível. A parte difícil são os servidores nos quais a atualização está bloqueada ou cuja versão já chegou ao fim do ciclo de vida.

Atualizar para uma versão corrigida

Para ramificações mantidas ativamente, mude para uma versão fixa e considere os números por CVE na tabela acima como o mínimo necessário, e não como o objetivo final. Chegue à versão mais recente em sua ramificação, o que hoje significa 9.0.121, 10.1.59 ou 11.0.25. Parar na correção mínima para um CVE faz com que você continue com todas as correções publicadas desde então. O CVE-2026-29146 é um exemplo que serve de alerta. Suas correções iniciais foram lançadas nas versões 9.0.116, 10.1.53 e 11.0.20, e todas essas três versões acabaram se mostrando vulneráveis à falha de contorno de patch CVE-2026-34486; portanto, o limite mínimo real nesse caso é 9.0.117, 10.1.54 ou 11.0.21.

O CVE Tracker da TuxCare para o Apache Tomcat é útil para verificar quais CVEs afetam uma versão específica mais antiga ou em fim de vida útil (EOL).

Aplique medidas de mitigação de configuração quando ainda não for possível realizar a atualização

Se for necessário adiar a atualização de versão, bloqueie a vulnerabilidade na camada de configuração. Mantenha a opção `readonly` definida como `true` no servlet padrão, o que é a configuração padrão e, por si só, remove a pré-condição do servlet gravável. Se as gravações forem realmente necessárias, defina `allowPartialPut` como `false` sempre que o aplicativo não precisar de uploads parciais. Esse parâmetro já existe há anos, inclusive na versão 8.5.100 e nas compilações mais antigas da 9.0, portanto, é uma opção viável em servidores sem patches. Em seguida, desative o conector AJP se você não o utilizar, ou vincule-o à interface de que seu proxy realmente precisa e atribua uma senha secreta a ele, caso o utilize.

Atenção: O PUT parcial está habilitado por padrão, mas a persistência de sessão baseada em arquivo não está, assim como o servlet padrão não está configurado como gravável. No momento em que alguém configura o servlet padrão como gravável para um recurso de envio de arquivos, uma das pré-condições não padrão é atendida. Adicione a persistência de sessão baseada em arquivo no local de armazenamento padrão e uma biblioteca que possa ser explorada para deserialização, e a cadeia completa do CVE-2025-24813 estará ativa. Trate a opção “habilitar gravações” como uma decisão de segurança, e não como um recurso de conveniência, e verifique as outras duas condições enquanto estiver fazendo isso.

Escolha entre a aplicação manual ou automática de patches e cubra as versões em fim de vida útil (EOL)

A forma como você aplica os patches depende do tamanho da frota, do nível de controle de mudanças que você precisa cumprir e se a versão ainda recebe correções do desenvolvedor original.

O Tomcat é um contêiner de servlets bastante independente, e a maioria dos alertas se refere a seus próprios componentes, como Catalina, Coyote e Jasper. As implantações em produção ainda precisam monitorar o JDK e quaisquer bibliotecas incluídas no aplicativo, já que essas dependências apresentam vulnerabilidades próprias. Em um caso como o CVE-2025-24813, uma biblioteca incluída no pacote é também o que fornece a cadeia de exploits que transforma a desserialização insegura em execução de código.

Quando as correções do desenvolvedor original deixam de chegar à versão que você está executando, é aí que entra o Suporte de Ciclo de Vida Ilimitado da TuxCare para o Apache Tomcat. Ele faz o backport das correções de CVE para versões fixas do Tomcat, fornecidas a partir de um repositório da TuxCare, para que você possa permanecer na versão atual, em vez de fazer um salto de versão que ainda não testou. Atualmente, a cobertura abrange versões selecionadas do Tomcat 7, 8.5, 9.0 e 10.1, a saber: 7.0.109, 8.5.100, 9.0.46, 9.0.50, 9.0.75, 9.0.83, 9.0.87, 9.0.90, 9.0.100, 10.1.18 e 10.1.42, e a documentação apresenta a matriz atual. Esse intervalo é importante porque o problema não se resume apenas ao fim do ciclo de vida da ramificação. O Tomcat 7 e o 8.5 já ultrapassaram esse prazo há muito tempo — o 8.5 desde 31 de março de 2024 — e o fim do suporte ao Tomcat 9.0 foi anunciado para 31 de março de 2027. Mas um aplicativo fixado em uma versão mais antiga do 9.0 ou 10.1 não recebe as correções que a Apache adiciona nas versões posteriores desse mesmo ramo.

Resumindo: se a sua versão do Tomcat ainda recebe patches do desenvolvedor original, faça a atualização em intervalos regulares. Se ela estiver no fim do ciclo de vida ou se a versão fixada já tiver sido ultrapassada pelo desenvolvedor original, opte por patches oferecidos pelo fornecedor ou planeje a migração. Manter o sistema sem patches não é uma opção.

Melhores práticas para proteger o Apache Tomcat

O fortalecimento do Tomcat não tem tanto a ver com controles sofisticados, mas sim com manter intactas as configurações padrão seguras, desativar o que você não usa e reforçar a segurança de tudo o que você expõe. Alguns hábitos consistentes já são suficientes para fechar a maioria das brechas comuns.

Mantenha-se nas versões com suporte

Mantenha tanto o Tomcat quanto o JDK em versões que ainda recebam correções de segurança. Para compilações que o desenvolvedor original deixou de suportar, o Suporte de Ciclo de Vida Ilimitado para o Apache Tomcat garante que os patches continuem sendo fornecidos sem a necessidade de uma migração forçada.

Conectores de bloqueio e o servlet padrão

Aplique o princípio do privilégio mínimo à superfície de exposição do Tomcat. Mantenha o servlet padrão como somente leitura, a menos que haja um motivo concreto para não fazê-lo; desative o PUT parcial caso não o utilize; e nunca deixe o AJP acessível a partir de redes não confiáveis.

Dica de especialista: Se você usar o AJP, vincule o conector à interface de que seu proxy confiável realmente precisa, restrinja o acesso a ele na camada de rede e defina um segredo. O Ghostcat era tão perigoso em grande parte porque essa porta permanecia aberta nas instalações padrão por bem mais de uma década.

Coloque o Tomcat atrás de um proxy reverso e monitore-o

Na maioria das implantações em produção, coloque um proxy reverso fortificado na frente do Tomcat, em vez de expor diretamente o conector da aplicação. Remova as aplicações de exemplo e restrinja rigorosamente o acesso à aplicação de gerenciamento, caso decida mantê-la. Monitore os logs de acesso em busca de solicitações de arquivos incomuns, especialmente aquelas que tentam acessar /WEB-INF/ ou que enviam solicitações PUT inesperadas.

Mantenha seu Apache Tomcat protegido com a TuxCare

As vulnerabilidades do Apache Tomcat raramente se revelam. Elas permanecem ocultas nas configurações padrão e nas versões em fim de vida útil até que alguém faça uma varredura no seu servidor. A solução é simples, mas confiável. Saiba o que você está executando, aplique patches onde houver correção, mitigue os riscos onde não houver e nunca deixe uma versão em fim de vida útil exposta. Se você estiver preso a uma versão que o desenvolvedor original já não oferece suporte, veja como a TuxCare oferece Suporte de Ciclo de Vida Ilimitado para o Apache Tomcat.

Resumo

Nome do artigo

O que são as vulnerabilidades do Apache Tomcat: detecção, correções e dicas

Descrição

Mantenha seus servidores Apache Tomcat protegidos! Aprenda a identificar vulnerabilidades, corrigi-las e seguir as melhores práticas para garantir uma segurança robusta.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora