Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais pontos a serem destacados:
- A vulnerabilidade CVE-2025-24813 pode permitir que invasores não autenticados executem código remotamente, divulguem informações ou injetem conteúdo em servidores Tomcat – mas somente quando o servlet padrão tiver a gravação habilitada (desativada por padrão) e algumas outras condições não padrão forem atendidas.
- As equipes afetadas devem fazer um levantamento das implantações do Tomcat, verificar se as restrições de segurança estão em uso e atualizar para versões corrigidas o mais rápido possível.
- Ambientes do Tomcat mais antigos ou difíceis de atualizar precisam de um plano claro de redução de riscos, em vez de depender de versões sem patches e no fim do ciclo de vida.
Se você gerencia instâncias do Apache Tomcat em produção, a CVE-2025-24813 é uma daquelas vulnerabilidades que exigem sua atenção imediata. Não porque seja chamativa ou esteja ganhando destaque na mídia, mas porque representa um risco real e explorável em configurações que são surpreendentemente comuns.
Este não é um caso teórico isolado que afeta apenas quem está executando o Tomcat em um Raspberry Pi no modo de depuração. Estamos falando de uma vulnerabilidade que pode afetar ambientes reais de produção, potencialmente dando aos invasores um ponto de entrada na infraestrutura da sua aplicação. Vamos explicar o que realmente é o CVE-2025-24813, quem precisa se preocupar com ele e como lidar com a situação sem transformar sua semana em uma crise.
O que é o CVE-2025-24813?
A CVE-2025-24813 é uma vulnerabilidade de equivalência de caminho no Apache Tomcat que pode levar à execução remota de código sem autenticação, à divulgação de informações ou à injeção de conteúdo em arquivos enviados. Na prática, um invasor capaz de acessar uma instância vulnerável do Tomcat pode conseguir enviar um arquivo malicioso e induzir o Tomcat a executá-lo – sem a necessidade de credenciais.
A vulnerabilidade decorre da forma como o tratamento parcial de PUT do Tomcat constrói caminhos de arquivos temporários. A implementação original gerava um nome de arquivo temporário com base no nome e no caminho fornecidos pelo usuário, com o separador de caminho substituído por um ponto. Combinado com a persistência de sessão baseada em arquivos do Tomcat, esse design permite que um invasor envie uma carga serializada em Java especialmente criada para o diretório de sessão e, em seguida, acione a desserialização com uma solicitação GET subsequente contendo um JSESSIONID . O resultado é a execução remota de código.
O que torna isso particularmente preocupante é que não é necessária nenhuma autenticação, e a carga útil pode ser codificada em Base64 para contornar regras comuns de detecção. Uma vez que o invasor compreenda a colisão de caminhos de arquivo e o gatilho de desserialização, a exploração se torna um processo mecânico.
Dito isso, a vulnerabilidade tem pré-requisitos concretos. Para que ela seja explorada, é necessário que todas as condições a seguir sejam atendidas: as gravações estejam habilitadas no servlet padrão (desativadas por padrão – o parâmetro em conf/web.xml deve ser alterado de false), o Tomcat esteja configurado para usar persistência de sessão baseada em arquivo (não a configuração padrão) e o classpath do aplicativo inclua uma cadeia de componentes de desserialização que o invasor possa explorar. A Apache classificou inicialmente o CVE como “Importante” em vez de “Crítico” exatamente por esse motivo. Mas, quando os pré-requisitos se alinham, o impacto é o comprometimento total do servidor – e a CISA o adicionou ao catálogo de Vulnerabilidades Exploradas Conhecidas poucas semanas após a divulgação. –
Quais versões do Tomcat são afetadas?
A vulnerabilidade CVE-2025-24813 afeta várias ramificações do Apache Tomcat, embora os intervalos exatos das versões vulneráveis dependam da versão principal que você estiver executando. Veja a seguir os detalhes:
- O Apache Tomcat 11.0.x apresenta vulnerabilidade nas versões 11.0.0-M1 a 11.0.2. A correção foi implementada na versão 11.0.3; portanto, você precisa estar na versão 11.0.3 ou posterior para receber a correção.
- O Apache Tomcat 10.1.x apresenta uma vulnerabilidade nas versões 10.1.0-M1 a 10.1.34. A correção está incluída na versão 10.1.35 e versões posteriores.
- O Apache Tomcat 9.0.x apresenta vulnerabilidade nas versões 9.0.0.M1 a 9.0.98. Você precisa da versão 9.0.99 ou posterior para corrigir a vulnerabilidade.
- Apache Tomcat 8.5.x atingiu o fim do ciclo de vida em 31 de março de 2024, antes da divulgação dessa vulnerabilidade (CVE). O projeto Apache Tomcat não lançou um patch da comunidade para a versão 8.5; portanto, qualquer implantação da versão 8.5.x fica permanentemente exposta, a menos que você migre para um ramo com suporte ou obtenha cobertura por meio de um provedor comercial de suporte estendido.
Vale destacar que o Tomcat 8.5 e todas as versões anteriores — os ramos 8.0.x e 7.0.x — já chegaram ao fim do ciclo de vida e não receberão um patch da comunidade para a vulnerabilidade CVE-2025-24813. Se você estiver em qualquer um desses ramos, suas únicas opções são migrar para uma versão com suporte ou obter cobertura por meio de um provedor comercial de suporte estendido. Falaremos sobre ambas as opções daqui a pouco.
O importante é entender que isso não afeta apenas versões de ponta ou configurações pouco conhecidas. A vulnerabilidade abrange as principais versões do Tomcat que estão ativamente em uso em ambiente de produção neste momento, incluindo as versões 9.0 e 8.5, já bem estabelecidas, que sustentam inúmeras aplicações corporativas.
Compreendendo o Cenário de Exploração
Para compreender de fato o risco, é preciso entender quando e como essa vulnerabilidade realmente tem importância em ambientes de produção.
O cenário de exploração da vulnerabilidade CVE-2025-24813 gira em torno do servlet padrão do Tomcat — o componente que lida com solicitações diretas de arquivos — e de um recurso chamado PUT parcial, que permite que os clientes enviem partes de um arquivo por meio de várias solicitações. Por padrão, o servlet padrão é somente de leitura e ignora totalmente as solicitações PUT, razão pela qual a maioria das instalações não fica exposta. A vulnerabilidade só se torna acessível quando um administrador define explicitamente o readonly como false no arquivo conf/web.xml, ativando assim os envios de arquivos por meio do servlet padrão.
É aqui que a coisa fica interessante: mesmo com as gravações habilitadas, a exploração requer elementos adicionais. O Tomcat precisa estar configurado para a persistência de sessão baseada em arquivo (o gerenciador FileStore em vez de sessões na memória), o classpath do aplicativo precisa incluir uma cadeia de componentes de desserialização e o invasor precisa ser capaz de acessar o endpoint de upload pela rede.
Quando essas condições se alinham, a cadeia de ataque é curta. O invasor envia uma solicitação PUT parcial que faz o upload de uma carga útil Java serializada para um caminho sob seu controle. Como a implementação da solicitação PUT parcial do Tomcat converte a URI da solicitação em um nome de arquivo temporário — substituindo os separadores de caminho por pontos —, o arquivo enviado vai parar exatamente onde o Tomcat procurará posteriormente pelos dados da sessão. Uma solicitação GET subsequente com um JSESSIONID faz com que o Tomcat desserialize o arquivo, execute a cadeia de gadgets e conceda ao invasor a execução remota de código. Não é necessária autenticação em nenhuma etapa.
Na prática, isso não significa que “um invasor possa ver um endpoint a mais”. Significa que “um invasor faz o upload de uma carga maliciosa, envia mais uma solicitação e executa código como o processo do Tomcat”.
Se o seu aplicativo não permitir gravações no servlet padrão ou não utilizar persistência de sessão baseada em arquivo, você não está exposto à vulnerabilidade de execução remota de código relacionada a este CVE. Você ainda pode estar exposto às variantes de divulgação de informações ou injeção de conteúdo em condições ligeiramente diferentes; portanto, aplicar a correção continua sendo a decisão correta — mas a urgência depende inteiramente da sua configuração.
Avaliando sua exposição
Antes de começar a aplicar as correções, vale a pena dedicar um momento para verificar se suas implantações específicas do Tomcat estão realmente em risco devido à vulnerabilidade CVE-2025-24813.
- Primeiro, verifique as versões do Tomcat. Isso pode parecer óbvio, mas em ambientes complexos com várias instâncias do Tomcat, você ficaria surpreso com a frequência com que as equipes não possuem um inventário completo. Se você estiver executando qualquer versão mais antiga do que as versões corrigidas listadas anteriormente, você está potencialmente vulnerável. Não se esqueça das instâncias do Tomcat em execução em contêineres Docker, ocultas em implantações de microsserviços ou incorporadas a outros aplicativos.
- Second, review your security constraint configurations. Look at the ‘web.xml’ files (and any programmatic security configurations) for your deployed applications. Are you using ‘<security-constraint>’ elements to protect resources? Are you relying on Tomcat’s built-in authentication mechanisms? If the answer is yes, you need to treat this vulnerability seriously.
- Em terceiro lugar, considere sua arquitetura de implantação. Suas instâncias do Tomcat estão expostas diretamente à internet ou estão protegidas por proxies reversos, gateways de API ou outras camadas de segurança? Embora a defesa em profundidade seja sempre recomendável, não presuma que um WAF ou proxy reverso o proteja automaticamente contra essa vulnerabilidade. A manipulação de solicitações necessária para explorar a vulnerabilidade CVE-2025-24813 pode passar por essas camadas sem problemas.
- Por fim, pense no que você está protegendo. Mesmo que você esteja tecnicamente vulnerável, o risco real depende do que um invasor poderia acessar ao contornar suas restrições de segurança. Se estivermos falando de uma interface de administração com acesso a dados de clientes ou controles do sistema, o risco é alto. Se for um endpoint de monitoramento interno que mostra apenas métricas filtradas, a urgência é diferente.
O objetivo aqui não é minimizar a vulnerabilidade nem convencê-lo a não aplicar as correções. Trata-se de compreender seu perfil de risco para que você possa priorizar adequadamente as medidas de correção, especialmente se estiver gerenciando dezenas ou centenas de instâncias do Tomcat.
Etapas de mitigação e aplicação de correções
A solução principal e recomendada para a vulnerabilidade CVE-2025-24813 é simples: atualizar para uma versão corrigida do Apache Tomcat. Mas, como sabe qualquer pessoa que já tenha gerenciado implantações do Tomcat em ambiente de produção, “basta atualizar” é mais fácil dizer do que fazer.
O caminho para uma atualização limpa
Se for possível fazer a atualização sem problemas, veja como fica:
- Identifique a versão atual do Tomcat em todas as implantações. Use o comando `catalina.sh version` ou verifique o número da versão no diretório de instalação do Tomcat. Não confie em documentações ou manuais de procedimentos que possam estar desatualizados.
- Baixe a versão corrigida adequada no site oficial do Apache Tomcat. Para o Tomcat 11, baixe a versão 11.0.3 ou posterior. Para a versão 10.1, baixe a versão 10.1.35 ou posterior. Para a versão 9.0, baixe a versão 9.0.99 ou posterior. Se você ainda estiver usando o Tomcat 8.5, não há patch da comunidade – consulte “Quando a atualização não é viável imediatamente” abaixo. Sempre faça o download de fontes oficiais, nunca de espelhos aleatórios ou repositórios de terceiros.
- Teste a atualização primeiro em um ambiente que não seja de produção. Isso não é paranóia desnecessária – é uma prática básica de higiene operacional. As atualizações do Tomcat, ocasionalmente, introduzem mudanças de comportamento ou características de desempenho que podem pegá-lo de surpresa. Verifique se suas aplicações continuam funcionando, se as métricas de desempenho parecem razoáveis e se todas as integrações de monitoramento ou registro de logs continuam funcionando.
- Planeje a implantação em produção. Leve em consideração suas janelas de implantação, padrões de tráfego e procedimentos de reversão. Se você estiver executando o Tomcat atrás de um balanceador de carga, poderá atualizar as instâncias uma de cada vez. Se estiver em um ambiente mais restrito, talvez seja necessário definir uma janela de manutenção. Certifique-se de ter um plano de reversão testado para o caso de algo dar errado.
- Aplique a atualização e verifique se você está executando a versão corrigida. Não presuma simplesmente que a atualização funcionou – verifique de fato o número da versão após a implantação.
Medidas de mitigação baseadas em configuração
Embora a atualização seja a solução adequada, pode haver alterações na configuração que reduzam sua exposição no curto prazo. Revise suas restrições de segurança para garantir que sejam o mais específicas e restritivas possível. Padrões de URL excessivamente amplos ou restrições mal definidas podem aumentar sua superfície de ataque.
Considere implementar camadas adicionais de autenticação no nível do proxy reverso ou do gateway de API, caso você tenha esses componentes em sua arquitetura. Mais uma vez, isso não substitui a aplicação de patches, mas contribui para uma defesa em profundidade.
Se você estiver executando instâncias do Tomcat que hospedam várias aplicações web, verifique quais aplicações estão implantadas e se todas elas precisam estar lá. Reduzir o número de aplicações implantadas diminui a superfície de ataque potencial.
Considerações operacionais
Aqui estão alguns pontos práticos a serem observados durante o processo de aplicação de patches:
- Requisitos para reinicialização. A atualização do Tomcat exige uma reinicialização. Isso significa tempo de inatividade para suas aplicações, a menos que você tenha projetado uma arquitetura para implantações sem tempo de inatividade. Planeje-se adequadamente.
- Compatibilidade dos arquivos de configuração. A maioria das atualizações do Tomcat é compatível com versões anteriores dos arquivos de configuração existentes, mas nem sempre. Preste atenção especial a quaisquer personalizações que você tenha feito no arquivo server.xml, web.xmlou outros arquivos de configuração.
- Dependências de versão da JVM. Diferentes versões do Tomcat têm diferentes requisitos de versão do Java. O Tomcat 10.1 requer o Java 11. O Tomcat 11 requer o Java 17 ou posterior. Se você estiver atualizando a partir de uma versão mais antiga do Tomcat, talvez seja necessário atualizar sua JVM também, o que aumenta a complexidade.
- Compatibilidade de bibliotecas e conectores. Se você estiver usando drivers JDBC, conectores JMS ou outras bibliotecas com o Tomcat, verifique se elas são compatíveis com a versão para a qual você está atualizando. Isso é particularmente importante para aplicativos corporativos mais antigos.
- Agentes de monitoramento e APM. Se você estiver executando agentes de monitoramento ou ferramentas de APM que se integram ao Tomcat, verifique se eles continuam funcionando após a atualização. Alguns agentes são sensíveis a mudanças na versão do Tomcat.
Quando a atualização não é viável imediatamente
Sejamos realistas: nem toda organização pode largar tudo e atualizar todas as instâncias do Tomcat assim que um CVE é divulgado. Às vezes, você lida com aplicativos fornecidos por fornecedores que vêm com versões específicas do Tomcat e não oferecem suporte a versões mais recentes. Às vezes, você executa aplicativos legados em ramificações mais antigas do Tomcat, cuja atualização exigiria testes e validações significativos. Às vezes, você simplesmente tem recursos limitados e precisa priorizar as instâncias mais críticas primeiro.
Para equipes que utilizam versões mais antigas do Tomcat e que não podem ser atualizadas imediatamente, existem opções de suporte de segurança estendido para ajudar a preencher essa lacuna. Serviços como o Endless Lifecycle Support (ELS) da TuxCare fornecem patches de segurança contínuos para versões de software em fim de vida útil, incluindo versões mais antigas do Tomcat que não recebem mais atualizações do projeto Apache.
Isso não substitui a aplicação adequada de patches e a atualização para as versões mais recentes. Trata-se de uma opção pragmática de redução de riscos que pode fazer parte de um plano de correção em fases. Se você estiver executando instâncias do Tomcat 8.0 ou 7.0 que não possam ser migradas imediatamente, o suporte estendido pode manter esses sistemas protegidos contra vulnerabilidades conhecidas enquanto você realiza o processo de atualização dentro de um prazo realista.
O segredo é agir de forma deliberada. Se você estiver utilizando o suporte estendido, tenha um plano claro para, eventualmente, migrar para as versões atuais do Tomcat. Não deixe que o suporte estendido se torne uma desculpa para adiar a dívida técnica indefinidamente.
Além desta vulnerabilidade (CVE): Criando implantações resilientes do Tomcat
A CVE-2025-24813 é uma vulnerabilidade, mas faz parte de um padrão mais amplo. Vulnerabilidades no Tomcat são descobertas regularmente, e sempre serão. A questão não é se você precisará aplicar uma correção no Tomcat novamente, mas sim com que rapidez e facilidade você conseguirá fazer isso quando a próxima CVE for divulgada.
Isso significa estabelecer práticas operacionais que facilitem a aplicação rápida de patches: manter inventários claros de todas as implantações do Tomcat, dispor de procedimentos de atualização testados, realizar varreduras regulares de vulnerabilidades e manter ambientes de teste que espelhem o ambiente de produção para testar as atualizações.
Isso também significa fazer escolhas arquitetônicas que reforcem a segurança: executar instâncias do Tomcat por meio de proxies reversos, implementar a segmentação de rede, utilizar orquestração de contêineres que facilite as atualizações contínuas e seguir o princípio do privilégio mínimo para as permissões dos processos do Tomcat.
E isso significa manter-se informado. Inscreva-se na lista de discussão sobre segurança do Apache Tomcat. Acompanhe os bancos de dados CVE em busca de vulnerabilidades relacionadas ao Tomcat. Não espere que uma vulnerabilidade se torne de conhecimento público para começar a planejar como reagir.
Entrando em ação
A vulnerabilidade CVE-2025-24813 é grave, mas também pode ser corrigida. Já existem correções, as medidas de mitigação são claras e os requisitos para a exploração são específicos o suficiente para que você possa tomar decisões informadas sobre a priorização.
Se você estiver executando versões do Tomcat afetadas e utilizando restrições de segurança para proteger recursos, considere isso uma tarefa de aplicação de patches de alta prioridade. Teste a atualização, planeje sua implantação e atualize essas instâncias. Se você estiver executando versões mais antigas do Tomcat que não receberão patches, avalie suas opções de suporte estendido ou acelere seus planos de migração.
A pior maneira de lidar com a vulnerabilidade CVE-2025-24813 é ignorá-la e torcer para que ela não tenha importância. A melhor maneira é avaliar sua exposição, priorizar suas medidas de correção e aplicar as atualizações de forma sistemática.
Suas instâncias do Tomcat fazem parte da infraestrutura da sua aplicação. Manter a segurança delas não é uma tarefa opcional que se realiza quando você tem tempo livre. É uma responsabilidade operacional fundamental que merece tempo, atenção e recursos.
