Fim da vida útil do Apache CXF: versões, status do suporte e o que fazer a seguir

Principais conclusões

• O Apache CXF 3.5.x e versões anteriores chegaram ao fim do ciclo de vida, não havendo mais correções de segurança previstas por parte do Apache.
• Atualmente, apenas as versões 4.1.x e 4.2.x estão em desenvolvimento – as versões 3.6.x e 4.0.x já lançaram suas versões finais planejadas.
• EOL CXF significa que, atualmente, existem CVEs conhecidas sem correção e que não haverá correções do Apache para nada que venha a ser descoberto posteriormente.
• Suas opções são atualizar para o CXF 4.x, substituí-lo completamente ou utilizar o suporte estendido para continuar recebendo correções nesse meio tempo.

Se você tem uma pilha de serviços Java que está em operação desde os tempos do Spring XML, é bem provável que o Apache CXF esteja por lá em algum lugar, cuidando discretamente dos seus endpoints SOAP, de uma ou duas APIs JAX-RS e, talvez, de uma integração com WS-Security que ninguém abre há anos. E há uma boa chance de que a versão que você está usando tenha deixado de receber correções há algum tempo.

Todas as versões do CXF da linha 3.5.x e anteriores já estão fora do ciclo de vida, o que significa que não haverá mais correções de segurança por parte do projeto Apache.

Esta publicação explica quais versões do CXF foram descontinuadas, o que isso realmente significa para sua postura de segurança e conformidade e as três opções viáveis que você tem: atualizar para a versão 4.x, substituir o CXF por completo ou ganhar um pouco de tempo com o suporte estendido.

O Apache CXF chegou ao fim de sua vida útil?

O Apache não divulga datas fixas de fim de vida útil (EOL) para o CXF. Na prática, funciona como um modelo contínuo: os ramos que o Apache está lançando ativamente ficam na página de downloads do projeto e, à medida que novas versões são lançadas, as mais antigas são retiradas e deixam de receber correções. No momento, essa página lista o CXF 4.2.x como o ramo mais recente (base no JDK 17, Jakarta EE 11), com o 4.1.x logo atrás (JDK 17, Jakarta EE 10). A linha 3.6.x já lançou o que a Apache chama explicitamente de seu último lançamento planejado, a versão 3.6.11, e a 4.0.x foi encerrada da mesma forma com a versão 4.0.11 – nenhuma dessas é uma ramificação com a qual você deva contar para correções futuras.

Tudo na versão 3.5.x e anteriores está encerrado. O Apache lançou sua versão final de manutenção da série 3.5.x (3.5.11) e seguiu em frente — sem backports, sem correções de CVE, nada mais está por vir. Se sua compilação com Maven ou Gradle ainda fixa o org.apache.cxf na versão 3.5.x ou anterior, você está executando um software em fim de vida (EOL) em produção neste momento, independentemente de alguém ter sinalizado isso ou não.

Versões do Apache CXF com fim de vida útil (EOL) e status de suporte a serem considerados

O Apache não divulga datas formais de término para as versões “LTS ativas” e “LTS em manutenção” do CXF, como fazem alguns ambientes de execução. O suporte depende de qual ramificação está atual; portanto, a tabela abaixo mapeia cada uma delas à sua versão de referência do JDK, namespace e status atual na página de downloads do Apache, em vez de inventar marcos que não existem.

Agência CXF	Linha de base do JDK / namespace	Status do suporte ao Apache
4.2.x	JDK 17 / Jakarta EE 11 (jakarta.*)	Atual, mais recente
4.1.x	JDK 17 / Jakarta EE 10 (jakarta.*)	Atual
4.0.x	JDK 11 / Jakarta EE 9.1 (jakarta.*)	Versão final planejada lançada (4.0.11); agora arquivada
3.6.x	JDK 11 / Java EE 8 (javax.*)	Versão final planejada lançada (3.6.11)
3.5.x	JDK 8 / Java EE 8 (javax.*)	Fim do ciclo de vida (última versão: 3.5.11)
3.4.x e versões anteriores	JDK 8 / javax.*	Fim da vida

Atenção: A mudança de javax.* para jakarta.* ocorre exatamente na fronteira entre as versões 3.x e 4.x. Isso não é um sinalizador de configuração que você pode simplesmente ativar ou desativar – é a principal razão pela qual a transição do CXF 3 para o CXF 4 se transforma em um projeto de migração de verdade, em vez de uma simples atualização de versão.

O que o fim do ciclo de vida (EOL) do Apache CXF significa para sua pilha de serviços Java

Utilizar uma versão do CXF que chegou ao fim da vida útil (EOL) não é apenas um problema abstrato de política em alguma planilha por aí. Isso altera três aspectos concretos: as vulnerabilidades (CVEs) que permanecem em aberto, aquelas das quais você nem sequer vai ouvir falar e as bibliotecas que o CXF traz consigo.

CVEs sem patch, com correções documentadas publicamente

As vulnerabilidades (CVEs) já estão disponíveis, e quanto mais antiga for a sua versão, mais delas se aplicam ao seu caso.

CVE-2022-46363 permite a listagem remota de diretórios ou a exfiltração de código quando o CXFServlet está mal configurado com os atributos `static-resources-list` e `redirect-query-check` ativos simultaneamente. O NVD atribuiu a ela uma pontuação de 7,5, e as correções foram implementadas nas versões 3.5.5 e 3.4.10. CVE-2024-28752, uma falha de SSRF que afeta apenas implantações que utilizam o Aegis DataBinding (não o databinding padrão), possui uma pontuação NVD de 9,3 e afeta versões anteriores à 4.0.4, 3.6.3 e 3.5.8. Essas duas séries de correções mostram como os backports se restringem com o tempo: a correção de 2022 atingiu tanto a 3.4.x quanto a 3.5.x, mas a correção de 2024 parou na 3.5.8 — ela nunca chegou à 3.4.x. Quanto mais antiga for a sua ramificação, mais cedo ela desaparece da lista de versões corrigidas.

E isso não é um problema histórico. O Apache publicou 14 novos alertas do CXF somente em 2026, incluindo uma vulnerabilidade XXE na funcionalidade WS-Transfer, uma falha de injeção LDAP no repositório XKMS LDAP, um conjunto de falhas no OAuth2 e uma correção incompleta para um problema anterior de execução remota de código relacionado ao JMS. Os ramos atuais incorporam essas correções. Os ramos desativados, não.

Essa é, na verdade, a armadilha do software sem suporte. A vulnerabilidade está documentada, o patch está disponível ao público, e a comparação de alterações (diff) está bem ali no histórico de commits. Os invasores não precisam descobrir nada por conta própria — eles podem estudar o aviso de segurança e o patch e, em seguida, procurar por instalações que ainda estejam rodando uma versão vulnerável. O Relatório DBIR 2026 da Verizon revelou que a exploração de vulnerabilidades é agora o vetor de acesso inicial mais comum, representando 31% das violações, um aumento em relação aos 20% do ano anterior – a primeira vez, nos 19 anos de história do relatório, que ela ultrapassou o uso indevido de credenciais e assumiu o primeiro lugar.

As vulnerabilidades (CVEs) que o Apache nunca corrigirá na sua ramificação

O maior risco é aquele que você ainda não consegue enxergar. Quando um branch chega ao fim da vida útil (EOL), qualquer problema descoberto nesse código posteriormente simplesmente não será corrigido pela Apache.

Suponha que, no ano que vem, seja identificada uma falha no CXF que afete a linha 3.5.x. Ela seja corrigida nos ramos 4.x atuais, mas permaneça sem correção em todos os outros ramos. Você lê o comunicado, verifica sua versão e percebe que não há nenhuma versão corrigida disponível para o seu ramo. Nesse momento, você se depara com a necessidade de uma migração de emergência ou de um backport do fornecedor, e nenhuma das duas opções ocorre da noite para o dia.

Essa é, mais ou menos, a lacuna que as atualizações oferecidas pelos fornecedores se propõem a preencher. O Suporte de Ciclo de Vida Ilimitado da TuxCare  continua produzindo correções de segurança para ramificações do CXF das quais o Apache já se afastou — uma maneira de continuar recebendo correções sem ser forçado a fazer uma atualização para a qual você ainda não está preparado.

Se você quiser ver o que já está sendo monitorado em relação às versões do CXF em fim de vida (EOL) e suas dependências, o TuxCare CVE Tracker permite filtrar as vulnerabilidades do CXF por gravidade e status da correção, sem que você precise vasculhar o NVD por conta própria.

As dependências transitivas que vêm junto

O CXF não funciona isoladamente. Ele utiliza bibliotecas para análise de XML, streaming StAX e segurança de XML, e cada uma delas tem seu próprio histórico de vulnerabilidades CVE com o qual é preciso se preocupar.

Quando o CXF é congelado em uma versão EOL, essas dependências tendem a ser congeladas junto com ele. O impacto vai além do próprio CXF – ele se estende a quaisquer versões mais antigas de bibliotecas que a compilação congelada tenha adotado. Vimos o mesmo padrão no Apache Camel e Apache Struts ; é um tema recorrente em frameworks que não recebem atualizações há algum tempo.

Estruturas de conformidade afetadas pela execução do Apache CXF em fim de vida útil (EOL)

Os auditores não se importam se o CXF é “interno” ou está “protegido por um firewall”. Softwares sem suporte tendem a ser apontados como uma falha por si só, pois violam os pressupostos de aplicação de patches nos quais a maioria das estruturas de auditoria se baseia. É nesse ponto que o CXF em fim de vida útil (EOL) costuma causar problemas para as pessoas.

PCI DSS 4.x

PCI DSS O requisito 6.3.3 exige que as correções críticas ou de alta segurança aplicáveis sejam instaladas no prazo de um mês após o lançamento, com todas as demais correções aplicáveis instaladas de acordo com um cronograma documentado e baseado no risco. Uma versão do CXF em fim de vida útil (EOL) sem fonte de patch torna ambos os cronogramas impossíveis de cumprir — não há mais nada para aplicar. Se um componente vulnerável do CXF estiver em qualquer lugar do seu ambiente de dados de titulares de cartões, essa lacuna é do tipo que se transforma em uma não conformidade com o Requisito 6.3.3. As ferramentas de conformidade podem sinalizar a versão para você, mas não podem aplicar patches ao que o Apache não oferece mais suporte.

SOC 2

Os critérios de segurança do SOC 2 pressupõem que você tenha um processo de gerenciamento de vulnerabilidades. Softwares sem fonte de patch disponível são difíceis de conciliar com isso. A pergunta que os auditores acabam fazendo não é se você aplica patches rapidamente – é se você consegue aplicar patches de fato. 

FIPS e cargas de trabalho federais

Se você estiver trabalhando em um contexto que exija criptografia validada, uma estrutura em fim de vida (EOL) complica toda a cadeia. O status do ciclo de vida do CXF, por si só, não invalida um módulo validado pela FIPS, mas uma estrutura congelada pode prendê-lo a versões de bibliotecas criptográficas que perderam o status de validade, sem que haja mais lançamentos do desenvolvedor original para permitir que você avance.

Opções após o fim do ciclo de vida do Apache CXF

Você tem três caminhos reais a seguir, e qual deles é o certo depende de quanto risco de migração você pode absorver agora, em comparação com mais tarde. Nenhuma dessas opções é “não fazer nada”. Isso deixou de ser uma opção viável no dia em que sua ramificação chegou ao fim da vida útil (EOL).

• Não dá para migrar neste trimestre, mas precisa manter as atualizações em dia? Suporte estendido.
• Tem o JDK 17 e tempo de engenharia disponível? Faça a atualização para a versão 4.x.
• O CXF é pouco utilizado, ou você está trocando de plataforma de qualquer maneira? Substitua-o.

Utilize o suporte contínuo ao ciclo de vida do Apache CXF

Uma maneira direta de eliminar o risco imediato, sem precisar reescrever o aplicativo, é o suporte de segurança oferecido pelo fornecedor. O Endless Lifecycle Support (ELS) da TuxCare mantém o Apache CXF em fim de vida (EOL) atualizado com patches, incluindo ramificações que o Apache retirou completamente de circulação, como a 3.5.x, com correções disponibilizadas à medida que novos CVEs são divulgados. Atualmente, a cobertura visa especificamente o CXF 3.5.9 e 3.5.11, com patches para CVEs ainda sendo lançados para ambas as versões muito tempo depois do lançamento final da versão 3.5.x do Apache. As correções são distribuídas por meio de repositórios assinados e hospedados pela TuxCare que se integram ao fluxo de trabalho do Maven ou do Gradle que você já possui.

O que a maioria das equipes subestima é a árvore de dependências. O CXF vem com bibliotecas de tempo de execução para análise de XML, gerenciamento de esquemas e segurança, e essas bibliotecas precisam de correções tanto quanto o próprio código do CXF. O TuxCare ELS cobre tanto as dependências diretas quanto as transitivas, sem custo adicional, para que você não precise aplicar correções na estrutura enquanto uma biblioteca vulnerável, localizada mais profundamente na árvore, permaneça sem correção.

Essa abordagem faz mais sentido quando a migração envolve um trabalho de engenharia complexo e você não pode agendá-la neste momento. Você permanece na versão atual, seus serviços SOAP e REST continuam funcionando sem a necessidade de reescrevê-los, e você continua recebendo correções de segurança enquanto planeja a atualização no seu próprio ritmo, em vez de sob a pressão de uma violação de segurança. É uma ponte, não o destino final. O objetivo ainda é atualizar o sistema eventualmente, mas nos termos que você realmente controla.

Isso se encaixa especialmente bem em duas situações: um serviço congelado, mas essencial para os negócios, que não pode arcar com uma migração de javax.* para jakarta.* neste ano; e uma base de código herdada, na qual ninguém ainda definiu totalmente o escopo da migração. Em ambos os casos, o ELS recupera a única coisa que o fim do suporte (EOL) tira: tempo.

Atualizar para o Apache CXF 4.x

A solução mais adequada a longo prazo é migrar para um ramo 4.x atual. Essa é a decisão certa se você tiver recursos de engenharia disponíveis e se o seu ambiente de execução puder realmente ser migrado.

O problema é duplo. Primeiro, o CXF 4.x é executado no namespace jakarta.*; portanto, todas as importações de javax.ws.rs, javax.xml.ws e outras relacionadas no código da sua aplicação precisam ser migradas, e qualquer dependência ainda compilada com base nas antigas APIs javax.* precisa de uma atualização ou substituição compatível com o jakarta. Em segundo lugar, a versão de referência do JDK mudou: o CXF 4.0.x tem como referência o JDK 11, enquanto as versões 4.1.x e 4.2.x exigem o JDK 17. Ferramentas como o Eclipse Transformer podem lidar automaticamente com boa parte da reescrita do namespace, mas qualquer elemento reflexivo ou baseado em strings na sua configuração precisará de uma revisão manual. Encare isso como um projeto, não como algo para se fazer em uma tarde.

Uma observação sobre a versão mais recente: a Apache destaca que a versão 4.2.x atual depende de compilações alfa do Undertow, portanto, sua integração com o Undertow pode ainda não estar estável. Se o Undertow faz parte da sua pilha de tecnologias, a versão 4.1.x é a opção mais segura por enquanto.

Substituir o CXF por uma estrutura ou abordagem alternativa

Se o CXF estiver lidando apenas com uma pequena parte da sua pilha de tecnologias, substituí-lo pode, na verdade, dar menos trabalho do que uma migração completa para a versão 4.x. Equipes que, em sua maioria, executam endpoints REST às vezes migram para o Spring MVC ou WebFlux no Spring Boot, ou para uma implementação do JAX-RS, como o Jersey ou o RESTEasy. Usuários intensivos de SOAP e WS-Security não têm tantas opções de saída simples, para ser sincero, já que essa é precisamente a carga de trabalho para a qual o CXF foi criado inicialmente, e é por isso que essas equipes tendem a permanecer no CXF por mais tempo do que gostariam.

Seja honesto consigo mesmo em relação ao trabalho envolvido antes de se comprometer com isso. Uma substituição implica reescrever os limites do seu serviço, com todos os testes que isso acarreta. Se você tiver contratos WSDL extensos, políticas de WS-Security ou anexos MTOM envolvidos, a ideia de “simplesmente trocar a estrutura” geralmente subestima o trabalho real em grande medida.

Proteja o Apache CXF após o fim do suporte (EOL) com a TuxCare

Utilizar o Apache CXF, que está no fim do ciclo de vida (EOL), representa um risco de evolução gradual. Ele funciona bem até que uma vulnerabilidade CVE divulgada publicamente ou uma auditoria transforme a situação em uma emergência da noite para o dia. Você não precisa escolher entre uma migração disruptiva agora mesmo e simplesmente ignorar essa exposição.

O suporte estendido mantém sua versão atual atualizada com os patches enquanto você planeja a atualização de acordo com sua própria programação, e uma migração para a versão 4.x ou uma troca de framework resolve esse problema específico de fim de vida útil (EOL) assim que você estiver pronto. A única opção que sempre acaba mal é deixar as coisas como estão. Comece por avaliar os custos de suas opçõesou veja como a TuxCare mantém as pilhas de código aberto legadas seguras de maneira mais abrangente em ELS para Software de Código Aberto.

Perguntas frequentes