Fim da vida útil (EOL) do Eclipse Jetty: versões, caminho de atualização e opções

Principais conclusões

• As versões Jetty 8, 9, 10 e 11 estão todas no fim do ciclo de vida. Em 1º de janeiro de 2026, a Webtide e o projeto Jetty deixaram de publicar versões das linhas 9, 10 e 11 no Maven Central; portanto, as correções para novas vulnerabilidades (CVEs) não são mais disponibilizadas por meio de canais públicos.
• Apenas o Jetty 12.0 e o 12.1 ainda contam com suporte da comunidade. O Jetty 12.1 é a versão atual; a Webtide informou que as atualizações do 12.0 serão encerradas em algum momento de 2026, sem ter definido uma data específica até o momento.
• A migração para o Jetty 12 é mais do que apenas uma atualização de versão. Ela requer o JDK 17 e, dependendo do ambiente EE de destino, uma migração de javax para jakarta e, para aplicativos Spring Boot embarcados, uma migração para o Spring Boot 3.2 ou posterior.
• Se você ainda não puder migrar, as opções viáveis são o suporte estendido oferecido pelo fornecedor, backports mantidos internamente ou a substituição do Jetty. O suporte estendido costuma ser a solução de transição que exige menos esforço; a manutenção interna é aquela que as equipes tendem a subestimar.

Você aplicou todas as correções no último trimestre. Então, uma verificação de dependências sinalizou o jetty-server 9.4.x, oculto em três níveis de profundidade em um serviço que ninguém mexe desde 2021, e a versão corrigida de que você precisa não está no Maven Central. Essa é a situação do Eclipse Jetty EOL em 2026: o Jetty 9, 10 e 11 chegaram ao fim da vida útil e, desde 1º de janeiro de 2026, o projeto não publica mais versões dessas linhas publicamente.

Este guia aborda quais versões chegaram ao fim do ciclo de vida, como saber se você está usando uma delas, quais são os riscos reais e qual é a melhor maneira de fazer a transição.

O Eclipse Jetty chegou ao fim de sua vida útil?

Sim, e o cronograma tem mais variáveis do que a maioria das equipes percebeu. O Jetty 10 e o 11 chegaram ao fim do suporte da comunidade em 1º de janeiro de 2024 e foram declarados em fim de vida a partir de janeiro de 2025. O Jetty 9 perdeu o suporte da comunidade em 1º de junho de 2022 e tinha o fim de vida útil previsto para janeiro de 2025, embora versões de segurança patrocinadas por clientes tenham continuado a ser lançadas até a versão 9.4.58.v20250814, lançada em agosto de 2025.

A data que altera sua avaliação de risco é mais recente. Desde 1º de janeiro de 2026, a Webtide e o projeto Jetty não publicam mais as versões 9, 10 ou 11 do Jetty no Maven Central nem em qualquer outro repositório público. Portanto, quando hoje é divulgado um CVE referente a uma versão anterior à 12, muitas vezes já existe uma compilação corrigida. Só que ela não está em nenhum lugar acessível à sua compilação.

O Jetty 12.0 e o 12.1 são as únicas versões com suporte da comunidade, e a versão 12.0 está em fase de notificação.

Observação: O Jetty 9 é a versão que provavelmente está em execução no seu ambiente, mesmo que ninguém tenha decidido instalá-la. Versões do Apache Solr, Spark, ActiveMQ e Hadoop vêm com o Jetty incorporado, e o plug-in do Jetty para o Maven o inclui nas compilações; por isso, ele tende a entrar na compilação como uma dependência empacotada ou transitiva, e não como uma escolha deliberada.

Principais versões e datas do Eclipse Jetty

A correspondência entre versões e status é o que a maioria dos leitores realmente precisa, por isso a apresentamos logo no início, atualizada em julho de 2026 e extraída dos anúncios oficiais e listas de lançamentos do Eclipse Jetty.

Uma observação sobre a segunda coluna: existem números de versão fixos mais altos para as linhas com fim de vida útil (EOL), incluindo 9.4.60 e versões posteriores, 10.0.28 e versões posteriores e 11.0.28 e versões posteriores. Essas compilações não são publicadas no Maven Central, e é por isso que a tabela termina nesse ponto.

Como verificar se você está executando o Eclipse Jetty em fim de vida útil (EOL)

Existem duas situações que exigem verificações diferentes. O Jetty independente é fácil de identificar. Já o Jetty incorporado é onde as equipes costumam ter problemas.

Se você estiver executando o Jetty como um servidor autônomo, pergunte diretamente a ele:

java -jar $JETTY_HOME/start.jar –version

Isso exibe a versão exata da compilação, por exemplo jetty-12.1.11. Você também pode ler o arquivo o arquivo VERSION.txt no diretório raiz do Jetty.

Se o Jetty estiver incorporado a um aplicativo Spring Boot, a uma instância do Solr ou a qualquer JAR compacto, a versão fica oculta na sua árvore de dependências. Para o Maven:

mvn dependency:tree -Dincludes=’org.eclipse.jetty*’

Mantenha o curinga no final. O Jetty 12 publica seus artefatos de ambiente sob IDs de grupo distintos, como org.eclipse.jetty.ee10, e um filtro de correspondência exata de org.eclipse.jetty não os exibirá. Se você preferir não se preocupar com a sintaxe do filtro, use mvn dependency:tree | grep -i jetty captura tudo.

Para o Gradle:

./gradlew dependencies | grep -i jetty

E para identificar os JARs do Jetty armazenados no disco dentro de outros produtos:

find / -name ‘jetty-*.jar’ 2>/dev/null

Aponte isso para a raiz de um aplicativo real, em vez de / se o host tiver montagens grandes ou em rede, e lembre-se de que um JAR dentro de um fat JAR ou de uma camada de contêiner não aparecerá como um arquivo separado.

Se o resultado for 9.x, 10.x ou 11.x, você está executando o Jetty EOL. Se for 12.0.x ou 12.1.x, você está em uma versão com suporte, com a ressalva de que as atualizações da versão 12.0 devem ser encerradas ainda este ano.

O que acontece se você continuar usando o Eclipse Jetty após o fim da vida útil (EOL)

O risco não é teórico e não se resume apenas à versão visível. Ele se divide em três partes: novas vulnerabilidades (CVEs) cujas correções nunca chegam a um repositório público, o longo histórico de bugs de análise de HTTP do Jetty e a exposição em auditorias decorrente da execução de software sem suporte.

Novas vulnerabilidades (CVEs) sem correção disponível ao público

Uma vulnerabilidade divulgada hoje no Jetty 9, 10 ou 11 não recebe nenhuma versão no Maven Central. Esse é o efeito prático da mudança de janeiro de 2026, e é um problema mais estranho do que parece à primeira vista, pois a correção geralmente já existe.

CVE-2026-2332 é o exemplo mais claro. Trata-se de uma falha de contrabando de solicitações HTTP no analisador de codificação de transferência em blocos do Jetty: o Jetty encerra a análise da extensão do bloco em um CRLF dentro de uma string entre aspas, em vez de tratá-la como um erro, o que permite que um invasor dessincronize o Jetty de um proxy front-end. Publicada em 14 de abril de 2026, com CVSS 7,4, e afetou as versões 9.4.0 a 9.4.59, das versões 10.0.0 a 10.0.27, 11.0.0 a 11.0.27, 12.0.0 a 12.0.32 e 12.1.0 a 12.1.6. As correções públicas foram incorporadas nas versões 12.0.33 e 12.1.7. Também existem compilações corrigidas para as linhas em fim de vida (EOL), como 9.4.60, 10.0.28 e 11.0.28, mas elas não estão no Maven Central. Os próprios avisos do Jetty agora confirmam isso, listando os patches para versões em fim de vida como disponíveis por meio de provedores comerciais, incluindo a TuxCare.

Então, isso aconteceu novamente. O CVE-2026-5795, uma falha de contorno de autenticação do JASPI causada pela sobrevivência do estado do ThreadLocal após um retorno antecipado, foi corrigido publicamente nas versões 12.0.34 e 12.1.8, com as versões 9.4.61, 10.0.29 e 11.0.29 disponíveis apenas por meio desses mesmos canais de suporte estendido. Dois alertas de alta gravidade em uma única primavera, ambos corrigidos, mas nenhuma das correções está disponível em uma versão pública se você estiver em uma versão anterior à 12.

Um aplicativo Spring Boot 2.7 que incorpora o Jetty 9.4 ilustra bem essa armadilha. Substituir a versão do Jetty na sua compilação só funciona se houver uma versão pública para substituí-la, e, no caso da 9.4, isso não existe mais. A alternativa é um artefato da versão 12.x, o que significa JDK 17, namespaces do Jakarta e uma atualização significativa do Spring Boot; por isso, o CVE tende a simplesmente permanecer no relatório. A correção existe; o difícil é conseguir uma compilação compatível para instalar em seus servidores, e preencher essa lacuna sem uma atualização forçada é exatamente para isso que servem os patches fornecidos pelos fornecedores.

Histórico de análise de HTTP do Jetty

Um ponto fraco recorrente do Jetty é o tratamento de solicitações HTTP/1.x, e esse padrão é consistente o suficiente para que se possa planejar medidas preventivas. O CVE-2026-2332 é um bug de análise de codificação em blocos, e está longe de ser o primeiro. O CVE-2023-40167 envolveu o Jetty aceitando um + antes do valor de Content-Length , uma peculiaridade de análise que pode permitir o contrabando de solicitações quando um front-end interpreta esse cabeçalho de maneira diferente.

O lote de 2017 apresenta o mesmo problema em três falhas no analisador sintático. CVE-2017-7656 envolveu a aceitação de uma linha de solicitação no estilo HTTP/1 que declarava HTTP/0.9, o que poderia corromper um cache quando um intermediário encaminhasse a versão sem processá-la. CVE-2017-7657 foi um estouro de inteiro na análise do comprimento do chunk, de modo que um chunk grande poderia ser lido como um menor e seu corpo tratado como uma solicitação em pipeline. CVE-2017-7658 envolvia indicadores conflitantes de Content-Length e codificação em blocos. Nos dois últimos casos, a situação prejudicial ocorria quando o Jetty estava atrás de um intermediário que impunha autorização e repassava a solicitação sem alterações: a solicitação contrabandeada chegava ao outro lado dessa verificação.

Dessa história, duas conclusões se impõem. Se o Jetty estiver atrás de um proxy, balanceador de carga ou CDN, trate as vulnerabilidades (CVEs) do analisador como de alta prioridade, e não apenas como questões teóricas, pois é o intermediário que as torna exploráveis. E, caso não seja possível aplicar o patch imediatamente, normalizar ou remover as extensões dos chunks no front-end é uma medida de mitigação provisória eficaz para esse tipo de falha.

Incorporação oculta e exposição à conformidade

O problema da dependência transitiva torna tudo o que foi mencionado acima mais difícil. Como as versões do Solr, Spark, ActiveMQ e Hadoop incluem o Jetty, e o plug-in do Jetty para o Maven o incorpora às compilações, a suposição de que “não usamos o Jetty” costuma estar errada. Em um portfólio de grande porte, é comum encontrar mais de uma versão principal do Jetty em diferentes serviços, cada uma com sua própria exposição e seu próprio responsável.

Há também a questão da auditoria. O PCI DSS estabelece requisitos explícitos para a aplicação de patches e o gerenciamento de vulnerabilidades, o FedRAMP exige cronogramas documentados para varreduras e correções, e, embora o SOC 2 é uma certificação com base nos controles que você definiu, e não uma exigência de aplicação de patches, um auditor ainda assim perguntará como um servidor HTTP sem suporte se encaixa nos controles que você estabeleceu. Um Jetty em fim de vida útil (EOL) não é, por si só, motivo para reprovação em uma auditoria. No entanto, isso exige que você se justifique, e “a correção do desenvolvedor original não está mais disponível” é uma resposta insatisfatória sem um controle compensatório por trás.

Atenção: Uma verificação de dependências com o Green Dependency Scan nos repositórios do seu aplicativo não significa que você esteja livre de problemas. O Jetty em fim de vida (EOL) geralmente fica oculto em produtos de terceiros que você implantou como um único artefato; portanto, o JAR vulnerável pode nunca aparecer como uma dependência direta no seu próprio pom.xml. Faça a verificação dos artefatos implantados e das imagens de contêiner, não apenas dos repositórios que você cria.

Caminho de atualização: Migração para o Eclipse Jetty 12

O processo de migração depende muito do fato de o seu Jetty ser autônomo ou incorporado. Cada etapa abaixo condiciona a seguinte, portanto, a ordem é importante.

•   Primeiro, o JDK 17. Tanto o Jetty 12.0 quanto o 12.1 definem Java 17 como o ambiente de execução mínimo. Se você estiver usando o Java 8 ou Java 11, essa é a etapa determinante e, geralmente, a maior parte do trabalho.
•   Em seguida, escolha seu ambiente EE. O Jetty 12 executa aplicativos dentro de módulos específicos para cada ambiente: a versão 12.0 inclui EE8, EE9 e EE10, e a 12.1 abrange do EE8 ao EE11. O EE10 usa o jakarta.servlet (Servlet 6.0) e o EE11 usa o Servlet 6.1; portanto, o código e as bibliotecas que importam as APIs javax.* do Java EE precisam ser adaptados para esses destinos. O EE8 mantém o namespace javax.*, o que significa que você pode implementar primeiro o núcleo do Jetty 12 e agendar o trabalho relacionado ao namespace separadamente. Vale ressaltar claramente para quem estiver criando scripts para isso: apenas os pacotes do Java EE foram movidos. O javax.crypto, o javax.sql e o restante do Java SE permanecem exatamente onde estão.
•   Compatibilidade de versões do Spring Boot para usuários do Jetty incorporado. Essa é a armadilha. O Jetty 12 incorporado requer o Spring Boot 3.2 ou posterior, pois o Spring Boot 3.0 e 3.1 eram fornecidos com o Jetty 11 e exigiam o downgrade da API Servlet para a versão 5.0 para que o Jetty pudesse ser utilizado. O Spring Boot 3.x, por sua vez, requer o Java 17 e o namespace do Jakarta EE 9; portanto, uma solicitação de “atualização do Jetty” se transforma em uma migração do Spring Boot 2 para o 3, com a versão 3.2 como requisito mínimo.

Considere um aplicativo SaaS no Spring Boot 2.7 com o Jetty 9.4 incorporado. A atualização do Jetty não é uma linha no arquivo pom.xml. Trata-se de um projeto que se estende por vários sprints e envolve o JDK, as importações do Java EE em toda a base de código, a configuração do Spring Security e uma longa lista de bibliotecas que precisam de versões compatíveis com o Jakarta.

A decisão é bem clara. Se você estiver executando o Jetty de forma independente e já estiver usando o Java 17, a migração será mais contida do que no caso de uma instância incorporada; no entanto, reserve tempo para revisar o orçamento, levando em conta a renomeação de artefatos do Maven, o novo layout de módulos e ambientes, sua configuração do jetty-base e seus descritores de implantação. Se o Jetty estiver incorporado a um aplicativo Spring Boot 2.x, planeje primeiro a migração para o Spring Boot 3.2 ou posterior e trate a versão do Jetty como um efeito secundário. E se você já estiver trabalhando com um migração do Spring Framework para o fim de vida útil (EOL) , sequencie as duas migrações juntas, pois o trabalho com o Jakarta se sobrepõe quase que completamente.

Dica de especialista: O Eclipse Transformer pode reescrever automaticamente as referências a javax.* para jakarta.* no bytecode para dependências que você não consegue recompilar a partir do código-fonte. Isso elimina grande parte do trabalho repetitivo, mas os artefatos transformados precisam passar por testes de regressão completos e o fornecedor original não oferecerá suporte a eles; portanto, trate isso como uma solução temporária para uma dependência bloqueada, e não como uma estratégia de migração.

Suas opções caso não seja possível fazer a atualização neste momento

Às vezes, a migração não pode ocorrer neste trimestre. O trabalho envolvido no Spring Boot 3 é muito extenso, ou um produto de fornecedor depende de uma versão antiga do Jetty sobre a qual você não tem controle. Você ainda tem três opções viáveis: suporte estendido oferecido pelo fornecedor, backports mantidos internamente ou a substituição do Jetty.

1. Utilize o Suporte de Ciclo de Vida Ilimitado da TuxCare para o Jetty

Se a migração ainda demorar meses, o suporte estendido oferecido pelo fornecedor mantém o Jetty em fim de vida útil (EOL) atualizado com patches, sem forçar a atualização de acordo com o seu cronograma. O Suporte de Ciclo de Vida Ilimitado da TuxCare oferece correções de segurança para softwares de código aberto em fim de vida, e sua cobertura para o Jetty abrange as versões 7, 8, 9.2, 9.4, 10 e 11, incluindo as compilações pós-EOL que corrigem as vulnerabilidades CVE de 2026: 9.4.60 e posteriores, 10.0.28 e posteriores, e 11.0.28 e posteriores. A Webtide firmou parceria com a TuxCare para oferecer esse serviço, e é por isso que os próprios alertas do Jetty agora orientam os usuários em fim de vida útil a recorrerem a provedores comerciais de patches.

A entrega se adapta à cadeia de ferramentas que você já possui. Os artefatos corrigidos são publicados como pacotes assinados em um registro compatível com o Maven e gerenciado pela TuxCare; assim, as compilações existentes do Maven e do Gradle os utilizam indicando um repositório diferente e atualizando a versão, sem a necessidade de alterar o processo de compilação.

A pegada do Jetty é pequena e simples: jetty-server inclui jetty-http, jetty-io, jetty-utile slf4j-api. O problema é onde as vulnerabilidades (CVEs) se localizam. jetty-http e jetty-server são exatamente onde residem os bugs de contrabando de solicitações e análise de URIs, e o jetty-http costuma ser o artefato que seu scanner sinaliza depois de ter passado por três níveis de dependências. O ELS cobre dependências diretas e transitivas sem custo adicional, de modo que os módulos que realmente contêm as vulnerabilidades do Jetty são corrigidos, e não apenas o artefato que você declarou.

Para a maioria das equipes, essa é a solução pragmática. Ela alivia a pressão imediata em relação à segurança e oferece uma cobertura documentada de patches para apresentar em uma reunião de auditoria, enquanto você planeja adequadamente o trabalho com o Java 17 e o Spring Boot 3.2, em vez de ter que reescrever integrações de servidores web incorporados de acordo com o prazo imposto por terceiros.

2. Manutenção interna do cais

Você pode criar um fork da última versão pública do Jetty e fazer você mesmo o backport das correções de segurança. Isso é tecnicamente possível e, às vezes, a decisão certa para uma implantação altamente personalizada que, de qualquer forma, nunca iria migrar sem problemas.

Além disso, é caro no aspecto que mais importa: você se torna o mantenedor do seu próprio fork do Jetty. Alguém precisa ficar de olho em cada novo aviso de segurança, ler o analisador HTTP/1.x com atenção suficiente para portar corretamente uma correção de vulnerabilidade e enviá-la por meio do seu processo de compilação e lançamento, com testes de regressão para validar a correção. Se você errar em algum detalhe ao corrigir o analisador, acabará lançando um patch que parece aplicado, mas não está, o que é pior do que saber que você está vulnerável. Manter isso exige engenharia de segurança dedicada e capacidade de gerenciamento de lançamentos que a maioria das equipes de aplicativos não tem disponível.

3. Substituir o Jetty por uma alternativa

A possibilidade de substituir o Jetty por outro contêiner de servlets está em discussão, especialmente se você já estivesse pensando em mudar a arquitetura de qualquer maneira. Tomcat e o Undertow são as opções equivalentes, e para uma implantação autônoma com necessidades simples de servlets, o Tomcat é uma das escolhas mais comuns. O Netty é uma proposta diferente: trata-se de uma estrutura de rede assíncrona de nível mais baixo, e não de um contêiner de servlets; portanto, migrar para ele implica uma reformulação arquitetônica, e não uma simples substituição.

Seja honesto quanto ao porte disso. Para um aplicativo embarcado, substituir o servidor muitas vezes significa mais trabalho do que a atualização do Jetty exigiria: um modelo de configuração diferente, ajustes diferentes no conector e no pool de threads, além de uma nova rodada de testes de carga. Uma substituição que “deveria ser equivalente” costuma revelar diferenças de comportamento em casos extremos sob tráfego de produção. E se você já estiver realizando a migração do Jakarta para o Jetty 12, a maior parte desse trabalho é transferível, o que torna a permanência no Jetty a opção mais tranquila para muitas equipes.

Mantenha a segurança do Eclipse Jetty em fim de vida útil (EOL) com a TuxCare

A questão das versões está resolvida. O Jetty 8, 9, 10 e 11 chegaram ao fim do ciclo de vida; os lançamentos públicos das linhas 9, 10 e 11 foram encerrados em 1º de janeiro de 2026; e a migração para o Jetty 12 é um projeto concreto, e não apenas mais uma tarefa a ser marcada na lista. A questão que permanece em aberto é como preencher a lacuna entre o momento atual e a conclusão da migração.

Se você puder migrar para o Jetty 12 neste trimestre, faça isso e planeje de forma realista o trabalho com o JDK 17 e o Spring Boot 3.2. Se não for possível, não utilize versões sem correções, pois existem compilações corrigidas para as linhas em fim de vida (EOL) que simplesmente não são mais publicadas. O suporte oferecido pelo fornecedor mantém as vulnerabilidades conhecidas corrigidas e fornece evidências de um processo ativo de correção enquanto você planeja. Veja como a TuxCare lida com software de código aberto em fim de vida (EOL)e confira os preços para avaliar se ele se encaixa no seu portfólio.

Perguntas frequentes

Quais versões do Eclipse Jetty ainda recebem suporte?

Apenas o Jetty 12.0 e o 12.1 recebem suporte da comunidade. O Jetty 12.1 é a versão atual e recebe correções ativas; o 12.0 ainda recebe atualizações, mas a Webtide informou que elas serão interrompidas em algum momento de 2026, sem ter se comprometido com uma data específica. Todas as versões anteriores, incluindo o Jetty 8, 9, 10 e 11, estão no fim do ciclo de vida.

Ainda é seguro utilizar o Eclipse Jetty 9 em ambiente de produção?

Não sem uma fonte ativa de correções de segurança. O Jetty 9.4 chegou ao fim de vida útil; sua última versão pública foi a 9.4.58.v20250814, lançada em agosto de 2025, e, desde 1º de janeiro de 2026, nenhuma versão da série 9.x é publicada no Maven Central. Existem compilações corrigidas posteriores, mas apenas por meio de provedores de suporte estendido; portanto, utilizar a versão 9.4 de forma responsável significa contar com esse suporte, ou implementar controles compensatórios à frente dela, além de um plano de migração para ambos.

Como posso saber se meu aplicativo Spring Boot usa uma versão do Jetty que chegou ao fim da vida útil (EOL)?

Execute mvn dependency:tree -Dincludes=’org.eclipse.jetty*’ ou ./gradlew dependencies | grep -i jetty. Mantenha o curinga, pois o Jetty 12 publica artefatos de ambiente sob IDs de grupo como org.eclipse.jetty.ee10, que um filtro de correspondência exata não detectaria. Se a saída mostrar um artefato do Jetty 9.x, 10.x ou 11.x, seu aplicativo está em uma linha EOL, mesmo que o Jetty tenha chegado como uma dependência transitiva que você nunca declarou.

A atualização do Jetty 10 para o Jetty 12 exige a migração do javax para o jakarta?

Somente se você estiver trabalhando com o ambiente EE10 ou EE11 do Jetty 12. O Jetty 10 usa javax.servlet, o EE10 usa jakarta.servlet (Servlet 6.0) e o EE11 usa Servlet 6.1. O Jetty 12 também inclui os ambientes EE8 e EE9, e o EE8 mantém o namespace javax.*; portanto, você pode migrar primeiro o núcleo do Jetty e o JDK e tratar a migração do namespace como um projeto à parte.

Qual versão do JDK o Eclipse Jetty 12 requer?

Java 17. Tanto o Jetty 12.0 quanto o 12.1 definem o Java 17 como o ambiente de execução mínimo; portanto, a atualização do JDK é o primeiro passo obrigatório para qualquer equipe que venha do Jetty 9, 10 ou 11 no Java 8 ou no Java 11.

Resumo

Nome do artigo

Fim da vida útil (EOL) do Eclipse Jetty: versões, caminho de atualização e opções

Descrição

As versões Jetty 8, 9, 10 e 11 chegaram ao fim de vida útil, e os lançamentos públicos foram interrompidos em janeiro de 2026. Confira as datas das versões, os comandos de detecção e suas opções.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora