Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack

CVE-2021-45046 documenta que a correção da Apache para o Log4Shell original (CVE-2021-44228) na versão 2.15.0 foi incompleta: em configurações não-padrão de logging, ainda é possível acionar expansão de lookup JNDI a partir de dados do Thread Context Map (MDC), causando no mínimo negação de serviço e, em certos ambientes, execução remota de código. A própria Apache classificou o problema inicialmente como DoS moderado (CVSS 3.7); a nota da NVD usada aqui (9.0, com escopo alterado e impacto Alto em confidencialidade/integridade/disponibilidade) reflete o pior cenário possível, não o caso típico — a exploração depende de uma configuração específica de layout que a maioria dos deployments não usa.

O fix da 2.15.0 desabilitou a expansão de lookups apenas dentro do conteúdo da mensagem de log (a string passada ao logger). Ele não tocou na expansão de padrões dentro do PatternLayout em si. Se a configuração de logging usa PatternLayout com um Context Lookup (`$${ctx:algumaChave}`) ou com os conversores de Thread Context Map (`%X`, `%mdc`, `%MDC`), o valor armazenado no MDC ainda passa pelo motor de resolução de Lookups do Log4j antes de ser escrito — e esse motor continua reconhecendo e resolvendo `${jndi:...}`.

O MDC (Mapped Diagnostic Context) é preenchido pela própria aplicação, normalmente copiando dados de entrada (headers HTTP, parâmetros de request, IDs de sessão) para correlacionar logs. Isso significa que o atacante não precisa controlar a mensagem de log diretamente — precisa apenas que algum valor sob seu controle acabe em uma chave do MDC que a camada de layout está formatando.

A 2.15.0 já restringia lookups LDAP/JNDI a localhost por padrão, o que limita bastante o alcance de RCE remoto direto via este vetor específico. Mesmo assim, a resolução de expressão continua ocorrendo internamente, o que é suficiente para provocar exceções não tratadas e queda do processo (DoS), para causar vazamento de informação via lookups de ambiente/sistema, e, dependendo do ambiente (outros providers JNDI configurados, ausência da restrição a localhost em certos contextos), para RCE.

O pesquisador Moritz Bechler, em discussão pública na lista oss-security, confirmou o mecanismo: a expansão foi bloqueada apenas para o corpo da mensagem, não para o pattern do layout, e destacou que reproduzir o vetor via `%X`/`%mdc`/`%MDC` isoladamente não era trivial — o caminho mais claramente explorável era via `$${ctx:...}` no layout.

Pré-requisito central, e é a informação que a manchete '9.0 crítico' esconde: a aplicação vulnerável precisa (a) copiar dado controlado pelo atacante para o Thread Context Map e (b) ter uma configuração de log4j2.xml/properties com PatternLayout usando `$${ctx:...}`, `%X`, `%mdc` ou `%MDC`. Isso não é o padrão de fábrica do Log4j2 — é uma escolha explícita de configuração de logging, geralmente feita para correlacionar requisições (ex: logar um `loginId` ou `requestId` do usuário). Sem essa combinação de configuração + dado no MDC, o sistema não é explorável por esta CVE mesmo estando na versão 2.15.0.

Com essa combinação presente, o atacante injeta uma expressão JNDI (`${jndi:ldap://...}` ou similar) no campo que a aplicação grava no MDC. O impacto documentado com maior confiança pela própria Apache é negação de serviço: crash do processo. RCE remoto e vazamento de informação são possíveis dependendo do ambiente (se o Java runtime, o provider JNDI disponível ou a topologia de rede permitirem contornar a restrição a localhost imposta pela 2.15.0), e RCE local (com um segundo estágio já presente no classpath/sistema de arquivos) é considerado viável em todos os ambientes pela descrição oficial.

A CVE está no catálogo KEV da CISA, tem módulo Metasploit, template Nuclei e PoC pública, mas a maior parte da exploração massiva de dezembro de 2021 registrada na internet mirava o vetor original mais simples do CVE-2021-44228 (lookup direto na mensagem), que não exige configuração de MDC. Não há evidência nas fontes consultadas de campanha em massa distinta e específica para o vetor via MDC/PatternLayout desta CVE — o risco real concentra-se em aplicações com essa configuração de logging particular.

Atualizar para Log4j2 2.16.0 (Java 8 ou superior) ou 2.12.2 (backport para Java 7). Essas versões removem completamente o suporte a message lookup patterns e desabilitam JNDI por padrão, eliminando a classe de problema em vez de apenas restringir o alcance da rede.

Se a atualização não for possível de imediato, o paliativo real e eficaz em qualquer versão anterior à 2.16.0 (incluindo a 2.15.0) é remover a classe `JndiLookup` do jar do log4j-core: `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`. Isso elimina o mecanismo de lookup JNDI inteiro, independentemente de onde ele é invocado (mensagem ou layout), então cobre tanto CVE-2021-44228 quanto esta CVE. Custo: quebra qualquer uso legítimo de JNDI Lookup na configuração de logging, se houver.

Mito que circulou e não funciona contra esta CVE especificamente: definir a system property `log4j2.noFormatMsgLookups=true` (ou a variável de ambiente `LOG4J_FORMAT_MSG_NO_LOOKUPS=true`), usada como mitigação inicial do CVE-2021-44228. Essa flag só bloqueia a expansão de lookups no corpo da mensagem — não impede a expansão via PatternLayout/MDC explorada por CVE-2021-45046. Quem aplicou apenas essa flag e permaneceu na 2.15.0 continua exposto se usa `$${ctx:...}` ou `%X`/`%mdc`/`%MDC` no layout.

Como o vetor passa pelo Thread Context Map em vez da mensagem de log direta, assinaturas de WAF que procuram `${jndi:` apenas no corpo do payload de requisição podem não cobrir o caso: o valor malicioso pode estar em qualquer campo que a aplicação copie para o MDC (cookie, header customizado, parâmetro específico), o que exige conhecer quais campos a aplicação de fato grava no contexto de log. Sinal mais confiável: tráfego de saída do servidor de aplicação para LDAP/RMI/DNS (portas e protocolos incomuns para aquele processo) coincidindo com entradas anômalas em campos conhecidos de MDC, e exceções repetidas do Log4j nos próprios logs da aplicação indicando tentativas de resolução de lookup mal-sucedidas.

Se a configuração de logging da aplicação não usa PatternLayout com `$${ctx:...}`, `%X`, `%mdc` ou `%MDC`, não há superfície para esta CVE específica — vale confirmar isso na configuração antes de investir em detecção de tráfego.