Oracle Coherence: RCE sin autenticación expone clusters de Fusion Middleware (CVE-2026-35307)

Contexto del incidente

El 16 de junio de 2026 Oracle publicó su Critical Security Patch Update de junio, que incluye 245 parches de seguridad en toda la suite. Entre los parches más críticos aparecen CVE-2026-35307 y su CVE compañero CVE-2026-35308, ambos con un puntaje CVSS 3.1 de 10.0 — el máximo posible — y un vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H que describe el peor escenario: ataque por red, baja complejidad, sin autenticación, sin interacción del usuario, con cambio de scope e impacto total en confidencialidad, integridad y disponibilidad.

La falla reside en el componente Core de Oracle Coherence, la grilla de datos en memoria que Oracle Fusion Middleware usa como capa de cache distribuida y que es consumida directamente por WebLogic Server, SOA Suite, ORDS y decenas de productos Oracle empaquetados como "Fusion Middleware Infrastructure". Coherence se expone por HTTP en su puerto de management (8088 por defecto) y por REST para tareas de cluster management. Por la naturaleza del componente, una vulnerabilidad en el Core no afecta solo al proceso de Coherence: el flag scope:Changed en el CVSS indica que la falla rompe la frontera de seguridad y compromete a las aplicaciones que dependen del cluster.

Desde la óptica del atacante, el ataque es directo: un request HTTP especialmente armado contra los endpoints de management del Core, sin cookie de sesión ni token, ejecuta código arbitrario en el contexto del JVM que hospeda al nodo de Coherence. Como el cluster comparte sesiones y caches, el compromiso escala a todos los nodos. La entrada en el CISA KEV todavía no se produjo (EPSS reportado por FIRST en el percentil 37), pero el CVSS 10.0 con complejidad baja y vector red hacen que esta falla sea una candidata natural a sumarse a KEV en cuanto aparezca un PoC público o un caso de exploitation activa.

Cuando una pieza de middleware se vuelve el camino más corto hacia toda la aplicación, parchearla deja de ser una tarea de IT y se convierte en una decisión de negocio.

¿Cómo proteger tu infraestructura?

1. Aplicá el parche de junio de 2026 sin demora

El CPU de junio de 2026 (CPU157) cubre tanto CVE-2026-35307 (Core) como CVE-2026-35308 (Centralized Third Party Jars). Las versiones afectadas son 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 y 15.1.1.0.0. Si tu Coherence viene empaquetado dentro de WebLogic o de Oracle Forms/Reports, parchear la instalación del producto padre alcanza. Si lo corrés standalone, descargá el patch de MOS Note CPU157 y aplicá Opatch 13.9.4.2.4 o superior. Verificá con opatch lspatches que el bundle de junio figure en la lista.

2. Restringí el acceso HTTP al puerto de management

Por defecto Coherence expone el REST management sobre el puerto 8088 y un proxy opcional sobre 9095. Ninguno de los dos debería estar reachable desde Internet ni desde la red de oficina. Configurá un NetworkFilter en el coherence-cache-config.xml que limite los listeners a la subred de backend, y en el firewall perimetral bloqueá el tráfico 8088/9095 desde fuera del segmento de aplicación. Si necesitás administrarlo remotamente, exponélo únicamente a través de un bastion host con MFA.

3. Exigí autenticación en los endpoints REST del cluster

El error de control de acceso (CWE-284) en el Core se manifiesta en endpoints que no validan correctamente quién está haciendo la llamada. Activá el auth-method basic o cert en el bloque <management> del archivo de configuración, y deshabilitá cualquier perfil que tenga auth-method=none en producción. Si tu Coherence se inicia desde WebLogic, asegurate de que el realm de seguridad del dominio esté heredado por el cluster.

4. Segmentá el cluster y monitorealo

Como el scope change significa que comprometer un nodo compromete a todos, conviene segmentar el cluster de Coherence en una VLAN dedicada, sin rutas hacia bases de datos de producción ni hacia otros middleware. Monitoreá los logs del nodo (<domain>/servers/<server>/logs/<server>.log en WebLogic, o coherence.log en standalone) en busca de requests a /management/coherence/cluster, /management/coherence/services y /coherence/rest/* que provengan de IPs que no estén en tu allowlist. Una buena señal de explotación es ver varios GET seguidos contra /management/coherence/cluster/members desde una IP que jamás había tocado el cluster.

Indicadores de compromiso (IoC)

Como Oracle no publicó un advisory técnico con TTPs detallados, los IoCs que dejamos abajo están derivados del vector CVSS, del componente afectado y del comportamiento esperado del cluster de Coherence. Sirven como punto de partida para tu SIEM o EDR; ajustá los thresholds a la baseline de tu entorno.

• Endpoint sensible (HTTP): GET /management/coherence/cluster/members desde una IP que no esté en la allowlist de management — el request debería estar autenticado y provenir del bastion.
• Puerto de management por defecto: tráfico entrante hacia TCP/8088 y TCP/9095 desde Internet o desde una subred que no sea la de backend/application.
• User-Agent de escaneo: requests a los endpoints REST de Coherence con User-Agent vacío o con strings típicos de scanner (python-requests, curl/, sqlmap, nuclei). Las llamadas legítimas de WebLogic usan el Java HttpClient interno y casi nunca tienen un UA identificable.
• Procesos hijos inesperados en el nodo JVM: en el host que corre Coherence, aparición de shells (/bin/sh, /bin/bash, cmd.exe) o de binarios de post-explotación como ncat, curl o powershell.exe spawneados por el proceso Java de Coherence.
• Archivos JAR nuevos en el classpath: cualquier .jar droppeado en $DOMAIN_HOME/lib/, $MW_HOME/coherence/lib/ o en el directorio temporal de WebLogic en los días posteriores a la divulgación es una señal fuerte de que alguien está intentando persistir.

Para automatizar la detección, un patrón útil es alertar por cualquier request HTTP a */management/coherence/* que llegue sin un Authorization header y desde una IP fuera de la subred de administración.

# Suricata rule — detección de escaneo/exploit contra Coherence management
alert http $EXTERNAL_NET any -> $HOME_NET 8088 (msg:"ORACLE COHERENCE CVE-2026-35307 unauth mgmt access"; flow:to_server,established; http_uri; content:"/management/coherence/"; http_method; content:"GET"; http_header; content:"User-Agent|3a 20|"; nocase; content:"python-requests"; nocase; sid:2026353701; rev:1;)

# Splunk SPL — buscar accesos no autenticados a endpoints REST de Coherence
index=weblogic OR index=coherence
| rex field=uri_path "(?<coh_path>/management/coherence/[^/?]+)"
| search coh_path=*
| eval auth_present=if(isnotnull(authorization) AND authorization!="", "yes", "no")
| where auth_present="no" AND NOT cidrmatch(src_ip, "10.20.0.0/16", "10.30.0.0/16")
| stats count min(_time) as firstSeen max(_time) as lastSeen values(uri_path) as paths by src_ip
| where count > 3