CVE-2020-2883

Falha de deserialização de dados não confiáveis no núcleo do Oracle WebLogic Server, explorável sem autenticação por qualquer atacante com acesso de rede aos protocolos T3 ou IIOP. Um payload malicioso enviado nessas conexões é desserializado pelo servidor e resulta em execução de código arbitrário no contexto do processo do WebLogic — ou seja, comprometimento total do servidor de aplicação. Está no catálogo KEV da CISA (adicionada em 2025, muito depois da divulgação original), o que confirma exploração ativa contínua mesmo anos após o patch existir.

A CVE-2020-2883 cobre pelo menos duas cadeias de gadget distintas documentadas pela ZDI sob o mesmo identificador. A primeira (ZDI-20-504) está no tratamento do próprio protocolo T3: dados manipulados numa mensagem T3 disparam a deserialização de objetos Java não confiáveis antes de qualquer verificação de identidade ou payload. A segunda (ZDI-20-570) está na biblioteca Oracle Coherence embutida no WebLogic, onde a ausência de validação de dados fornecidos pelo usuário permite a mesma classe de falha — deserialização insegura (CWE-502) — mas alcançada via IIOP em vez de T3.

O vetor é de rede pura: o atacante não precisa de credenciais, interação do usuário, nem privilégios prévios (PR:N, UI:N, AC:L no vetor CVSS). Basta alcançar a porta onde o WebLogic escuta T3 e/ou IIOP — por padrão a mesma porta usada para HTTP administrativo em muitas instalações — e enviar um objeto serializado malicioso que aciona uma cadeia de gadgets já conhecida no classpath do servidor (bibliotecas padrão do WebLogic/Coherence), resultando em execução de código no contexto do processo do servidor de aplicação.

A correção oficial veio no Critical Patch Update de abril de 2020 da Oracle (cpuapr2020), que se aplica às linhas suportadas 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 e 12.2.1.4.0. A Oracle não publica um número de versão pós-patch isolado para WebLogic — a correção é distribuída como patch dentro do CPU e deve ser aplicada via Opatch/instalador sobre a versão de base já instalada; consulte o advisory oficial para o patch ID exato da sua combinação de versão/plataforma.

Quando o patch não pode ser aplicado imediatamente, o paliativo real é bloquear o vetor de rede: desabilitar o protocolo T3 nos canais de rede do WebLogic (quando a aplicação não depende de RMI/T3 para clientes legítimos) e restringir/bloquear IIOP, além de isolar a porta administrativa e as portas de listen de rede não confiável via firewall ou segmentação. Esses controles reduzem a superfície mas não corrigem a falha — qualquer host que ainda alcance T3/IIOP continua explorável.

Não funciona como mitigação apenas confiar em filtros de deserialização de versões anteriores do WebLogic: a família de CVEs de deserialização T3 do WebLogic historicamente inclui bypasses sucessivos de blacklists de classes aplicadas em patches anteriores, e essa CVE é tratada pela comunidade como mais um bypass nessa linha — reforçando que bloqueio de rede é a defesa mais confiável na ausência do patch.

Monitorar tráfego nas portas de T3 e IIOP do WebLogic por conexões originadas de fora da rede de administração esperada, e por payloads com cabeçalho de serialização Java (bytes 0xAC 0xED no início do stream) vindos de IPs não confiáveis. Logs do WebLogic mostrando exceções de deserialização, ClassNotFoundException incomuns, ou reinícios/crashes inexplicados do servidor após conexões T3/IIOP são indícios de tentativa de exploração — mas como a exploração busca execução de código silenciosa, a ausência desses sinais não garante que o servidor não foi comprometido; presença de módulo Metasploit e PoC pública tornam scans de massa contra portas WebLogic expostas um cenário realista de detecção via IDS/NIDS com assinaturas para os padrões conhecidos de exploit T3.