A Fundação Apache Software é clara: não há workaround . A única mitigação confiável é atualizar. Aplique os passos abaixo em ordem de prioridade, começando pelos ambientes que usam JNDIRealm com GSSAPI. Atualize o Tomcat para 11.0.23, 10.1.56 ou 9.0.119 (ou superior), conforme a ramificação em uso. Audite o uso de JNDIRealm : identifique todo servidor que faz bind autenticado via GSSAPI e trate essas instâncias como prioridade máxima. Revise o web.xml após a atualização: confirme que as restrições de método ( PUT , DELETE ) agora funcionam como esperado sobre o servlet padrão. Verifique os logs de acesso desde 29 de junho em busca de tentativas de autenticação anômalas ou requisições com métodos não autorizados alcançando recursos protegidos. Mapeie versões 8.x e sem suporte e planeje a migração — essas instâncias não receberão correção. Para confirmar a versão em execução, use ./version.sh no diretório binário do Tomcat ou inspecione o cabeçalho Server nas respostas HTTP. Ambientes containerizados precisam de atenção extra: imagens base Debian ou Ubuntu frequentemente empacotam versões defasadas, então reconstrua a imagem a partir de uma base atualizada.

Apache Tomcat: falha crítica permite login sem senha

Q: Como o login é burlado?

A falha mais séria, CVE-2026-55957 (classificada como Important ), ataca o componente JNDIRealm quando ele é configurado com bind autenticado via GSSAPI — o cenário clássico de integração com Active Directory ou LDAP usando Kerberos. Em português direto: quando o administrador liga o Tomcat ao diretório corporativo para validar usuários por tickets Kerberos, o mecanismo de verificação de senha deixou de conferir corretamente a credencial. O texto do próprio aviso da Apache é incisivo: "um invasor era capaz de se autenticar sem fornecer a senha correta" . A consequência prática é que qualquer pessoa que conseguisse forjar um contexto GSSAPI válido — ou manipular o fluxo de bind — entrava na aplicação protegida como se fosse um usuário legítimo. Em ambientes onde o LDAP/AD é a base do controle de acesso corporativo, isso equivale a deixar a porta de entrada destrancada. A falha foi reportada pelo pesquisador Ilan Toyter e corrigida no commit fd96ab41 .

A Fundação Apache Software divulgou em 29 de junho de 2026 duas vulnerabilidades no Apache Tomcat que permitem burlar autenticação e ignorar restrições de acesso em aplicações Java. A mais grave, CVE-2026-55957, deixa um invasor entrar no servidor sem a senha correta quando o Tomcat usa JNDIRealm com GSSAPI. A segunda, CVE-2026-55956, faz o contêiner ignorar bloqueios de métodos HTTP configurados pelos administradores.

Duas falhas no Tomcat

Pontos-chave: duas falhas (CVE-2026-55957 e CVE-2026-55956) afetam Apache Tomcat 9, 10.1 e 11. O impacto direto é autenticação burlada via JNDIRealm/GSSAPI e restrições de método HTTP ignoradas no servlet padrão. As vítimas típicas são bancos, órgãos públicos e fintechs brasileiras que rodam Java corporativo. A correção exige atualizar para Tomcat 11.0.23, 10.1.56 ou 9.0.119 — sem workaround oficial.

O Apache Tomcat é o contêiner de servlets Java mais usado do mundo e sustenta boa parte das aplicações web corporativas no Brasil — de portais bancários a sistemas de governo. No fim de junho de 2026, a Fundação Apache Software tornou públicas duas vulnerabilidades que afetam simultaneamente as três principais ramificações suportadas: 9.0.x, 10.1.x e 11.0.x. Ambas escaparam da lógica de segurança do contêiner por caminhos distintos, e nenhuma delas tem correção alternativa além da atualização.

A primeira falha foi reportada à equipe de segurança em 14 de junho de 2026 e tornada pública no dia 29 do mesmo mês, conforme o aviso oficial da Fundação Apache Software. A segunda chegou um dia depois, em 15 de junho, e também saiu em 29 de junho. Os prazos curtos entre divulgação e cobertura da imprensa especializada significam que scanners de oportunismo já devem estar varrendo a internet em busca de instâncias desatualizadas.

A falha mais séria, CVE-2026-55957 (classificada como Important), ataca o componente JNDIRealm quando ele é configurado com bind autenticado via GSSAPI — o cenário clássico de integração com Active Directory ou LDAP usando Kerberos. Em português direto: quando o administrador liga o Tomcat ao diretório corporativo para validar usuários por tickets Kerberos, o mecanismo de verificação de senha deixou de conferir corretamente a credencial.

O texto do próprio aviso da Apache é incisivo: “um invasor era capaz de se autenticar sem fornecer a senha correta”. A consequência prática é que qualquer pessoa que conseguisse forjar um contexto GSSAPI válido — ou manipular o fluxo de bind — entrava na aplicação protegida como se fosse um usuário legítimo. Em ambientes onde o LDAP/AD é a base do controle de acesso corporativo, isso equivale a deixar a porta de entrada destrancada. A falha foi reportada pelo pesquisador Ilan Toyter e corrigida no commit fd96ab41.

Restrições de método ignoradas

A segunda vulnerabilidade, CVE-2026-55956 (classificada como Moderate), atinge um hábito tão comum quanto perigoso: administradores que confiam em restrições de método HTTP como controle compensatório. No arquivo web.xml, é prática usual declarar <security-constraint> limitando quais verbos — GET, PUT, DELETE — podem alcançar determinado recurso. A expectativa é bloquear gravação ou remoção de conteúdo estático servido pelo servlet padrão.

O problema é que o Tomcat ignorava silenciosamente a configuração de método (ou de omissão de método) sempre que a restrição era aplicada ao servlet padrão. Em vez de bloquear o PUT ou o DELETE, o servidor deixava a requisição passar como se nenhuma regra existisse. Segundo o relato da Cyber Security News, o defeito persistiu por vários ciclos de versão antes de ser detectado. O pesquisador j0hndo é creditado pela descoberta, corrigida no commit 3f6bd2ba e lançada no Tomcat 11.0.23 em 22 de junho de 2026.

Quais versões estão afetadas

O alcance das duas falhas se sobrepõe, mas não é idêntico. A tabela abaixo resume as faixas vulneráveis e a versão que resolve cada CVE em cada ramificação suportada. Como a recomendação prática é subir para uma única versão que corrija ambos os problemas, os valores da última coluna são os que devem guiar a atualização.

Ramificação	CVE-2026-55957 (afeta)	CVE-2026-55956 (afeta)	Versão que corrige as duas
Tomcat 11.0.x	11.0.0-M1 a 11.0.4	11.0.0-M1 a 11.0.22	11.0.23 ou superior
Tomcat 10.1.x	10.1.0-M1 a 10.1.36	10.1.0-M1 a 10.1.55	10.1.56 ou superior
Tomcat 9.0.x	9.0.0.M1 a 9.0.100	9.0.0.M1 a 9.0.118	9.0.119 ou superior

Ramificações antigas e sem suporte (como 8.5.x e anteriores) provavelmente também são vulneráveis, mas a Apache não emite correções para elas. Quem ainda roda Tomcat 8 está, na prática, sem correção oficial e deve planejar a migração imediata para uma ramificação suportada.

Por que importa para o Brasil

O Apache Tomcat é onipresente na stack Java corporativa brasileira. Bancos digitais, corretoras, órgãos do setor público e plataformas de e-commerce rodam dezenas de milhares de instâncias do contêiner — muitas delas com integração LDAP/Active Directory exatamente no padrão que a CVE-2026-55957 compromete. Qualquer ambiente que valide usuários por GSSAPI contra o Active Directory da empresa está, por definição, na zona de risco até atualizar.

O cenário se agrava pela cultura de manutenção defasada: não é raro encontrar instâncias de produção em versões 9.0.x antigas, mantidas “porque funciona”, sem rotina de patch. Para um atacante, isso transforma a falha de autenticação em um caminho direto para aplicações que processam dados financeiros, dados pessoais (LGPD) e credenciais internas. A janela entre a divulgação pública (29 de junho) e a aplicação do patch é exatamente onde o risco é maior — e já se esgotou há dias.

O que fazer agora

A Fundação Apache Software é clara: não há workaround. A única mitigação confiável é atualizar. Aplique os passos abaixo em ordem de prioridade, começando pelos ambientes que usam JNDIRealm com GSSAPI.

Atualize o Tomcat para 11.0.23, 10.1.56 ou 9.0.119 (ou superior), conforme a ramificação em uso.
Audite o uso de JNDIRealm: identifique todo servidor que faz bind autenticado via GSSAPI e trate essas instâncias como prioridade máxima.
Revise o web.xml após a atualização: confirme que as restrições de método (PUT, DELETE) agora funcionam como esperado sobre o servlet padrão.
Verifique os logs de acesso desde 29 de junho em busca de tentativas de autenticação anômalas ou requisições com métodos não autorizados alcançando recursos protegidos.
Mapeie versões 8.x e sem suporte e planeje a migração — essas instâncias não receberão correção.

Para confirmar a versão em execução, use ./version.sh no diretório binário do Tomcat ou inspecione o cabeçalho Server nas respostas HTTP. Ambientes containerizados precisam de atenção extra: imagens base Debian ou Ubuntu frequentemente empacotam versões defasadas, então reconstrua a imagem a partir de uma base atualizada.

Como verificar a exposição

Antes de considerar o incidente encerrado, é necessário confirmar que nenhuma instância permanece vulnerável e que os controles voltaram a funcionar. A auditoria pós-patch é tão importante quanto a própria atualização, porque falhas de bypass de autenticação costumam ser exploradas de forma silenciosa — sem log de erro, sem alerta de SIEM.

Teste manualmente uma restrição de método bloqueada: tente um curl -X PUT contra um recurso protegido e confirme que o servidor agora retorna o erro esperado. Para o JNDIRealm, valide o fluxo de login com uma credencial inválida e garanta que o acesso seja negado. Cruze o inventário de versões com o escopo afetado listado na tabela anterior e documente cada instância corrigida. Esse rastro documentado será indispensável caso a equipe de compliance ou a autoridade de proteção de dados questione o tempo de resposta.

Um padrão que se repete

As duas falhas compartilham uma raiz desconfortável: controles de segurança configurados que o servidor simplesmente deixava de aplicar. Não é um bug de parsing nem um estouro de buffer — é a quebra silenciosa de uma premissa operacional. O administrador declara uma regra, o Tomcat aceita a configuração sem reclamar, e no momento decisivo a regra não vale. Esse tipo de defeito é particularmente perigoso porque não gera alerta: a configuração parece correta, os testes superficiais passam e a falha só aparece sob um ataque ativo.

O episódio reforça uma lição recorrente na segurança de aplicações Java: atualizar a aplicação não basta se o contêiner subjacente fica parado. O Tomcat precisa entrar na rotina de patch com a mesma prioridade do sistema operacional e das bibliotecas. E, sempre que possível, restrições de método no web.xml devem ser complementadas por controles de camada superior — WAF, autorização na aplicação e validação no repositório — para que uma falha isolada não vire uma porta aberta.