Risco de vulnerabilidade do Log4j

Vá direto para um resumo gerado por IA desta postagem do blog

Lembra-se de dezembro de 2021? Aquele pânico coletivo quando surgiu a vulnerabilidade Log4Shell e, de repente, todas as equipes de engenharia do planeta correram para descobrir se estavam usando o Log4j, onde ele estava escondido em sua pilha de tecnologias e com que rapidez poderiam aplicar o patch?

A maioria das equipes acredita que essa história chegou ao fim no início de 2022. Elas corrigiram suas aplicações, verificaram suas dependências, talvez tenham atualizado algumas bibliotecas e seguiram em frente. O Log4j se tornou um daqueles incidentes do tipo “lembra daquela vez?” — estressante na época, mas resolvido.

Só que a questão não está resolvida. Nem de longe.

A verdade é que o risco da vulnerabilidade do Log4j não desapareceu após a onda inicial de correções do Log4Shell. Ele apenas ficou mais discreto e difícil de detectar. Hoje, em 2026, instâncias vulneráveis do Log4j ainda estão ocultas em ambientes de produção, embutidas em locais onde as equipes pararam de procurar há anos. E isso não se deve ao descuido das equipes de engenharia – mas sim ao fato de que a própria natureza do funcionamento das dependências de software faz com que a ideia de “já aplicamos o patch uma vez” seja, muitas vezes, uma falsa sensação de que o problema está resolvido.

Vamos falar sobre onde está, atualmente, o verdadeiro risco do Log4j, por que ele continua ressurgindo e como seria uma mitigação realmente eficaz ao lidar com pilhas de software modernas que possuem camadas e mais camadas de dependências ocultas.

O panorama das vulnerabilidades do Log4j além do Log4Shell

O Log4Shell (CVE-2021-44228) foi o que mais chamou a atenção da mídia, e com razão. Uma vulnerabilidade de execução remota de código em uma biblioteca de registro de eventos usada por metade do ecossistema Java é o pior que pode acontecer. Mas concentrar-se apenas no Log4Shell é como se preocupar com o tubarão que você consegue ver, enquanto ignora aqueles que estão circulando abaixo da superfície.

Desde o Log4Shell, várias outras vulnerabilidades do Log4j foram descobertas. CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 e outras surgiram em rápida sucessão. Cada uma delas exigiu atenção, cada uma exigiu correções e cada uma comprovou que o Log4j, como componente, apresentava problemas de segurança mais profundos do que apenas aquela vulnerabilidade espetacular de RCE.

O que é particularmente insidioso é que essas vulnerabilidades subsequentes costumam afetar intervalos de versões diferentes daqueles afetados pelo Log4Shell. Uma equipe que atualizou do Log4j 2.14.1 para o 2.15.0 a fim de corrigir o Log4Shell poderia ter ficado vulnerável ao CVE-2021-45046. A atualização para a versão 2.16.0 resolveu esse problema, mas as versões mais antigas ainda apresentavam a vulnerabilidade CVE-2021-44832, que continuava sendo motivo de preocupação. Esse jogo de “bate-na-toupeira” com as vulnerabilidades tornou complicado o rastreamento de versões “seguras”, e muitas organizações perderam o controle sobre quais sistemas haviam sido totalmente corrigidos e quais apenas parcialmente.

Depois, há o elefante na sala: o Log4j 1.x. Embora grande parte do pânico público tenha se concentrado nas vulnerabilidades do Log4j 2.x, o Log4j 1.x tem seus próprios problemas de segurança e chegou ao fim de vida útil em 2015. No entanto, ele ainda está em circulação, rodando em sistemas de produção que nunca migraram para o Log4j 2.x. Esses sistemas enfrentam vulnerabilidades que nunca receberão correções oficiais, pois a base de código foi abandonada.

O panorama das vulnerabilidades também não é estático. Pesquisadores de segurança continuam encontrando problemas em bibliotecas de registro de log. A atenção que o Log4Shell chamou para o Log4j e componentes semelhantes significa que há mais pessoas procurando por problemas. Seria ingênuo supor que já encontramos a última vulnerabilidade do Log4j.

Onde o Log4j se esconde nas pilhas modernas

A razão pela qual o risco do Log4j persiste não é que as equipes o ignorem deliberadamente. É que identificar todas as instâncias do Log4j em uma pilha de aplicativos moderna é realmente difícil.

Dependências transitivas são o esconderijo mais comum. Seu aplicativo pode não depender diretamente do Log4j, mas uma de suas dependências depende. Ou uma das dependências dessas dependências depende. Ou você está em várias camadas de profundidade em uma árvore de dependências e, em algum lugar lá dentro, enterrado três níveis abaixo, está o Log4j 2.14.0.

As ferramentas de verificação de dependências ajudam, mas não são perfeitas. Elas podem informar sobre dependências conhecidas nos arquivos de dependências declarados do seu projeto, mas nem sempre detectam tudo. Às vezes, as bibliotecas ocultam dependências — agrupando-as internamente de maneiras que não aparecem na análise padrão de dependências. Outras vezes, a dependência existe em um artefato binário que o seu verificador não analisa com profundidade suficiente.

Aplicativos em contêineres apresentam seus próprios desafios. Você pode estar executando imagens de contêineres criadas meses ou anos atrás, antes que o Log4Shell fosse conhecido. A imagem base pode conter versões vulneráveis do Log4j. As camadas da aplicação podem agravar ainda mais a situação. A menos que você esteja recompilando e verificando as imagens regularmente, essas vulnerabilidades persistem mesmo que seu código-fonte atual esteja livre de falhas.

Aplicativos de terceiros e softwares comerciais frequentemente incluem suas próprias dependências, incluindo o Log4j. Aquela ferramenta de monitoramento corporativo que você implantou em 2020? Ela pode estar executando o Log4j 2.12.1 internamente, e você não tem visibilidade sobre isso porque se trata de uma “caixa preta” do fornecedor. O fornecedor pode ter lançado uma versão corrigida, mas se você não estiver acompanhando de perto os alertas de segurança do fornecedor ou se as atualizações exigirem testes extensos e tempo de inatividade, essa instância vulnerável permanecerá em uso.

Você também pode consultar nosso guia técnico sobre como implementar uma correção para a vulnerabilidade do Log4j, a fim de identificar dependências ocultas em pilhas complexas.

Ferramentas de compilação e ambientes de desenvolvimento às vezes contêm versões vulneráveis do Log4j que não fazem parte diretamente da sua aplicação de produção, mas ainda assim representam um risco. Plug-ins do Jenkins, repositórios do Maven, extensões de IDE — todos eles podem conter o Log4j e nem sempre são incluídos em varreduras de vulnerabilidades voltadas para a produção.

Sistemas legados e bases de código congeladas são talvez os maiores desafios. Aquela aplicação crítica em Java que vem rodando inalterada há cinco anos porque é estável e “ninguém quer mexer nela”? Provavelmente contém o Log4j vulnerável. Mas atualizá-la significa testá-la com as versões atuais do JDK, validar integrações que não são alteradas há anos e, possivelmente, descobrir que dependências críticas não são mais mantidas.

Componentes e dispositivos embarcados completam a lista. Dispositivos de rede, aparelhos de segurança, sistemas de IoT e outras aplicações Java incorporadas costumam usar o Log4j internamente. Esses são, normalmente, os mais difíceis de corrigir, pois as atualizações precisam vir do fornecedor, os ciclos de atualização são lentos e, às vezes, o próprio fornecedor já encerrou suas atividades ou deixou de oferecer suporte ao produto.

O traço comum a todos esses cenários é a invisibilidade. Essas instâncias do Log4j não aparecem na árvore de dependências do seu aplicativo principal. Elas não são abrangidas pelos seus processos padrão de aplicação de patches. Elas existem nas lacunas entre o que você pensa que está executando e o que está, de fato, implantado.

Por que a desculpa “Já corrigimos isso uma vez” não cola

Mesmo as equipes que realizaram uma correção completa no final de 2021 e início de 2022 frequentemente descobrem que instâncias vulneráveis do Log4j estão voltando a se infiltrar em seus ambientes. Isso não ocorre porque os patches foram revertidos, mas porque os ecossistemas de software são dinâmicos.

Novas implantações trazem vulnerabilidades antigas. Um desenvolvedor cria um novo microsserviço com base em um modelo de projeto de 2020. O modelo inclui dependências mais antigas. A menos que seu gerenciamento de dependências seja excepcionalmente rigoroso, esse novo serviço pode ser lançado com o Log4j vulnerável, mesmo que sua organização tenha “corrigido” o Log4j há dois anos.
Atualizações de dependências podem reverter correções. Você atualiza uma biblioteca não relacionada, e ela traz uma versão mais antiga de uma de suas dependências, o que, por transição, faz com que uma versão vulnerável do Log4j volte a ser usada. Suas regras de resolução de dependências podem não ser rigorosas o suficiente para impedir isso, ou o algoritmo de resolução de conflitos de versão pode escolher a versão vulnerável por motivos de compatibilidade.
Aquisições e integrações trazem código externo. Sua empresa adquire outra empresa ou se integra ao sistema de um parceiro. De repente, você se torna responsável pela base de código deles, que talvez não tenha recebido a mesma atenção que a sua em relação à correção do Log4j.
TI paralela e implantações não oficiais contornam seus processos padrão. Uma equipe faz uma implantação às pressas, ignorando as verificações de segurança e os processos de aprovação habituais. Ou alguém executa um serviço “temporário” que acaba se tornando permanente. Essas implantações não autorizadas costumam conter vulnerabilidades que você pensava terem sido eliminadas.
Restauração de backup e recuperação de desastres podem trazer de volta versões vulneráveis. Você restaura um sistema a partir de um backup feito antes de o Log4Shell ser conhecido. Ou reconstrói um serviço a partir de artefatos de implantação arquivados. A menos que você esteja verificando especificamente a presença do Log4j nesses cenários de recuperação, pode estar colocando código vulnerável de volta em produção.

A questão fundamental é que a segurança de software não é um estado que se alcança — é um processo que se mantém. Estar “atualizado” não é um estado permanente. Isso exige vigilância contínua, novas verificações regulares e consciência constante do que realmente está em execução em comparação com o que você acredita que deveria estar em execução.

Avaliação de riscos no mundo real

Nem toda instância do Log4j representa o mesmo nível de risco. Compreender sua exposição real ajuda a priorizar as medidas corretivas de maneira inteligente, em vez de tratar tudo como uma crise igualmente urgente.

A exposição é o fator mais importante. Uma instância vulnerável do Log4j em um aplicativo web exposto à Internet que processa entradas não confiáveis de usuários representa um alto risco. Uma instância vulnerável do Log4j em uma tarefa interna de processamento em lote que lida apenas com dados estruturados provenientes de fontes confiáveis apresenta um risco menor. A vulnerabilidade é a mesma, mas a possibilidade prática de exploração é diferente.
A sensibilidade dos dados aumenta o risco. Sistemas que lidam com informações de pagamento, registros pessoais de saúde ou outros dados regulamentados enfrentam riscos maiores decorrentes das vulnerabilidades do Log4j. Uma violação de segurança não significa apenas um comprometimento técnico – significa violações de conformidade, responsabilidade legal e penalidades regulatórias.
O posicionamento na rede afeta a vulnerabilidade à exploração. As vulnerabilidades do Log4j em sistemas que só podem ser acessados a partir de redes internas são menos passíveis de exploração imediata do que aquelas expostas à internet pública. Isso não as torna seguras, mas altera o modelo de ameaça e a urgência da correção.
A disponibilidade de exploits influencia o prazo. Assim que exploits funcionais para uma vulnerabilidade específica do Log4j se tornam publicamente disponíveis e passam a ser usados ativamente por invasores, o prazo para uma correção segura diminui drasticamente. Vulnerabilidades anteriores, com ecossistemas de exploits já consolidados, são mais perigosas do que problemas recém-descobertos que ainda estão em fase de pesquisa.
Controles compensatórios reduzem o risco prático. Se instâncias vulneráveis do Log4j estiverem protegidas por firewalls de aplicativos web configurados para bloquear padrões de pesquisa JNDI, ou se ferramentas de proteção de aplicativos em tempo de execução estiverem monitorando tentativas de exploração, o risco prático é menor do que em implantações completamente desprotegidas. Essas medidas não substituem a aplicação de patches, mas afetam a avaliação do risco.

O objetivo da avaliação de riscos não é justificar a inércia. É ajudar você a alocar os recursos limitados destinados à correção de falhas nos pontos em que eles terão maior impacto sobre sua postura de segurança real.

Estratégias práticas de mitigação

Então, você identificou vulnerabilidades do Log4j em seu ambiente. Algumas são fáceis de corrigir, outras são complicadas. Veja a seguir como funciona uma mitigação realmente eficaz.

Primeiro, uma investigação abrangente

Não dá para consertar o que não se consegue encontrar. Invista em uma análise minuciosa antes de começar a aplicar remendos.

Utilize várias abordagens de verificação: análise de dependências do código-fonte, verificação de imagens de contêiner, análise binária de artefatos implantados e detecção em tempo de execução. Cada abordagem identifica aspectos diferentes. A verificação do código-fonte detecta dependências declaradas. A verificação de contêineres identifica vulnerabilidades na imagem base. A análise binária detecta dependências ocultas. A detecção em tempo de execução identifica o que está realmente carregado no ambiente de produção.

Não limite a verificação apenas à produção. Verifique os ambientes de desenvolvimento, os sistemas de compilação, os ambientes de teste e qualquer outro local onde o código seja executado. Um Log4j vulnerável no laptop de um desenvolvedor pode não representar um risco imediato para a produção, mas constitui uma dívida técnica e uma possível exposição futura.

Documente o que você descobrir com detalhes: quais sistemas, quais versões do Log4j, quais caminhos de código realmente utilizam a funcionalidade de registro de logs e como se apresenta a vulnerabilidade. Esse inventário se tornará seu plano de ação para a correção.

Priorizar com base no risco real

Corrija primeiro os casos de maior risco. Isso inclui sistemas conectados à Internet, aqueles que lidam com dados confidenciais e qualquer sistema com padrões conhecidos de exploração ativa.

Para sistemas de risco médio, implemente controles compensatórios enquanto planeja as medidas corretivas adequadas. Implemente regras de WAF, ative o monitoramento em tempo de execução, restrinja o acesso à rede e implemente camadas adicionais de autenticação. Essas medidas de mitigação lhe dão tempo para realizar as atualizações de forma adequada, em vez de fazê-las às pressas.

Para sistemas de menor risco, é possível adotar prazos mais flexíveis, mas não deixe que “menor risco” se transforme em “nunca corrigido”. Estabeleça prazos concretos e cumpra-os.

Atualize sempre que possível

A solução adequada para as vulnerabilidades do Log4j é atualizar para versões corrigidas. No caso do Log4j 2.x, isso significa migrar para, no mínimo, a versão 2.17.1, que corrige todas as principais vulnerabilidades descobertas até o início de 2022.

Teste as atualizações minuciosamente. Mudanças na versão do Log4j podem causar diferenças de comportamento, especialmente no que diz respeito à configuração e ao desempenho. Valide em ambientes de teste que reproduzam as condições de produção antes de implementar as atualizações.

Se não for possível atualizar o Log4j diretamente devido a restrições de dependências superiores, tente atualizar as dependências que incluem o Log4j. Às vezes, é necessário atualizar várias camadas da sua árvore de dependências para resolver o problema.

Migrar do Log4j 1.x

Se você ainda estiver usando o Log4j 1.x, está trabalhando com uma base de código sem suporte e sem manutenção. O passo certo é migrar para uma estrutura de registro de logs moderna – Log4j 2.x, Logback ou outra opção que receba manutenção.

Muitas vezes, essa é uma tarefa significativa. Os formatos de configuração são diferentes. As APIs mudaram. Pode ser necessário atualizar as dependências. Mas é um trabalho necessário que já deveria ter sido feito há anos e que não pode ser adiado indefinidamente.

Planeje a migração em fases. Comece pelos sistemas menos críticos para compreender os padrões e identificar problemas. Elabore documentação interna e guias de migração. Em seguida, avance sistematicamente pelos seus sistemas de produção.

Tratar componentes de fornecedores e de terceiros

No caso de softwares comerciais e componentes fornecidos por fornecedores, verifique os alertas de segurança e os cronogramas de atualização. Muitos fornecedores lançaram patches para o Log4j, mas não os aplicam automaticamente nas instalações dos clientes.

Se os fornecedores não tiverem aplicado as correções em seus softwares, leve o caso a um nível superior. Abra tickets de suporte, envolva seus gerentes de conta e deixe claro que isso é um impedimento para a continuidade do uso. Os fornecedores respondem à pressão dos clientes, especialmente quando ela vem de vários clientes ao mesmo tempo.

Para softwares de fornecedores essenciais que não podem ser atualizados, implemente isolamento de rede e controles de segurança adicionais. O fato de não ser possível aplicar patches no software não significa que não seja possível limitar sua exposição.

Quando a remediação chega a um impasse

Apesar de todos os esforços, algumas instâncias do Log4j resistem à correção. Você está lidando com sistemas legados sem suporte que não podem ser facilmente atualizados, softwares de fornecedores que não receberão patches ou aplicativos personalizados que exigiriam um trabalho extenso de adaptação para migrar para versões mais recentes do Log4j.

Nesses cenários, as opções de suporte de segurança estendido oferecem uma alternativa. Serviços como o da TuxCare Endless Lifecycle Support para Log4j da TuxCare podem fornecer patches de segurança para versões mais antigas e sem suporte do software — incluindo instâncias legadas do Log4j que não receberão atualizações oficiais.

Essa não é uma solução de longo prazo nem uma desculpa para evitar atualizações necessárias. Mas é uma saída pragmática para situações em que a correção imediata não é tecnicamente viável. Se você estiver obrigado a usar o Log4j 1.x em um aplicativo legado estagnado, cuja migração levaria dezoito meses, o suporte estendido pode manter essa instância protegida contra vulnerabilidades conhecidas enquanto você executa o plano de migração.

Pense nisso como uma forma de ganhar tempo sem assumir todo o risco de utilizar um software totalmente sem patches. Você ainda terá a responsabilidade de, eventualmente, modernizar esses sistemas, mas não será forçado a realizar migrações apressadas que possam causar novos problemas ou interrupções nos negócios.

O segredo é ser explícito quanto à estratégia. O suporte prolongado não substitui a correção adequada — é uma ponte que permite que você realize a correção em um prazo razoável, em vez de um prazo ditado pela crise.

Desenvolvendo práticas sustentáveis de segurança

A verdadeira lição do caso Log4j não diz respeito a essa biblioteca específica. Trata-se da natureza das dependências de software e da vigilância constante necessária para gerenciar a segurança em aplicativos modernos.

A disciplina de gerenciamento de dependências precisa ser uma prática fundamental de engenharia, e não algo em que se pense apenas quando surge uma crise. Isso significa auditorias regulares de dependências, varreduras automatizadas em pipelines de CI/CD, políticas sobre versões aceitáveis de dependências e processos para avaliar e atualizar dependências continuamente.
A verificação de segurança não pode ser uma atividade pontual. Vulnerabilidades são descobertas constantemente. Sua verificação precisa ser executada continuamente — no desenvolvimento, na CI/CD, na produção e em todos os ambientes intermediários. O que estava seguro ontem pode estar vulnerável hoje.
Gestão de riscos de fornecedores exige supervisão ativa. Acompanhe os softwares de terceiros que você utiliza, monitore os alertas de segurança dos fornecedores, avalie as práticas de segurança dos fornecedores antes da aquisição e estabeleça SLAs claros para atualizações de segurança nos contratos com os fornecedores.
Os processos de resposta a incidentes devem incluir vulnerabilidades de dependências como um cenário. Quando surgir a próxima vulnerabilidade do nível do Log4Shell – e haverá uma próxima –, com que rapidez você conseguirá identificar os sistemas afetados? Como você prioriza as medidas corretivas? Quem toma as decisões sobre o risco aceitável e os prazos?
Escolhas arquitetônicas podem limitar o impacto das vulnerabilidades. Microsserviços com dependências isoladas são mais fáceis de atualizar do que aplicativos monolíticos com árvores de dependências extensas. Aplicativos em contêineres com imagens recompiladas regularmente incorporam atualizações de segurança de forma mais natural do que máquinas virtuais em execução prolongada. A infraestrutura imutável reduz o tempo de exposição às vulnerabilidades.

Seu plano de ação

Se você está lendo isso e se perguntando se ainda há vulnerabilidades ocultas do Log4j em seu ambiente, veja o que fazer:

Realize varreduras abrangentes em todos os ambientes utilizando diversas abordagens de varredura. Não se limite a verificar apenas seus principais aplicativos — verifique também os sistemas de compilação, o software de fornecedores, as cargas de trabalho em contêineres e os sistemas legados.

Faça um inventário do que você encontrar com detalhes suficientes para avaliar os riscos e planejar as medidas corretivas. Não basta dizer apenas “encontrei o Log4j 2.14.1”, mas sim “encontrei em um serviço de API voltado para o cliente, que lida com o processamento de pagamentos e está exposto à internet”.

Estabeleça prioridades de forma rigorosa com base no risco real. Corrija imediatamente os problemas perigosos. Planeje medidas corretivas deliberadas para os casos de risco médio. Não ignore os casos de baixo risco, mas não deixe que eles atrapalhem o trabalho de alta prioridade.

Implemente controles compensatórios para tudo o que não puder ser corrigido imediatamente. Regras de WAF, segmentação de rede, monitoramento em tempo de execução — utilize todas as ferramentas disponíveis para reduzir a vulnerabilidade prática.

Em situações em que realmente não há saída, considere o suporte prolongado como uma estratégia de transição. Mas seja honesto sobre o que ele é e o que não é, e mantenha prazos claros para uma eventual solução definitiva.

A Verdade Inconfortável

O risco da vulnerabilidade do Log4j não é um problema que se resolve de uma vez por todas e depois se esquece. Trata-se de uma preocupação de segurança contínua que exige atenção constante, varreduras regulares e esforços contínuos de correção.

Os pontos cegos não vão desaparecer. As dependências continuarão ocultando versões vulneráveis em lugares inesperados. Os sistemas legados continuarão resistindo a atualizações fáceis. Novas vulnerabilidades do Log4j ainda podem ser descobertas. O trabalho nunca está realmente concluído.

Mas isso não é motivo para desespero ou paralisia. É um motivo para desenvolver práticas sustentáveis que tornem o gerenciamento desse tipo de risco algo rotineiro, e não excepcional. Equipes que tratam a segurança das dependências como um trabalho contínuo, em vez de crises periódicas, lidam com essas situações de maneira muito mais eficaz.

Você não precisa alcançar a perfeição. Você precisa manter a visibilidade, gerenciar os riscos de forma inteligente e continuar avançando. É assim que a segurança sustentável se concretiza na prática.

O pânico em torno do Log4Shell já passou há muito tempo. Mas a história da vulnerabilidade do Log4j continua. Certifique-se de continuar atento.

Para obter atualizações de segurança de longo prazo que garantam sua proteção muito além da data de fim de vida útil, confira Suporte de ciclo de vida ilimitado para o Log4j.

Resumo