Zero-day de PeopleSoft de ShinyHunters: tres fallos encadenados

Si parcheaste CVE-2026-35273 en junio y seguiste con lo tuyo, la pregunta que conviene hacerse esta semana es sencilla: ¿parcheado contra qué, exactamente? Según los investigadores que reportaron el fallo a Oracle, el grave error de PeopleSoft que ShinyHunters explotó como zero-day durante meses no es una vulnerabilidad sino tres, encadenadas entre dos componentes distintos. Oracle las corrigió todas bajo un único identificador. Si un parche con un solo identificador basta para verificar la cobertura es la parte incómoda de esta historia.

La respuesta corta: si aplicaste la corrección fuera de banda de Oracle, cerraste las tres brechas, porque un solo parche las cubría. Pero el identificador por sí solo no lo demuestra, y no dice nada sobre si alguien entró antes de que parcharas. En ese segundo punto, la evidencia no tranquiliza. La guía de Mandiant asume que el compromiso persiste después del parche. Yo también lo creo.

La cronología: zero-day durante dos semanas, con retraso en su notificación durante cuatro meses

Si ordenas las fechas, la forma del incidente se aclara. El día 0, en términos prácticos, fue el 27 de mayo, cuando Mandiant y Google Threat Intelligence Group afirman que el grupo que siguen como UNC6240, más conocido como ShinyHunters, empezó a explotar el fallo, sobre todo contra universidades. Esa actividad se prolongó hasta el 9 de junio. El 10 de junio, Oracle publicó una alerta de seguridad fuera de banda con el CVE-2026-35273, una vulnerabilidad de ejecución remota de código con CVSS 9,8, sin autenticación y accesible por red, en PeopleSoft Enterprise PeopleTools en las versiones 8.61 y 8.62. Todo lo anterior a esa fecha fue un zero-day, sin matices.

La falla llegó al catálogo de Vulnerabilidades Explotadas Conocidas de CISA, como debía. A principios de junio, ShinyHunters declaró a The Register que había vulnerado a más de 100 organizaciones mediante el fallo. Luego, en septiembre, unos tres meses después del parche, Mandiant documentó una segunda oleada, más grande. Los objetivos se extendieron mucho más allá de la educación, hacia la tecnología, los servicios de TI, la sanidad, la agricultura, el transporte y el gobierno, con web shells desplegadas en decenas de sistemas de todo el mundo. Una vulnerabilidad parcheada con un número creciente de víctimas suele significar una de dos cosas: parcheo lento o atacantes que mantienen el acceso obtenido antes. Aquí parece que han ocurrido ambas.

Esta semana, Bobby Gould, de la Zero Day Initiative, publicó el desglose que replantea todo el incidente, como informó The Hacker News. El equipo de ZDI, formado por Gould junto con los investigadores de TrendAI Minh Giang y Lucas Miller, reportó tres vulnerabilidades distintas en dos componentes de PeopleSoft. Oracle las parcheó bajo el único CVE de junio. ZDI indica que trabaja con Oracle para asignar un identificador propio a cada fallo; a día de hoy, CVE-2026-35273 sigue siendo el único registrado.

Paso a paso: cómo funcionaba realmente la cadena

Dos componentes son clave, ambos ejecutándose como aplicaciones web independientes. La Integration Gateway (PSIGW) gestiona la mensajería con sistemas externos. El Environment Management Hub (PSEMHUB) es una interfaz de administración interna que solo debería responder a hosts de confianza. La cadena es sencilla en el sentido en que suelen serlo las peores: sin primitivas exóticas, solo una decisión de confianza que nunca debió llegar a producción.

1. Paso uno: el SSRF en PSIGW. Un atacante envía una solicitud al conector de escucha de la pasarela y controla tanto la dirección de destino como la carga completa que se reenvía. ZDI afirma que el manejador no comprueba si el destino es legítimo. Por sí solo, el alcance es limitado. Importa por lo que puede alcanzar.
2. Paso dos: el bypass de confianza en loopback. PSEMHUB decide en quién confiar usando un archivo llamado allowedhosts.properties. Ese archivo viene con 127.0.0.1 ya incluido en la lista. Si diriges el SSRF al loopback, la solicitud falsificada llega como si procediera de la propia máquina. La comprobación de confianza se supera. La interfaz interna que Oracle pretendía aislar queda accesible desde internet.
3. Paso tres: ejecución de código, de dos formas. Opción A: abusar de un comando de PSEMHUB diseñado para escribir entradas de registro. Quien llama controla el contenido del archivo y la ruta exacta en disco, así que puede escribir una web shell en el directorio de la aplicación y ejecutarla como la cuenta de servicio de PeopleSoft. Opción B: depositar un archivo XML malicioso que PSEMHUB procesa con XMLDecoder de Java al reiniciar el servicio, lo que ejecuta código sin necesidad de instalar ninguna shell. La segunda vía deja bastante menos rastro que la detección estándar pueda captar.

Fíjate en lo que no aparece. Nada en esta cadena requirió desarrollo de exploits nuevo en el momento del ataque. Un SSRF hacia una interfaz de administración con confianza en loopback es un patrón que los respondedores de incidentes llevan años documentando. ZDI señaló el núcleo de la decisión de diseño: permitir por defecto el loopback vuelve inútil la comprobación de confianza en cuanto existe cualquier SSRF. Si tu control compensatorio era una regla de red que asumía que PSEMHUB solo era accesible en local, esa suposición murió en el paso dos.

La regla del WAF que no estaba

La oleada de septiembre incluyó un detalle que debería irritar a cualquier equipo que tratara el filtrado perimetral como mitigación. Mandiant descubrió que ShinyHunters eludía las reglas del WAF que bloqueaban la ruta /PSEMHUB/ codificando en URL un único carácter: solicitaba /%50SEMHUB/ en su lugar. Muchas reglas de WAF comparan la ruta como texto plano; el servidor de PeopleSoft la decodifica y sirve la página. Un carácter. Esa es la distancia entre tener una regla sobre el papel y tener una interfaz de administración expuesta en internet.

Mandiant es explícito: el bloqueo por ruta en el WAF no sustituye al parche. Yo iría más lejos: si tu única telemetría sobre este problema era una regla del WAF que coincidía con la ruta literal, tus registros pueden no mostrar nada mientras el ataque tuvo éxito. ¿Cuándo podría haberse detectado? En la pasarela, si se registraran y alertaran los destinos de las solicitudes salientes; un SSRF hacia 127.0.0.1 desde un conector no es tráfico normal. En el sistema de archivos, cuando aparece un archivo nuevo en el directorio de la aplicación. Al reiniciar el servicio, cuando XMLDecoder ejecutó algo que no debía. Cada etapa ofrecía una oportunidad de detección. Todas exigían mirar el host, no el perímetro.

Lo que oculta un solo CVE y lo que el parche no arregla

¿Basta el parche con un solo identificador para que los defensores verifiquen que están cubiertos? En parte. La corrección de junio de Oracle abordó los tres problemas, así que un sistema completamente parcheado tiene cerrada la cadena; eso lo confirma que exista la alerta y que el análisis de ZDI describa lo que cerró. Lo confirmado termina ahí. Queda sin respuesta si aplicar el parche elimina el acceso que un atacante ya había establecido. La alerta de Oracle no lo aborda. La guía de Mandiant —buscar web shells, tratar cualquier host con una shell como comprometido, preservar evidencias y rotar todas las credenciales accesibles desde la capa de PeopleSoft— se escribe asumiendo que no lo elimina. Esa suposición es correcta. El parche cierra la puerta, pero no expulsa a quien ya está dentro, y el modelo de negocio de ShinyHunters consiste precisamente en estar dentro: robar los datos y luego exigir un pago.

Hay un problema de verificación más amplio en la forma en que se divulgó esto. Tres fallos, dos componentes, un CVE. Un escáner que compruebe la cobertura de CVE-2026-35273 te dirá que el parche está aplicado, pero no te dirá cuál de las tres debilidades remedió, ni si tu allowedhosts.properties sigue confiando en loopback, ni si tu pasarela sigue reenviando cargas arbitrarias. Identificadores separados, que ZDI está coordinando con Oracle para asignar, permitirían al menos a proveedores y equipos de seguridad relacionar correcciones, detecciones y mitigaciones con debilidades concretas en lugar de con un identificador monolítico. Hasta entonces, afirmar que se parcheó el 35273 es una declaración de intención, no una verificación de la postura de seguridad. Si ese patrón te resulta familiar —atacantes que encadenan en silencio un bypass de autenticación durante meses mientras los defensores confían en una única corrección—, la campaña contra PAN-OS de las bandas de ransomware Qilin e Inc funcionó con la misma lógica.

El trabajo de esta semana

La orientación sobre corrección y respuesta aquí proviene de Oracle y Mandiant, no de ZDI, cuyo análisis cubre el fallo en sí. Por orden de prioridad: aplica la corrección fuera de banda para CVE-2026-35273 y mantente en una versión de PeopleTools con soporte. Si de verdad no puedes parchear, la alerta de Oracle indica que deshabilites el servicio Environment Management Hub en configuraciones multiservidor, o que elimines la aplicación PSEMHUB en configuraciones de servidor único; restringir estos endpoints de administración no interrumpe las sesiones normales de usuario. Después, para cualquier instancia que haya permanecido sin parchear y accesible desde internet entre finales de mayo y el momento en que la corregiste, trátala como una posible intrusión: haz una imagen o preserva el host, busca web shells en los directorios de aplicaciones y rota todas las credenciales a las que pudiera acceder la capa de PeopleSoft. Prepárate para un correo de extorsión; así es como este grupo monetiza.

La lección no es que Oracle lanzara tres errores bajo un solo CVE, aunque así fue. Es que la cadena solo funcionó por un valor predeterminado que nadie cuestionó —el loopback en una lista de hosts de confianza— y que cada control compensatorio construido sobre ese valor, desde las suposiciones sobre el cortafuegos hasta las reglas de ruta del WAF, falló de la misma manera silenciosa. Revisa los registros de tu pasarela. Si PSIGW alguna vez reenvió una solicitud a 127.0.0.1, ya tienes la respuesta sobre si el parche fue el final de este incidente o solo su mitad.