CVE-2025-61884

SSRF (CWE-918) no componente Runtime UI do Oracle Configurator, dentro do Oracle E-Business Suite, explorável sem autenticação via HTTP. Por si só o impacto é 'apenas' confiscação de confidencialidade (o servidor faz requisições em nome do atacante), mas o mesmo mecanismo é o primeiro estágio documentado da cadeia pré-autenticada de RCE identificada como CVE-2025-61882, o que explica por que está no catálogo KEV da CISA com exploração ativa confirmada.

O componente Configurator expõe o servlet oracle.apps.cz.servlet.UiServlet no path /configurator/UiServlet, mapeado no web.xml da aplicação oacore. Quando a requisição chega com o parâmetro getUiType preenchido, o código faz XmlUtil.parseXmlString() sobre o valor recebido — ou seja, o corpo XML enviado pelo cliente é parseado sem autenticação prévia. Se o parâmetro redirectFromJsp não estiver definido como 'false' (ou ausente), o fluxo segue para createNew(), que processa o documento XML.

Dentro desse processamento, o elemento XML com atributo return_url é extraído via CZUiUtilities.resubXMLAndURLChars(XmlUtil.getReturnUrlParameter()) e atribuído ao objeto clientAdapter através de setReturnUrl(). Esse valor — totalmente controlado pelo atacante dentro do XML enviado — percorre uma sequência de chamadas do clientAdapter até chegar em postXmlMessage(), onde é instanciada uma CZURLConnection com essa URL e o método connect() efetivamente dispara a requisição HTTP de saída a partir do servidor Oracle EBS.

É um SSRF clássico: falta de validação/allowlist sobre o destino de uma URL fornecida em um campo de dados de negócio (return_url dentro de um blob XML de UI), que termina sendo usada como alvo de uma conexão HTTP originada pelo próprio backend. Não há verificação de que o destino pertence a um domínio confiável nem restrição contra endereços internos (RFC 1918, metadata endpoints, etc.) conforme documentado no código analisado.

O vetor é uma requisição HTTP direta ao endpoint /configurator/UiServlet com o parâmetro getUiType contendo um XML forjado cujo elemento return_url aponta para um destino controlado pelo atacante ou para um recurso interno da rede do EBS. Não é necessário login, sessão válida, nem interação do usuário (AV:N/AC:L/PR:N/UI:N) — apenas alcançar a porta HTTP/HTTPS onde o EBS está exposto. Isso torna a exploração trivial em termos de esforço técnico, o que casa com a classificação 'easily exploitable' da Oracle e com a existência de PoC pública e template Nuclei.

O resultado direto é o servidor Oracle Configurator fazendo requisições HTTP arbitrárias em nome do atacante: isso permite varredura/reconhecimento de serviços internos inacessíveis externamente, exfiltração de respostas de endpoints internos, e — o que mais preocupa — funciona como estágio de reconhecimento/pivotagem dentro de cadeias de exploração maiores. A análise técnica pública (watchtowr) reconstruiu este exato fluxo (UiServlet → getUiType → return_url → CZURLConnection.connect()) como o Stage 1 de uma cadeia de pelo menos cinco falhas encadeadas que culmina em RCE pré-autenticado, catalogada separadamente como CVE-2025-61882.

O ingresso no KEV da CISA em 20/10/2025, com prazo de remediação até 10/11/2025, confirma exploração ativa in-the-wild associada a essa onda de ataques contra Oracle E-Business Suite iniciada em outubro de 2025. Não há confirmação pública de que a SSRF isolada (sem o restante da cadeia) tenha sido usada de forma independente para exfiltração — o registro trata o SSRF como componente do problema maior, mas a Oracle e a CISA a tratam como CVE distinta por afetar isoladamente a confidencialidade.

A Oracle publicou um Security Alert Advisory específico para esta CVE (alert-cve-2025-61884.html) cobrindo as versões 12.2.3 a 12.2.14 do E-Business Suite; a orientação primária é aplicar o patch correspondente distribuído junto a esse alerta. Não localizamos nas fontes disponíveis o número exato do patch/RUP a aplicar por release — consulte o advisory oficial da Oracle para o identificador de patch específico da sua versão antes de considerar o ambiente corrigido.

Se o patch não puder ser aplicado imediatamente, controles compensatórios reais incluem: restringir o acesso de rede ao path /configurator/UiServlet apenas a origens confiáveis (o endpoint não deveria estar exposto sem controle a redes não confiáveis, dado que é pré-autenticado); e, onde suportado por proxy reverso ou WAF, bloquear requisições cujo corpo XML no parâmetro getUiType contenha elementos return_url apontando para hosts fora de uma allowlist de destinos legítimos. Se o módulo Configurator Runtime UI não é usado pela organização, avaliar a remoção/desativação do componente como mitigação de maior custo, mas mais definitiva.

O que não mitiga: rotação de credenciais ou reforço de autenticação não tem efeito, já que a falha é pré-autenticada por desenho — o problema está na ausência de validação do destino da URL, não em controle de acesso a uma sessão.

Nos logs de acesso HTTP do servidor de aplicação EBS, procurar requisições para /configurator/UiServlet com o parâmetro getUiType contendo um payload XML e, dentro dele, um elemento return_url apontando para domínios ou IPs fora do ambiente legítimo (especialmente endereços externos ou faixas internas sensíveis que não deveriam receber tráfego originado pelo próprio EBS). No lado de rede, monitorar conexões de saída não usuais originadas pelo host do Configurator para destinos externos — esse é o sinal mais direto de que a SSRF foi acionada com sucesso, já que o próprio servidor passa a atuar como cliente HTTP.

Não há um indicador de comprometimento único e confiável isolado, porque o tráfego malicioso pode se misturar com uso legítimo do Configurator (que também manipula XML e URLs de retorno em fluxos normais); a distinção depende de correlacionar destino incomum do return_url com ausência de contexto de negócio esperado, e cruzar com os indicadores publicados para a cadeia CVE-2025-61882.