CVE-2025-61757: Ejecución remota de código Pre-Auth en Oracle Identity Manager (REST WebServices)

Oracle Identity Manager (OIM) es el tipo de sistema que no se nota hasta que se rompe. Proporciona identidades, gestiona derechos, emite o intermedia el acceso y, a menudo, se encuentra en la fase previa de cualquier aplicación empresarial seria. Cuando una vulnerabilidad llega a OIM, rara vez es "una CVE más". CVE-2025-61757 es un ejemplo crítico: una RCE no autenticado, alcanzable por la red en el componente REST WebServices de OIM que puede llevar a la toma total del nivel de identidad. NVD lo resume claramente: las versiones soportadas afectadas son 12.2.1.4.0 y 14.1.2.1.0La explotación requiere sin autenticaciónse produce sobre HTTPy se obtiene compromiso de alto impacto de confidencialidad, integridad y disponibilidad, con un Puntuación CVSS 3.1 de 9,8 (Crítico). (NVD)

Lo que hace que este CVE merezca una lectura más profunda, de grado ingeniero, no es sólo su puntuación, sino que donde vive. Las plataformas de identidad son la raíz de la confianza de las empresas modernas. Un atacante remoto que ejecute código en OIM está a un paso de falsificar identidades, manipular la asignación de roles o pivotar en los niveles adyacentes de middleware y aplicaciones. Dicho de otro modo, CVE-2025-61757 es un primitivo de toma de identidadno es un error de la aplicación.

El análisis público más citado: por qué funciona esta cadena

Entre los escritos disponibles públicamente, el post de investigación de Searchlight Cyber ("Breaking Oracle's Identity Manager: Pre-Auth RCE") es actualmente el análisis más referenciado y detallado para CVE-2025-61757, del que se hacen eco SANS y otros rastreadores. (Searchlight Cyber) Su principal argumento es que la vulnerabilidad es una cadena de dos etapas:

1. a elusión de la preautenticación en un filtro de seguridad Java centralizado que protege la superficie de gestión REST, y
2. abuso de un función de gestión administrativa/de script de alto privilegio expuesta por esas API REST, culminando en la ejecución remota de código. (Searchlight Cyber)

La mecánica exacta de la carga útil no es lo que importa para los defensores (y no debería repetirse fuera de un laboratorio autorizado). Lo que importa es el patrón: un clásico "filtro central + lista de permisos frágil" en el que la autenticación se aplica comparando los URI de las solicitudes con una lista blanca permisiva. En las aplicaciones Java empresariales de la vieja escuela, esto es común; en términos de seguridad, es un arma recurrente. Si tu control de acceso depende de la concordancia de cadenas o expresiones regulares a través de complejas reglas de análisis de URI, estás apostando a que cada componente aguas arriba normaliza los caminos de la misma manera. Esa apuesta tiende a perder.

Una forma segura de capturar la forma de la causa raíz es observar una versión abstraída de la lógica:

// Pseudocódigo que ilustra el antipatrón (no es código del producto)
if (request.uri.matches(ALLOWLIST_PATTERN) || request.query.equalsIgnoreCase("SPECIAL_CASE")) {
    chain.doFilter(request, response); // omite auth
} else {
    enforceAuthentication();
}

Una vez que los atacantes pueden sortear la puerta de autenticación, cualquier punto final de administración potente se convierte en un trampolín de ejecución potencial. La principal conclusión de Searchlight no es "este punto final específico es peligroso", sino "Las superficies de administración REST dentro de los productos IAM suelen incluir compilación de scripts, gestión de conectores o ganchos de flujo de trabajo con confianza implícita". Cuando se exponen sin autenticación, se obtiene RCE por diseño, no por accidente. (Searchlight Cyber)

La lección de ingeniería más amplia es útil más allá de este único CVE: los filtros centralizados con listas de permisos son una clase de vulnerabilidad estructural. Si está revisando el código de sus propios servicios Java (o auditando el middleware de un proveedor), considere la "central allow-list auth" como un olor que merece una prueba adversarial.

Versiones afectadas y contexto del parche

Oracle ha solucionado el problema CVE-2025-61757 en la aplicación Actualización de parches críticos de octubre de 2025 (CPU)publicado el 2025-10-21. (Oracle) Las versiones afectadas que se mencionan en varios trackers son:

Esto coincide con NVD, la base de datos de vulnerabilidades de Wiz y el informe de exposición de runZero. (NVD)

Un punto operativo sutil pero importante: Las CPU de Oracle son trimestrales. Las empresas que no cuentan con un estricto músculo de ingesta y despliegue de CPU tienden a acumular "deuda de parches" en las pilas de identidad y middleware porque se perciben como sistemas estables y de pocos cambios. CVE-2025-61757 rompe esa suposición. No es un fallo que se pueda dejar para el "próximo trimestre" si se puede acceder al plano de gestión REST desde redes no fiables.

Realidad de la superficie de ataque: por qué esta CVE se escaneará rápido

Incluso sin hablar de los detalles del exploit, la forma del vector CVSS indica por qué los actores de amenazas automatizadas se preocupan. NVD y Wiz lo enumeran como:

• AV:N (red alcanzable),
• AC:L (baja complejidad),
• PR:N/UI:N (sin privilegios, sin interacción del usuario),
• C:H/I:H/A:H (impacto completo). (NVD)

Esa combinación es la "luz verde" para los escáneres de productos básicos. En el momento en que un PoC aterriza en los canales públicos, se convierte en un huella dactilar de una solicitud + cadena de seguimiento en las redes de bots. Los servidores de identidad que están expuestos silenciosamente a través de balanceadores de carga mal configurados, reglas NAT heredadas o agujeros de soporte remoto de proveedores tienden a aparecer rápidamente en esos escaneos.

También hay un problema de contexto más amplio: El middleware de Oracle ha sido un objetivo de alto valor en 2025, con múltiples fallos críticos no autenticados en productos adyacentes (WebLogic, EBS, módulos de marketing) que se han convertido en campañas activas. La revisión de la CPU de Qualys de octubre destaca explícitamente los críticos de Fusion Middleware como un grupo de alto riesgo. (Qualys) Esto aumenta la probabilidad de que los atacantes encadenen el compromiso de la OIM en operaciones más amplias del estado de Oracle.

Verificación defensiva sin convertir la detección en explotación

Para la mayoría de los equipos, la primera tarea es sencilla: identificar la exposiciónno emular a los atacantes. Un flujo de trabajo seguro y autorizado tiene este aspecto:

1. Inventario de versiones de la OIM entre entornos y comparar con las líneas afectadas.
2. Restringir el acceso a la gestión inmediatamente (ACL de red, puerta VPN, ZTNA), incluso antes de las ventanas de parches.
3. Cazar anomalías de administración REST en los registros de acceso: URI de solicitud de alta entropía, ráfagas procedentes de IP desconocidas o endpoints de clase admin invocados en horas sin cambios.

Para concretar, aquí tienes un comparador de versiones sólo defensivo que puedes integrar en tus trabajos de inventario de activos:

# Sólo defensiva: hacer coincidir las versiones OIM descubiertas con el conjunto afectado
del paquete importar versión

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

def es_afectado(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, "¿afectado?" , is_affected(v))

Si no puede extraer versiones de forma fiable de los banners, dé prioridad a los datos internos de la CMDB, los manifiestos de paquetes de host o los metadatos de inicio de Oracle. La clave es evitar "sondear" el nivel de identidad de forma que aumente el riesgo operativo.

La caza tras el parche: cómo sería el compromiso

La cadena Searchlight implica una clase específica de comportamientos que debes vigilar, incluso después de la actualización:

• Puntos finales de gestión REST atacados por fuentes desconocidasespecialmente desde rangos de IP públicas.
• Verbos de gestión utilizados fuera de las ventanas de cambio, en particular todo lo que compila, carga o altera flujos de trabajo/conectores.
• Nuevas cuentas de servicio o cambios de función que no se ajustan a las operaciones con multas.

Tanto RunZero como Wiz aconsejan revisar los registros en busca de actividad REST inusual y reducir la accesibilidad de la gestión como parte del endurecimiento, no sólo de la corrección. (RunZero)

La razón para tomarse esto en serio después de parchear es que los bugs RCE pre-auth son a menudo explotados antes de divulgación. Si el nivel REST estaba expuesto, asuma que puede haber sido tocado.

Mitigación que reduce realmente el riesgo

La recomendación oficial de Oracle es aplicar las actualizaciones de CPU de octubre de 2025, que incluyen la corrección. (Oracle) Desde el punto de vista de la ingeniería, las acciones para reducir el riesgo se apilan así:

• Parche inmediato en cualquier versión compatible afectada.
• Eliminar la accesibilidad pública de planos de gestión REST. Las API de administración de identidades no deben estar orientadas a Internet.
• Rotación de credenciales privilegiadas y exigir la AMF cuando sea posible desde el punto de vista operativo.
• Línea de base y seguimiento Deriva de la configuración OIM (roles, conectores, flujos de trabajo).
• Segmentar el nivel IAM de modo que, incluso si la OIM se ve comprometida, el movimiento lateral se ralentiza.

Nada de esto es nuevo, pero CVE-2025-61757 es un caso de estudio de por qué el endurecimiento de IAM no puede ser tratado como "establecer y olvidar". El middleware de identidad está ahora firmemente en el mismo cubo de prioridad de amenazas que las VPN de borde y las pasarelas web.

Por qué esta CVE es importante para los ingenieros de seguridad de IA

Si trabajas en la intersección de los sistemas de IA y la seguridad, la OIM es una dependencia ascendente cada vez más relevante. Sus clústeres de servicio de modelos, plataformas de datos, CI/CD e incluso herramientas LLM internas a menudo heredan las decisiones de acceso de la IAM corporativa. La toma de control previa a la autenticación de la infraestructura de identidad es la forma en que los atacantes "legitiman" el compromiso posterior de la pila de IA: no necesitan destrozar un servidor de modelos si pueden acuñar la identidad que está autorizada a cambiarlo.

Desde la perspectiva de la IA defensiva, CVE-2025-61757 es un recordatorio para tratar la telemetría de identidad como una señal de primera clase en sus canales de detección. Si estás construyendo herramientas de seguridad agénticas, la "automatización de alto impacto" más realista no es la generación especulativa de exploits, sino el inventario de alta fidelidad, el modelado de radio de explosión y la orquestación de parches para los conjuntos de identidad y middleware.

Una nota tranquila sobre automatización (cuando cabe)

En los grandes conjuntos de Oracle, la proliferación de versiones es real: los inquilinos de desarrollo, control de calidad, recuperación de desastres y legado a menudo tienen un retraso de trimestres. Las plataformas de automatización Human-in-the-loop como Penligent pueden ayudar con inventario de versiones OIM en toda la flota, validación de la exposición y seguimiento de las medidas correctorassin empujar a los equipos a una explotación arriesgada. Cuando la vulnerabilidad es crítica a nivel de identidad, la velocidad y la precisión en el bucle "encontrar → priorizar → solucionar" importan más que cualquier otra cosa.

Cerrar

CVE-2025-61757 no es sólo un error; es una ruta de compromiso de alto nivel de identidad nacida de un conocido anti-patrón de Java empresarial. La petición inmediata es obvia: parchear las versiones de OIM afectadas y bloquear el acceso a la gestión REST. El objetivo a largo plazo es mayor: si su plano de control IAM es accesible, será atacado - y los filtros centralizados de listas permitidas serán saltados. Trate esta CVE como una función forzosa para auditar cómo se exponen, autentican y supervisan sus sistemas de identidad.