Se ha divulgado una vulnerabilidad de severidad máxima en Oracle Access Manager que afecta a las versiones 12.2.1.4.0 y 14.1.2.1.0. Según la entrada del NVD para CVE-2026-87337, un atacante no autenticado con acceso de red a través de HTTP puede comprometer completamente el Motor de Autenticación, obteniendo la capacidad de leer, crear, eliminar o modificar todos los datos que OAM gestiona. La calificación de cambio de ámbito implica que los sistemas posteriores protegidos por OAM también están expuestos.

Seamos directos sobre lo que esto significa en términos operativos. OAM es un producto de gateway. Se sitúa delante de las aplicaciones y toma decisiones de autenticación en nombre de todo lo que se encuentra detrás. Un CVSS 10.0 aquí no es una puntuación abstracta, es un atacante que cruza la puerta principal, toma los tokens de sesión y luego inspecciona con calma cada aplicación a la que acceden los empleados o los clientes. Sin credenciales. Sin interacción del usuario. Solo acceso de red y la petición HTTP adecuada.

El control que falló conceptualmente es el manejo de entradas previas a la autenticación en el propio Motor de Autenticación. Aún no disponemos del análisis técnico completo, pero un fallo explotable en red, sin privilegios requeridos, en un componente de autenticación casi siempre se reduce a una lista corta: exposición de endpoints no autenticados, deserialización incorrecta o manejo de solicitudes malformadas que omite una comprobación de autenticación asumida. Cualquiera de estos casos debería haberse detectado en la revisión de código o en pruebas de fuzzing antes del lanzamiento. El indicador de cambio de ámbito me dice que el almacén de sesiones o de políticas de OAM es accesible tras la explotación de una forma que cruza los límites de confianza hacia las aplicaciones conectadas.

Si está ejecutando alguna de las versiones afectadas, esta es una situación en la que se parchea primero y se hacen preguntas después. Mientras espera una ventana de mantenimiento, puede reducir la exposición restringiendo el acceso HTTP a los puertos de administración y de tiempo de ejecución de OAM únicamente a direcciones IP de origen internas conocidas. Las reglas de WAF no detendrán de forma fiable algo que opera a este nivel tan bajo en la pila de autenticación, así que no las utilice como control principal en este caso. Audite también qué sistemas dependen de OAM para SSO o para la aplicación de políticas, porque el cálculo del radio de explosión depende de esa lista.

Aplique el parche de Oracle esta semana. Si no puede parchear de inmediato, los controles de acceso en la capa de red al listener de OAM son su mejor medida a corto plazo, no las mitigaciones en la capa de aplicación. Una vez parcheado, revise los registros de acceso de OAM de los últimos 30 días y busque tráfico de autenticación anómalo, en particular solicitudes que tuvieron éxito sin coincidir con un patrón de usuario conocido. Si algo ya se coló, conviene saberlo antes de que se convierta en un problema mayor.