CVE-2025-61757: execução remota de código de pré-autenticação no Oracle Identity Manager (REST WebServices)

O Oracle Identity Manager (OIM) é o tipo de sistema que você só percebe quando ele quebra. Ele provisiona identidades, gerencia direitos, emite ou faz a intermediação de acesso e, muitas vezes, está à frente de todos os aplicativos corporativos importantes. Quando uma vulnerabilidade chega ao OIM, raramente é "apenas mais um CVE". O CVE-2025-61757 é um exemplo crítico: um RCE não autenticado e alcançável pela rede no componente REST WebServices da OIM que pode levar ao controle total da camada de identidade. A NVD resume isso de forma clara: as versões compatíveis afetadas são 12.2.1.4.0 e 14.1.2.1.0A exploração requer sem autenticação, ocorre em HTTPe produz compromisso de alto impacto confidencialidade, integridade e disponibilidade, com um Pontuação CVSS 3.1 de 9,8 (Crítico). (NVD)

O que faz com que este CVE mereça uma leitura mais profunda, de nível de engenheiro, não é apenas sua pontuação, mas onde ela vive. As plataformas de identidade são a raiz de confiança das empresas modernas. Um invasor remoto que executa um código na OIM está a um passo de forjar identidades, adulterar atribuições de funções ou entrar em camadas adjacentes de middleware e aplicativos. Em outras palavras, O CVE-2025-61757 é um primitivo de sequestro de identidadeNão é um bug de aplicativo restrito.

A análise pública mais citada: por que essa cadeia funciona

Entre os artigos disponíveis publicamente, a postagem de pesquisa da Searchlight Cyber ("Breaking Oracle's Identity Manager: Pre-Auth RCE") é atualmente a análise detalhada e mais referenciada para o CVE-2025-61757, compartilhada pela SANS e outros rastreadores. (Searchlight Cyber) Sua alegação principal é que a vulnerabilidade é uma corrente de dois estágios:

1. a desvio de pré-autenticação em um filtro de segurança Java centralizado que protege a superfície de gerenciamento REST, e
2. abuso de um função de gerenciamento administrativo/script de alto privilégio exposta por essas APIs RESTculminando na execução remota de código. (Searchlight Cyber)

A mecânica exata da carga útil não é o que importa para os defensores (e não deve ser repetida fora de um laboratório autorizado). O que importa é o padrão: um clássico "filtro central + lista de permissões frágil" em que a autenticação é imposta pela correspondência de URIs de solicitação com uma lista branca permissiva. Em aplicativos Java corporativos antigos, isso é comum; em termos de segurança, é uma arma recorrente. Se o seu controle de acesso depende de correspondência de string ou regex em regras complexas de análise de URI, você está apostando que todos O componente upstream normaliza os caminhos da mesma forma. Essa aposta tende a ser perdida.

Uma maneira segura de capturar a forma da causa-raiz é examinar uma versão abstraída da lógica:

// Pseudocódigo que ilustra o antipadrão (não o código do produto)
se (request.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) {
    chain.doFilter(request, response); // ignora a autenticação
} else {
    enforceAuthentication();
}

Quando os invasores conseguem contornar o portão de autenticação, qualquer endpoint de administrador avançado se torna um trampolim de execução em potencial. A principal conclusão do Searchlight não é "esse endpoint específico é perigoso", mas "As superfícies de administração REST dentro dos produtos IAM geralmente incluem compilação de scripts, gerenciamento de conectores ou ganchos de fluxo de trabalho com confiança implícita." Quando eles são expostos sem autenticação, você obtém RCE por design, não por acidente. (Searchlight Cyber)

A lição mais ampla de engenharia é útil além desse CVE: filtros centralizados com listas de permissões são uma classe de vulnerabilidade estrutural. Se estiver fazendo uma revisão de código em seus próprios serviços Java (ou auditando o middleware do fornecedor), trate a "autenticação central da lista de permissões" como um cheiro que merece um teste contraditório.

Versões afetadas e contexto do patch

A Oracle corrigiu o CVE-2025-61757 no Atualização crítica de patches de outubro de 2025 (CPU), lançado em 2025-10-21. (Oráculo) As versões afetadas com suporte mencionadas em vários rastreadores são:

Isso se alinha com o NVD, o banco de dados de vulnerabilidade do Wiz e a descrição de exposição do runZero. (NVD)

Um ponto operacional sutil, mas importante: As CPUs Oracle são trimestrais. As empresas que não têm um sistema rígido de entrada e implementação de CPU tendem a acumular "dívidas de patches" em pilhas de identidade e middleware porque são vistas como sistemas estáveis e de baixa mudança. O CVE-2025-61757 quebra essa suposição. Não é um bug que você pode deixar para o "próximo trimestre" se o seu plano de gerenciamento REST puder ser acessado por redes não confiáveis.

Realidade da superfície de ataque: por que esse CVE será verificado rapidamente

Mesmo sem discutir os detalhes da exploração, a forma do vetor CVSS indica por que os agentes de ameaças automatizadas se importam. O NVD e o Wiz o listam como:

• AV:N (rede acessível),
• AC:L (baixa complexidade),
• PR:N/UI:N (sem privilégios, sem interação com o usuário),
• C:H/I:H/A:H (impacto total). (NVD)

Essa combinação é o "sinal verde" para os scanners de commodities. No momento em que um PoC chega aos canais públicos, ele se torna um impressão digital de uma solicitação + cadeia de acompanhamento em botnets. Os servidores de identidade que são expostos discretamente por meio de balanceadores de carga mal configurados, regras NAT herdadas ou falhas de suporte remoto do fornecedor tendem a aparecer rapidamente nessas varreduras.

Você também tem um problema de contexto maior: O middleware da Oracle tem sido um alvo de alto valor em 2025, com vários bugs críticos não autenticados em produtos adjacentes (WebLogic, EBS, módulos de marketing) que se transformaram em campanhas ativas. A análise da CPU da Qualys em outubro destaca explicitamente os pontos críticos do Fusion Middleware como um cluster de alto risco. (Qualys) Isso aumenta a probabilidade de os invasores encadearem o comprometimento do OIM em operações patrimoniais mais amplas da Oracle.

Verificação defensiva sem transformar a detecção em exploração

Para a maioria das equipes, a primeira tarefa é simples: identificar a exposiçãoNão imite os invasores. Um fluxo de trabalho seguro e autorizado tem a seguinte aparência:

1. Inventário de versões do OIM em todos os ambientes e comparar com as linhas afetadas.
2. Restringir o acesso ao gerenciamento imediatamente (ACLs de rede, gate de VPN, ZTNA), mesmo antes das janelas de patches.
3. Caçar anomalias de administração REST nos registros de acesso: URIs de solicitação de alta entropia, rajadas de IPs desconhecidos ou pontos de extremidade de classe de administrador invocados em horários não alterados.

Para manter isso concreto, aqui está um combinador de versão somente defensivo que você pode mesclar em seus trabalhos de inventário de ativos:

# Defensive-only: corresponder versões descobertas do OIM ao conjunto afetado
da versão de importação do pacote

AFFECTED = [
    ("12.2.1.4.0", "12.2.1.4.0"),
    ("14.1.2.1.0", "14.1.2.1.0"),
]

def is_affected(v: str) -> bool:
    v = version.parse(v)
    return any(version.parse(lo) <= v <= version.parse(hi) for lo, hi in AFFECTED)

for v in ["12.2.1.4.0", "14.1.2.1.0", "14.1.2.2.0"]:
    print(v, "affected?" , is_affected(v))

Se não for possível extrair versões de forma confiável dos banners, priorize os dados internos do CMDB, os manifestos de pacotes do host ou os metadados da página inicial do Oracle. O segredo é evitar "sondar" seu nível de identidade de forma a aumentar o risco operacional.

Caça pós-patch: como seria o compromisso

A cadeia do Searchlight implica uma classe específica de comportamentos que você deve observar, mesmo após a atualização:

• Endpoints de gerenciamento REST sendo atingidos por fontes desconhecidasespecialmente de intervalos de IP públicos.
• Verbos de gerenciamento usados fora das janelas de mudançaparticularmente qualquer coisa que compile, faça upload ou altere fluxos de trabalho/conectores.
• Novas contas de serviço ou mudanças de função que não se alinham com as operações com tíquetes.

O RunZero e o Wiz aconselham a análise dos registros de atividades REST incomuns e a redução da acessibilidade do gerenciamento como parte da proteção, não apenas da correção. (RunZero)

O motivo para levar isso a sério após a aplicação de patches é que os bugs de RCE pré-auth são frequentemente explorados antes de divulgação. Se a camada REST foi exposta, presuma que ela pode ter sido tocada.

Mitigação que realmente reduz o risco

A orientação oficial da Oracle é aplicar as atualizações de CPU de outubro de 2025, que incluem a correção. (Oráculo) Do ponto de vista da engenharia, as ações de redução de risco são as seguintes:

• Patch imediatamente em qualquer versão compatível afetada.
• Remover a acessibilidade pública de planos de gerenciamento REST. As APIs de administração de identidade não devem estar voltadas para a Internet.
• Faça o rodízio de credenciais privilegiadas e exigir MFA sempre que operacionalmente possível.
• Linha de base e monitoramento Desvio de configuração do OIM (funções, conectores, fluxos de trabalho).
• Segmentar a camada de IAM de modo que, mesmo que o MIO esteja comprometido, o movimento lateral é retardado.

Nada disso é novidade, mas o CVE-2025-61757 é um estudo de caso que mostra por que o fortalecimento do IAM não pode ser tratado como "definir e esquecer". O middleware de identidade agora está firmemente no mesmo nível de prioridade de ameaças que as VPNs de borda e os gateways da Web.

Por que esse CVE é importante para os engenheiros de segurança de IA

Se você estiver trabalhando na interseção de sistemas de IA e segurança, a OIM é uma dependência upstream cada vez mais relevante. Seus clusters de serviço de modelo, plataformas de dados, CI/CD e até mesmo ferramentas internas de LLM geralmente herdam decisões de acesso do IAM corporativo. A aquisição pré-autorizada da infraestrutura de identidade é a forma como os invasores "legitimam" o comprometimento posterior da pilha de IA: eles não precisam destruir um servidor de modelos se puderem extrair a identidade que tem permissão para alterá-lo.

De uma perspectiva de IA defensiva, o CVE-2025-61757 é um lembrete para tratar a telemetria de identidade como um sinal de primeira classe em seus pipelines de detecção. Se estiver criando ferramentas de segurança agêntica, a "automação de alto impacto" mais realista não é a geração de exploits especulativos, mas sim o inventário de alta fidelidade, a modelagem de raio de explosão e a orquestração de patches para propriedades de identidade e middleware.

Uma observação discreta sobre automação (quando for o caso)

Em grandes propriedades Oracle, a dispersão de versões é real: desenvolvimento, controle de qualidade, recuperação de desastres e locatários legados costumam ter uma defasagem de alguns trimestres. As plataformas de automação com humanos no circuito, como a Penligent, podem ajudar com Inventário de versões OIM em toda a frota, validação de exposição e rastreamento de correçãosem levar as equipes a uma exploração arriscada. Quando a vulnerabilidade é crítica em termos de identidade, a velocidade e a precisão do ciclo "encontrar → priorizar → corrigir" são mais importantes do que qualquer outra coisa.

Fechamento

O CVE-2025-61757 não é apenas um bug; é uma rota de comprometimento de camada de identidade de alta alavancagem nascida de um conhecido antipadrão Java corporativo. A solicitação imediata é óbvia: corrigir as versões afetadas do OIM e bloquear o acesso ao gerenciamento REST. A tarefa de longo prazo é maior: Se o plano de controle do IAM estiver acessível, ele será atacado, e os filtros centralizados da lista de permissões serão ignorados. Trate essa CVE como uma função forçada para auditar como seus sistemas de identidade são expostos, autenticados e monitorados.