Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O Commons Lang está presente em todas as pilhas de Java corporativas; portanto, uma única cópia sem patch se torna um problema generalizado.
- O Apache disponibiliza correções em versões posteriores, em vez de ramos de retroportagem, de modo que as versões mais antigas da série 3.x deixam de recebê-las.
- As atualizações feitas às pressas dão errado porque
commons-lang3geralmente ocorre de forma transitiva, e as surpresas relacionadas à mediação surgem durante a execução. - O ELS da TuxCare publica compilações corrigidas de versões mais antigas do Commons Lang, para que você continue protegido enquanto faz seus planos.
O Commons Lang é aquela dependência sobre a qual ninguém marca uma reunião. Ele oferece os utilitários que o JDK nunca incluiu, StringUtils e ClassUtils e NumberUtils e as classes de construção, e depois passa a ficar em segundo plano em todos os serviços que você possui. Ele não carrega nada em tempo de execução, quase nunca apresenta falhas e vem fazendo isso discretamente desde que o Commons Lang 1.0 foi lançado, em 2002. Atualmente, o MvnRepository a coloca no topo da categoria “Core Utilities”, com cerca de 50.000 artefatos listados como usuários dela — o que é uma maneira educada de dizer que ela quase certamente está em algum lugar do seu arquivo de compilação.
É exatamente isso que torna uma cópia desatualizada irritante. Uma vulnerabilidade (CVE) em uma biblioteca acessada apenas pelo seu serviço de cobrança tem um impacto limitado a um único serviço. Uma vulnerabilidade (CVE) em commons-lang3 aparece em todos os lugares onde seu código o chama, e, em muitos ambientes Java corporativos, essa é uma longa lista de locais da qual ninguém tem um inventário bem organizado.
Essa é a parte que pega as equipes de surpresa. O Apache não divulga uma data de fim de vida útil para versões individuais do Commons Lang. Não há aviso de descontinuação, nem comunicado informando que o ramo em que você está não recebe mais atualizações. O que você também não recebe é um ramo mantido para sua versão mais antiga; portanto, assim que uma correção é incorporada a uma versão mais recente, geralmente não há um fluxo de manutenção que a traga de volta para a sua versão.
Como o Apache Commons Lang realmente lida com os lançamentos
É bom entender isso antes de acabar discutindo com um scanner por causa disso.
Comece pela divisão. O Apache lançou o Commons Lang 3.0 em 2011 com uma mudança deliberada no namespace dos pacotes. A linha 2.x está disponível em org.apache.commons.lang e a versão 3.x está disponível em org.apache.commons.lang3. Isso foi feito de propósito para que ambas pudessem coexistir no mesmo classpath sem conflitos, e é também por isso que muitas bases de código de grande porte ainda mantêm as duas versões. Do ponto de vista do ciclo de vida, a versão 2.x está encerrada em todos os aspectos que importam. A última versão lançada foi a 2.6, em 2011; o desenvolvimento mudou para a linha 3.x e nada mais foi lançado desde então. Quem ainda usa a versão 2.x vem operando sem as correções do upstream desde 2011.
A linha 3.x funciona de maneira diferente do que a maioria das pessoas imagina. O Apache não mantém ramificações paralelas de suporte de longo prazo da mesma forma que o JDK. As correções são incorporadas à próxima versão, e o histórico de versões publicado não apresenta nenhuma linha de manutenção 3.12.x nem nenhuma ramificação de retroportagem 3.17.x. Portanto, embora o Apache nunca tenha declarado formalmente o fim da vida útil de nenhuma versão 3.x, o resultado prático é o mesmo. Se uma correção for incorporada a uma versão mais recente, ela não chegará à sua.
Vale a pena esclarecer bem essa distinção ao redigir um relatório para um auditor. “Não há versão de backport upstream para esta versão” é uma afirmação precisa e justificável. “Fim oficial do ciclo de vida (EOL) a partir de uma data específica” não é, pois o Apache nunca publicou tal data.
Em setembro de 2026, a versão mais recente é a 3.20.0, lançada em 12 de novembro de 2025. Também vale a pena conhecer os requisitos mínimos de Java. A partir da versão 3.9, a biblioteca requer o Java 8; portanto, todas as versões a partir da 3.9 exigem o Java 8 ou posterior, e a integração contínua (CI) do projeto atualmente é executada nas versões LTS suportadas, ou seja, 8, 11, 17, 21 e 25.
| Linha de versão | Espaço de nomes do pacote | Situação atual | Lançamento mais recente |
|---|---|---|---|
| Commons Lang 2.x | org.apache.commons.lang |
O desenvolvimento foi encerrado; não há correções desde 2011 | 2.6 (2011) |
| Commons Lang 3.x, versões anteriores | org.apache.commons.lang3 |
Ainda está sendo distribuído na versão de produção, mas não há um ramo de retroportabilidade | n/a, substituído |
| Commons Lang 3.x, versão atual | org.apache.commons.lang3 |
Onde as correções realmente são aplicadas | 3.20.0 (novembro de 2025) |
O que significa, na prática, o fim do suporte (EOL) do Commons Lang
As correções não chegam mais até você
A vulnerabilidade CVE-2025-48924, divulgada em julho de 2025, é um bom exemplo justamente por não ter nada de espetacular. ClassUtils.getClass() resolvia nomes de classes aninhadas de forma recursiva; portanto, uma entrada suficientemente longa poderia esgotar a pilha e gerar um StackOverflowError. Como se trata de um erro e não de uma exceção, os aplicativos geralmente não o tratam, e a falha pode interromper o funcionamento do aplicativo. O Apache classificou-o como de baixo risco, o ADP da CISA atribuiu-lhe uma pontuação de 5,3, e ele foi identificado pelo OSS-Fuzz. Isso nunca iria virar manchete.
O que chama a atenção é a forma como isso se apresenta. O comunicado abrange as versões 2.0 a 2.6 do commons-lang e todas as commons-lang3 versões da 3.0 até a 3.18.0, excluída, que inclui a correção do desenvolvedor original. Não existe uma versão 3.17.0 corrigida pelo desenvolvedor original. Se uma estrutura de aplicativos o obrigar a permanecer nessa versão, ou se houver um congelamento de alterações, ou se ninguém tiver orçamento para realizar testes de regressão em uma biblioteca de utilitários que abrange quarenta serviços, essa falha permanecerá na saída do seu scanner indefinidamente.
Uma coisa que é preciso ter em mente durante a triagem é que um CVE do Commons Lang recém-divulgado não afeta automaticamente a versão que você estiver executando. Muitos deles não afetarão. O que o EOL elimina é a possibilidade de corrigir aqueles que afetam sem precisar também mudar de versão.
Quando a conformidade se torna complicada
O Requisito 6.3.3 da PCI DSS v4.0.1 exige que as correções para vulnerabilidades críticas — classificadas por meio do seu próprio processo descrito no Requisito 6.3.1 — sejam aplicadas no prazo de um mês a partir do lançamento da correção. Todo o restante segue um prazo que você determina com base em sua própria avaliação do grau de gravidade do risco para o seu ambiente. A versão 4.0 do PCI DSS aplicava esse prazo de um mês também a correções críticas ou de alta segurança, e a versão 4.0.1 restringiu-o novamente às vulnerabilidades críticas.
Outros regimes são menos prescritivos, e exagerar em relação a eles é uma maneira infalível de perder um leitor técnico. O FedRAMP define prazos de correção de acordo com a gravidade. A Regra de Segurança da HIPAA exige que você realize uma análise de risco e gerencie vulnerabilidades conhecidas, sem especificar um número de dias. O SOC 2 é baseado em critérios; portanto, o seu auditor se importa em saber se o processo de aplicação de patches que você documentou é o mesmo que você realmente segue. Nenhum deles torna fácil defender um componente que não tenha um caminho de correção.
O principal problema com uma biblioteca de utilitários é o escopo. Um servidor de aplicativos vulnerável fica em um único local e gera uma única descoberta. Um servidor vulnerável commons-lang3 aparece uma vez por cada artefato que o inclui, o que transforma uma única versão sem patch em um exercício de correção que envolve equipes que nunca se comunicaram entre si. Controles compensatórios podem ganhar tempo e costumam ser a decisão certa, mas a questão de saber se eles são suficientes deve ser discutida com seu avaliador, e não é algo que se resolve simplesmente marcando uma opção.
Suas opções após o fim do suporte ao Apache Commons Lang
Atualize para a versão mais recente
Para as equipes que têm condições, migrar para a versão atual é a decisão certa a longo prazo. O Apache mantém a compatibilidade dentro da série 3.x razoavelmente rigorosa, o namespace lang3 tem se mantido estável em toda a linha, e o projeto publica relatórios de compatibilidade binária para suas versões. As versões individuais ainda descontinuam recursos e ajustam comportamentos; portanto, trate isso como uma atualização, e não como um simples carimbo de aprovação.
O problema é que raramente se trata de uma alteração de apenas uma linha. commons-lang3 geralmente está na sua árvore de projetos porque foi colocado lá por outro elemento — uma camada de persistência, um framework ou outro componente do Apache Commons —, e a versão que você acaba utilizando é aquela escolhida pela mediação do Maven. Uma declaração direta com sua própria versão no seu pom.xml ganha essa disputa. Se você não especificar a versão e deixar que um POM pai ou uma BOM importada a forneça, a versão gerenciada é que decide. Uma cópia sombreada incluída no artefato de outra pessoa fica totalmente fora do processo de mediação e não será afetada por nada disso. É por isso que mvn dependency:tree -Dverbose é o primeiro comando a ser executado, e não o último.
Substituir por uma biblioteca de utilitários diferente
Algumas equipes aproveitam o momento para repensar completamente essa dependência. O Guava cobre grande parte desse mesmo escopo, o Spring inclui suas próprias classes utilitárias e as APIs principais do Java 8+ absorveram boa parte do que o Commons Lang se propunha a oferecer inicialmente.
É uma decisão arquitetônica legítima, mas sejamos honestos quanto às implicações. O Guava também é uma dependência de terceiros com seu próprio histórico de CVEs e adota uma abordagem mais flexível em relação à rotatividade do que o Apache Commons, já que qualquer coisa marcada como @Beta pode sofrer alterações ou desaparecer em qualquer versão. Você está trocando uma superfície da cadeia de suprimentos por outra, em vez de removê-la. A migração também implica auditar todos os pontos de chamada, reescrevê-los e validar o comportamento na nova implementação. Trata-se de um projeto de migração, não de um sprint, o que o torna uma resposta inadequada para um prazo de correção previsto para o próximo mês.
Mantenha sua versão e aplique a correção mesmo assim
A terceira opção é manter a versão como está e obter correções de segurança para ela em outro lugar que não seja o upstream. É isso que o Endless Lifecycle Support da TuxCare faz, e é a única das três opções que separa o status das correções do seu cronograma de atualizações.
Por que apressar uma atualização do Commons Lang acaba saindo pela culatra
Quando surge a pressão — e ela geralmente surge na forma de uma descoberta feita pelo scanner, e não de uma decisão —, o instinto é aumentar a versão e lançá-la. Algumas coisas tendem a dar errado.
A mediação de versões é a primeira. Quando várias dependências declaram diferentes commons-lang3 versões, o Maven recorre à declaração mais próxima no gráfico, em vez daquela com a qual seu código foi testado, sendo que a ordem das declarações desempata em casos de igualdade na mesma profundidade. A compilação pode permanecer com status “verde” enquanto um NoSuchMethodError, um NoClassDefFoundError ou alguma outra falha de compatibilidade venha à tona mais tarde, em um caminho de execução que não foi detectado nos testes.
A reação habitual pode piorar a situação. As equipes recorrem a <exclusions> no Maven ou restrições de dependência no Gradle para forçar a versão desejada, o que elimina o erro imediato, mas deixa para trás um gráfico de dependências que ninguém vai querer mexer na próxima atualização. Faça isso em vários serviços sob pressão de tempo e você terá trocado um problema de correção por um problema de manutenção.
A deriva comportamental é o risco mais sutil. Os auxiliares de string, reflexão e valores numéricos do Commons Lang foram aprimorados ao longo de várias versões, e o código que depende de um caso de borda, como o tratamento de valores nulos em um determinado StringUtils Um método, por exemplo, pode alterar o comportamento sem alterar a assinatura. Nada falha na compilação. Ele simplesmente retorna algo ligeiramente diferente em produção.
Nada disso é inevitável. É o que acontece quando o trabalho é comprimido em um prazo determinado por um calendário de conformidade, em vez de pelo gráfico de dependências. As equipes que passam por essas transições sem problemas fazem sempre as mesmas três coisas: auditam a árvore de forma adequada, testam o comportamento do qual seu código realmente depende e mantêm uma postura de segurança estável enquanto ambas as atividades ocorrem.
O que o ELS para o Apache Commons Lang oferece a você
A TuxCare vem desenvolvendo patches para softwares de código aberto há quinze anos e já lançou mais de 420.000 patches em todo o seu portfólio. O serviço Commons Lang destaca as versões nas quais as pessoas ainda estão presas. A documentação atualmente lista o Commons Lang 2.4 e 2.6 no namespace antigo, além de commons-lang3 3.4, 3.8.1, 3.10, 3.11, 3.12.0, 3.14.0, 3.15.0 e 3.17.0.
Do ponto de vista técnico, não tem nada de especial, e é justamente essa a ideia. Suas credenciais são inseridas no Maven’s settings.xml, o repositório do TuxCare fica na sua pom.xml, ou os equivalentes no Gradle para ambos, e você define a dependência para a versão mantida; assim, a 2.6 passa a ser 2.6-tuxcare.1. Seus endereços de chamada não mudam, suas ferramentas de compilação não mudam e a CI continua resolvendo os artefatos da mesma forma de sempre. Se você preferir que suas compilações não acessem diretamente um fornecedor, é possível redirecionar todo o processo por meio do seu próprio gerenciador de repositório.
Quanto aos prazos, a TuxCare estabelece uma meta de 14 dias a partir da divulgação pública para vulnerabilidades altas e críticas com pontuação CVSS 7,0 ou superior, 60 dias para as médias e 90 dias para as baixas. Esses prazos começam a contar a partir da divulgação. O PCI DSS começa a contar a partir do lançamento da correção; portanto, a meta de 14 dias foi definida para deixar uma margem dentro do prazo de um mês. O Requisito 6.3.3 se aplica a vulnerabilidades críticas.
Uma observação sobre a cobertura de dependências, pois é fácil exagerar na importância disso. commons-lang3 Não possui nenhuma dependência de tempo de execução, por padrão, portanto não há nenhuma árvore oculta por trás dele. Funciona exatamente ao contrário. commons-lang3 geralmente é a dependência transitiva que se encontra na árvore de dependências de outra pessoa, e é exatamente por isso que passa despercebida. O ELS for Libraries cobre as dependências diretas e transitivas dos componentes suportados sem custo adicional, e isso é extremamente importante para algo como o Struts ou o Tomcat. Especificamente para o Commons Lang, o valor está no fato de que a biblioteca da qual tudo o mais depende finalmente conta com uma compilação mantida.
O restante é a infraestrutura que você esperaria. Os pacotes contêm assinaturas OpenPGP independentes e provêm de um registro gerenciado pela TuxCare; assim, a autenticidade e a integridade são verificáveis, e não apenas presumidas. Há um feed VEX do CycloneDX para as bibliotecas Java, incluindo o Commons Lang, que informa aos seus scanners e auditores quais CVEs se aplicam efetivamente a uma determinada compilação, em vez de apenas aqueles que mencionam o pacote. As SBOMs são fornecidas nos formatos SPDX e CycloneDX, com o feed Java publicado no Nexus junto com os pacotes. O suporte funciona 24 horas por dia, 7 dias por semana, 365 dias por ano, por meio do Portal de Suporte da TuxCare, para triagem, solicitações de patches e eventuais problemas com o sistema de compilação.
Para consultar a lista atualizada das versões compatíveis do Apache Commons Lang, consulte a documentação da TuxCare. Para verificar quais CVEs do Apache Commons Lang já foram corrigidos, acesse o rastreador de CVEs em tempo real.
Não deixe que o fim do suporte ao Commons Lang coloque seus aplicativos em risco
A perda do suporte de manutenção do upstream, por si só, não causa nenhum problema. Esse é, na verdade, o problema, e é por isso que ela permanece fora do roteiro de desenvolvimento até que um scanner ou um auditor a inclua nele. Suas aplicações continuam funcionando, seus testes continuam sendo aprovados, e a única coisa que mudou é que as correções do upstream para a sua versão deixaram de chegar.
A atualização para a versão atual ainda é o caminho certo a seguir. Para chegar lá da maneira correta, é preciso definir o escopo da auditoria de dependências, testar o comportamento do qual seu código realmente depende e encaixar o trabalho em um cronograma de lançamento que também envolve outras pessoas. Isso é um plano, e planos levam tempo que você não tem quando o prazo é determinado por outra pessoa.
O suporte estendido é o que proporciona esse tempo. Ele não substitui a atualização, e ninguém deve fingir o contrário. Ele mantém atualizadas as versões do Commons Lang que oferece suporte, fornece a você algo justificável para apresentar a um avaliador e permite que seus engenheiros dediquem o trimestre ao plano de desenvolvimento, em vez de uma migração de emergência da biblioteca.
Se o fim do suporte (EOL) do Apache Commons Lang estiver em sua agenda no momento, confira o ELS da TuxCare para o Apache Commons Lang, que oferece suporte estendido para versões selecionadas do Commons Lang e do commons-lang3 que já não contam mais com suporte.
