Log4j2: Falha Ignora Filtro e Ainda Não Tem CVE

Neste artigo do Blog Dolutech, vamos analisar uma descoberta que fez muita gente na comunidade Java segurar a respiração por alguns dias: um possível bypass no mecanismo de desserialização segura do Apache Log4j2, a mesma biblioteca que ficou mundialmente conhecida em 2021 por causa do Log4Shell. A boa notícia é que, dessa vez, o cenário é bem diferente. A má notícia é que “diferente” não significa “sem risco algum”, e é justamente essa nuance que queremos destrinchar aqui na Dolutech.

O caso começou a circular publicamente em 24 de agosto de 2026, quando um relatório atribuído à empresa de segurança U-Sec (Wujie Security) descreveu, através do issue #4255 no repositório oficial do Log4j2 no GitHub, uma forma de contornar o filtro de desserialização da biblioteca e alcançar execução remota de código. Em poucos dias, o assunto se espalhou por veículos especializados, gerou debate sobre a real gravidade do problema e culminou na publicação de uma prova de conceito funcional e de um template de detecção para a ferramenta Nuclei. Nós, da Dolutech, decidimos separar o que é fato confirmado do que ainda é motivo de discussão técnica.

O Que Está Acontecendo: A Descoberta do Issue #4255

O relatório original, publicado por um usuário identificado como “dinosn” e atribuído à U-Sec, afirma que aplicações que recebem eventos de log serializados do Log4j (LogEvent) através de um receptor de rede, como um socket TCP, podem ser exploradas remotamente. Segundo a descrição técnica, versões do log4j-api entre 2.11.0 e 2.26.1 e do log4j-core entre 2.8.0 e 2.26.1 seriam afetadas. A classificação usada é CWE-502, que trata de desserialização de dados não confiáveis, uma categoria de vulnerabilidade clássica no ecossistema Java.

Um laboratório de reprodução público demonstrou o problema rodando o Log4j 2.26.1 sobre o JDK 17, em um contêiner Docker, e mostrou que uma cadeia de gadgets baseada na biblioteca Commons Collections 3.2.1 conseguia executar código sem exigir que o atacante enviasse uma classe própria para a máquina da vítima. Isso é relevante porque reduz a complexidade prática de um ataque, desde que as condições de exposição estejam presentes.

É importante frisar, seguindo nosso compromisso de transparência aqui na Dolutech: até o momento, nenhum CVE foi atribuído a essa questão e nenhuma correção oficial foi lançada pela equipe do Apache Log4j. Portanto, tratamos essa falha como CVE pendente, não como uma vulnerabilidade formalmente catalogada, e vamos explicar exatamente por quê ao longo do artigo.

Anatomia Técnica do Bypass

Para entender o problema, é preciso conhecer três peças que se encaixam de um jeito que ninguém havia detalhado publicamente até agora.

O Papel do FilteredObjectInputStream

O Log4j2 inclui uma classe chamada FilteredObjectInputStream (FOIS), pensada como uma camada de defesa em profundidade contra desserialização insegura. Ela sobrescreve o método resolveClass() do ObjectInputStream padrão do Java e só permite a instanciação de classes presentes em uma lista de permissões, definida internamente na classe SerializationUtil, na constante REQUIRED_JAVA_CLASSES. Essa lista inclui pacotes como java.lang, java.util e algumas classes específicas do próprio Log4j.

O Buraco Escondido em MarshalledObject

O problema é que essa mesma lista de permissões inclui a classe java.rmi.MarshalledObject, um contêiner nativo do Java que serve para armazenar outro objeto serializado dentro de um array de bytes opaco (objBytes). O FOIS consegue filtrar a classe externa, o próprio MarshalledObject, mas nunca inspeciona o conteúdo desse array de bytes. Quando o código chama o método MarshalledObject.get() para recuperar o objeto interno, o Java cria, internamente, um novo ObjectInputStream padrão, sem qualquer filtro aplicado. Ou seja, qualquer payload malicioso escondido dentro do array de bytes passa despercebido pelo filtro de segurança e é desserializado livremente.

A Cadeia de Execução via LogEventProxy

A ponte entre esse comportamento genérico do Java e o Log4j2 especificamente é a classe Log4jLogEvent$LogEventProxy, responsável por representar um evento de log de forma serializável. Pesquisadores identificaram que esse objeto pode carregar um MarshalledObject como parte de sua estrutura interna, e que o processo de leitura acaba chamando o get() sem filtro adicional. Na prática, isso cria um caminho onde um evento de log serializado, recebido por um serviço de rede baseado em FOIS, pode entregar um gadget chain completo e disparar execução de código arbitrário.

Isso É o Novo Log4Shell?

A resposta curta é não, e a diferença de alcance é enorme. O Log4Shell (CVE-2021-44228) explorava pesquisas JNDI dentro de mensagens de log comuns, o que significava que bastava uma aplicação registrar, em log, uma string controlada pelo atacante, algo tão simples quanto um cabeçalho HTTP ou um campo de formulário, para desencadear o ataque. Isso deu ao Log4Shell um alcance praticamente universal, atingindo qualquer sistema que usasse a biblioteca de forma padrão.

Esse bypass de 2026 exige um cenário muito mais específico: a aplicação precisa expor, deliberadamente, um receptor de rede que aceite eventos de log serializados no formato Java (LogEvent), processando-os através do FilteredObjectInputStream, e ainda precisa ter, na classpath, uma cadeia de gadgets utilizável. Esse tipo de receptor baseado em socket TCP foi removido do log4j-core como recurso padrão a partir da versão 2.9.0, o que significa que nenhuma instalação atual, com configuração padrão, expõe esse caminho de ataque. Só está em risco quem manteve, deliberadamente, um componente legado de recepção de eventos serializados, algo mais comum em integrações antigas, pontes de log centralizado personalizadas ou sistemas migrados de versões muito antigas do Log4j.

A Resposta da Apache: “Isso Não É Uma Vulnerabilidade”

Aqui está a parte mais interessante da história, e também a mais reveladora sobre como funciona a governança de projetos open source críticos como o Log4j.

A Discussão #4168 de Julho

Em 1º de julho de 2026, quase dois meses antes do relatório da U-Sec viralizar, o mantenedor do Log4j Piotr P. Karwasz já havia aberto uma discussão pública no GitHub, listando cinco descobertas de desserialização encontradas durante uma auditoria interna do projeto. A primeira delas, marcada como prioridade “alta” para fins de hardening, descrevia exatamente o mesmo mecanismo: o campo marshalledMessage, a cadeia de chamadas readResolve() → message() → marshalledMessage.get(), e o fato de que o stream privado do MarshalledObject não herda o filtro por stream do Log4j.

Karwasz foi direto ao afirmar que esses achados “não são problemas de segurança” segundo o modelo de ameaças do próprio projeto. A justificativa é consistente: o Log4j não desserializa dados como parte de sua operação normal, e filtrar um stream por pacote de classes nunca foi tratado como garantia suficiente para tornar a desserialização seguramente confiável, apenas como uma camada adicional de mitigação.

Por Que Não Há CVE

A Sonatype, empresa que monitora a cadeia de suprimentos de software, publicou um aviso próprio, identificado como sonatype-2026-006746, para ajudar organizações a verificar se suas aplicações dependem desse padrão de desserialização considerado, pelos próprios mantenedores do Log4j, como inerentemente inseguro. Esse aviso, no entanto, explicitamente não classifica o comportamento como uma vulnerabilidade no Log4j em si. A conclusão da comunidade de segurança que analisou o caso é que o relatório de agosto, na prática, reapresentou como “zero-day crítico” algo que o próprio projeto já havia triado, documentado e classificado como item de hardening não crítico dois meses antes. A conta que originalmente publicou o relatório de agosto foi posteriormente removida, e o issue #4255 segue sem resposta oficial dos mantenedores, mantendo a etiqueta de espera por revisão.

Para nós, da Dolutech, esse episódio reforça uma lição editorial que sempre repetimos: velocidade de viralização não é sinônimo de gravidade técnica, e é fundamental cruzar qualquer relatório de “zero-day” com a documentação oficial do projeto antes de tratá-lo como emergência.

Exploração Pública: PoC e Template Nuclei Já Circulam

Apesar da falta de CVE e de patch, o aspecto prático não pode ser ignorado. Em 26 de agosto de 2026, o pesquisador de segurança Joan Bono publicou uma prova de conceito funcional para o issue #4255, junto com um template de detecção para a ferramenta Nuclei, amplamente usada por equipes de red team e bug bounty para varreduras automatizadas. O repositório documenta a mesma cadeia técnica descrita acima: a lista de permissões do FilteredObjectInputStream mantendo java.rmi.MarshalledObject como classe autorizada, e o array de bytes interno nunca sendo inspecionado.

Isso significa que, mesmo sem uma correção oficial, qualquer equipe ofensiva ou pesquisador com conhecimento básico de Java consegue montar uma varredura para identificar aplicações potencialmente expostas. Do lado defensivo, o mesmo template de detecção pode e deve ser usado por equipes de segurança para auditar seu próprio parque de aplicações Java antes que outra pessoa o faça primeiro.

Mapeamento MITRE ATT&CK

Para equipes de Blue Team e de resposta a incidentes, mapear esse comportamento contra o framework MITRE ATT&CK ajuda a priorizar detecção e resposta:

Tática	Técnica	ID	Como se Aplica
Reconhecimento	Active Scanning	T1595	Varredura de rede em busca de receptores de eventos de log expostos, usando templates como o do Nuclei
Acesso Inicial	Exploit Public-Facing Application	T1190	Envio de um objeto MarshalledObject malicioso a um receptor de LogEvent baseado em FOIS e exposto à rede
Execução	Command and Scripting Interpreter	T1059	Execução de comandos arbitrários após a desserialização bem-sucedida de uma cadeia de gadgets
Evasão de Defesa	Obfuscated Files or Information	T1027	Payload oculto dentro do array de bytes opaco do MarshalledObject, invisível para a lista de permissões
Comando e Controle	Application Layer Protocol	T1071	Comunicação do payload serializado sobre o protocolo de objetos Java, transportado via TCP
Impacto	Endpoint Denial of Service	T1499	Uso de grafos de objetos volumosos (“bombas” de desserialização) para esgotar recursos, mesmo sem uma cadeia de gadgets disponível

Indicadores de Comprometimento (IoC)

Nota de transparência da Dolutech: até a publicação deste artigo, não há relatos confirmados de exploração ativa em ambientes de produção, apenas provas de conceito e ferramentas de detecção publicadas por pesquisadores. Os indicadores abaixo servem para caça proativa de ameaças (threat hunting) e auditoria preventiva, não como confirmação de campanhas em andamento.

Indicador	Tipo	Confiança / Origem
Template log4j2-4255-marshalledobject-deser.yaml (Nuclei)	Assinatura de detecção	PoC pública, uso recomendado para autoauditoria
Portas TCP não documentadas expondo SocketServer/SocketNode legado do Log4j	Configuração de rede exposta	Requer auditoria manual, não há porta padrão oficial
Presença da cadeia de gadgets Commons Collections 3.2.1 na classpath	Artefato de dependência	Confirmado em laboratório de reprodução (JDK 17 / Docker)
Streams com cabeçalho de serialização Java (bytes AC ED 00 05) recebidos em portas não catalogadas	Tráfego de rede	Indicador genérico de desserialização Java, não exclusivo deste caso

Mitigação e Hardening

Mesmo sem CVE nem patch oficial, existem passos concretos que equipes de infraestrutura e segurança podem tomar agora.

Identifique Receptores Expostos

O primeiro passo é descobrir se a sua organização ainda mantém algum componente legado que desserializa eventos de log via rede. Um bom ponto de partida é auditar o código-fonte e as configurações em busca de classes associadas a essa funcionalidade:

# Busca por uso de receptores de socket legados do Log4j em código-fonte e configs
grep -RniE "SocketServer|SocketNode|SocketAppender|ObjectInputStream" \
  --include="*.java" --include="*.xml" --include="*.properties" /caminho/do/projeto

# Lista dependências log4j-core presentes no classpath de aplicações Maven
find / -name "log4j-core-*.jar" 2>/dev/null

Em ambientes Windows com aplicações Java, o mesmo tipo de varredura pode ser feito com PowerShell:

# Procura por referências a receptores de socket legados em arquivos de configuração
Get-ChildItem -Path C:\ -Include *.xml,*.properties -Recurse -ErrorAction SilentlyContinue |
    Select-String -Pattern "SocketServer|SocketNode|SocketAppender"

# Lista arquivos log4j-core presentes no sistema
Get-ChildItem -Path C:\ -Filter "log4j-core-*.jar" -Recurse -ErrorAction SilentlyContinue

Aplique um Filtro Global na JVM (JEP 290)

Como a lista de permissões do próprio Log4j não cobre o conteúdo interno do MarshalledObject, a defesa mais eficaz é um filtro de serialização em nível de JVM, definido via JEP 290, que se aplica a qualquer ObjectInputStream criado no processo, inclusive o criado internamente pelo MarshalledObject.get():

# Exemplo de flag JVM para restringir globalmente quais classes podem ser desserializadas
# Ajuste a lista de classes permitidas conforme as necessidades reais da sua aplicação
-Djdk.serialFilter="java.rmi.MarshalledObject;java.lang.*;java.util.*;maxdepth=10;maxarray=1000;!*"

sole ou Desative Receptores Legados

Se a sua aplicação realmente depende de um receptor de eventos de log serializados, o ideal é isolá-lo em uma rede segmentada, sem exposição direta à internet, e restringir o acesso via firewall apenas a hosts confiáveis conhecidos. Sempre que possível, o caminho recomendado a médio prazo é migrar essa integração para um formato estruturado e não baseado em serialização nativa do Java, como JSON ou Protobuf, eliminando de vez essa classe de risco.

Use o Template Nuclei Para Autoauditoria

Equipes de segurança ofensiva interna (ou parceiros de pentest) podem usar o mesmo template público de detecção para validar, de forma controlada e autorizada, se algum ativo da organização está exposto:

# Varredura de um único host
nuclei -t log4j2-4255-marshalledobject-deser.yaml -u 10.0.0.5:4560

# Varredura de uma lista de alvos autorizados
nuclei -t log4j2-4255-marshalledobject-deser.yaml -l alvos_autorizados.txt

Reforçamos aqui, na Dolutech, que esse tipo de varredura só deve ser executado em ativos que você tem autorização explícita para testar.

Conformidade Regulatória

Mesmo tratando-se de uma falha ainda sem CVE, organizações que operam sob regimes regulatórios de cibersegurança precisam considerar o impacto de qualquer vetor de execução remota de código em seus processos de gestão de risco.

União Europeia: NIS2, DORA, GDPR e CNCS/CERT.PT

Sob a diretiva NIS2, entidades essenciais e importantes na União Europeia têm obrigação de gestão de risco de cadeia de suprimentos de software, o que inclui avaliar dependências como o Log4j2 mesmo na ausência de um CVE formal, já que o critério legal é o risco material, não apenas a existência de um identificador oficial. Instituições financeiras sujeitas ao DORA (Digital Operational Resilience Act) devem incluir esse tipo de achado em seus testes de resiliência operacional digital, especialmente se mantiverem qualquer integração legada de logging centralizado. O GDPR/RGPD entra em cena caso uma eventual exploração leve à exposição de dados pessoais, exigindo avaliação de necessidade de notificação à autoridade competente. Em Portugal, o CNCS e o CERT.PT recomendam que organizações mantenham inventário atualizado de componentes de terceiros justamente para permitir esse tipo de resposta rápida diante de relatos como este.

Brasil: LGPD e ANPD

No Brasil, a Lei Geral de Proteção de Dados (LGPD) impõe às organizações o dever de adotar medidas técnicas razoáveis para proteger dados pessoais contra acessos não autorizados. Um vetor de desserialização insegura, mesmo restrito a cenários legados, deve constar do mapeamento de riscos de qualquer empresa que processe dados pessoais em aplicações Java com componentes de logging customizados. Em caso de incidente de segurança que resulte em risco relevante aos titulares de dados, a comunicação à Autoridade Nacional de Proteção de Dados (ANPD) segue sendo obrigatória, independentemente de a vulnerabilidade explorada possuir ou não um CVE formalmente atribuído.

Considerações Finais

Esse episódio do Log4j2 é um lembrete valioso sobre como a comunidade de segurança lida, às vezes de forma desalinhada, com descobertas técnicas legítimas. De um lado, temos um mecanismo real, verificável no código-fonte, que permite contornar uma camada de proteção; do outro, temos um projeto que já conhecia o problema, já o havia classificado como hardening não crítico, e que segue considerando a exploração dependente de um cenário de configuração pouco comum nos dias de hoje.

Aqui na Dolutech, nossa recomendação prática é simples: não entre em pânico, mas também não ignore o achado. Audite se sua organização mantém algum receptor legado de eventos serializados do Log4j, aplique o filtro de JVM recomendado como camada extra de defesa, e acompanhe o issue #4255 e a discussão #4168 para eventuais atualizações oficiais. Vamos continuar acompanhando esse caso e atualizamos este artigo caso um CVE seja formalmente atribuído ou uma correção oficial seja lançada pela equipe do Apache Log4j.