Oracle ha emitido una alerta de seguridad relacionada con dos nuevas vulnerabilidades que afectan a su plataforma E-Business Suite (EBS). La primera, identificada como CVE-2025-61884, se clasifica como una vulnerabilidad grave con un CVSS de 7,5. Esta falla permite el acceso no autorizado a datos confidenciales si un atacante tiene acceso a la red a través de HTTP.
La vulnerabilidad CVE-2025-61884 afecta a las versiones desde la 12.2.3 hasta la 12.2.14. Según el comunicado de Oracle, un atacante no autenticado puede comprometer Oracle Configurator y acceder a datos críticos o a todos los datos accesibles del sistema.
En una alerta independiente, Oracle indicó que la vulnerabilidad se puede explotar de forma remota sin necesidad de autenticación. Por lo tanto, es crucial que los usuarios instalen la actualización lo antes posible. Sin embargo, no se menciona ninguna explotación en la práctica.
El director de seguridad de Oracle, Rob Duhart, señaló que la vulnerabilidad afecta a algunas implementaciones de E-Business Suite y podría utilizarse para permitir el acceso a recursos confidenciales.
CVE-2025-61882 – Otro Zero-Day
Este desarrollo se produce poco después de que Google Threat Intelligence Group (GTIG) y Mandiant revelaran que decenas de organizaciones podrían haberse visto afectadas tras la explotación de un Zero-Day relacionado con CVE-2025-61882. Se estima que la actividad, que presenta algunas características asociadas con el grupo de ransomware Cl0p, generó múltiples vulnerabilidades distintas, incluyendo la posibilidad de vulnerar las redes objetivo y exfiltrar datos confidenciales.
Esta vulnerabilidad se puede explotar remotamente sin autenticación. Si se explota con éxito, esta vulnerabilidad puede provocar la ejecución remota de código.
Watchtowr ha observado que CVE-2025-61882 no es «solo» una vulnerabilidad, sino un flujo de numerosas debilidades pequeñas y medianas. Esto es importante porque permite especular que quien descubrió estas vulnerabilidades y las encadenó conoce Oracle EBS a la perfección.
La cadena de ataque muestra un alto nivel de habilidad y esfuerzo, con al menos cinco errores distintos orquestados conjuntamente para lograr la Ejecución Remota de Código (ERC) preautenticada.
Etapas de la vulnerabilidad
Etapa 1: Falsificación de solicitudes del lado del servidor. La carga útil comienza enviando una solicitud XML especialmente diseñada al servlet inferior. Este documento XML puede usarse para obligar al servidor backend a enviar solicitudes HTTP arbitrarias.
Etapa 2: Inyección de retorno de carro/salto de línea (CRLF). Con una falsificación de solicitud del lado del servidor previa a la autenticación, se ejerce control total sobre la solicitud SSRF mediante el uso de cargas útiles CRLF. Los ataques CRLF consisten en el uso de nuevas líneas y caracteres de retorno de carro para modificar maliciosamente el contenido de un archivo, cadena o analizador e inyectar datos en áreas no deseadas por los desarrolladores.
Etapa 3: ¿Qué podemos hacer con «solo» SSRF? Una de las estrategias inteligentes en la cadena de exploits fue convertir la inyección CRLF en un arma dentro de la carga útil SSRF y, posteriormente, llevarla un paso más allá, abusando de las conexiones persistentes HTTP. Esta combinación permite al atacante controlar el encuadre de solicitudes a través de la SSRF y luego reutilizar la misma conexión TCP para encadenar solicitudes adicionales, lo que aumenta la fiabilidad y reduce el ruido.
Las conexiones persistentes HTTP, también conocidas como HTTP keep-alive o reutilización de conexión, permiten que una sola conexión TCP transmita múltiples pares de solicitud/respuesta HTTP en lugar de abrir una nueva conexión para cada intercambio.
En este contexto, la reutilización de conexión amplifica la ventaja del atacante: una vez que el encuadre inicial de SSRF y CRLF está configurado, las solicitudes posteriores pueden enviarse por el mismo canal, lo que hace que la cadena de exploits sea más eficiente y difícil de detectar.
Etapa 4: Evitar el filtro de autenticación. Si bien las vulnerabilidades SSRF pueden tener un impacto limitado por sí solas, se vuelven peligrosas cuando se combinan con otras debilidades o cuando pueden afectar a recursos internos sensibles. Cuando se cuenta con todos los ingredientes disponibles (como la inyección CRLF y la capacidad de convertir la solicitud HTTP de GET a POST), la situación es muy diferente.
Esto es técnicamente impresionante y amplía significativamente la superficie de ataque disponible para los siguientes pasos de una cadena de explotación: una SSRF con capacidad POST y una aplicación interna accesible ofrecen, lógicamente, a cualquier atacante muchas más opciones.
Etapa 5: Transformación XSL (XSLT). La cadena de exploits apunta a /OA_HTML/help/../ieshostedsurvey.jsp en el puerto 7201. Este archivo es simple pero expone funcionalidad y un manejo inseguro de entradas que es aprovechado para la explotación y ejecución de código.