Índice de contenidos
Claves de la noticia
- Mandiant observa una nueva campaña de ShinyHunters contra Oracle PeopleSoft y decenas de sistemas comprometidos en varios sectores.
- Los atacantes sustituyen una letra de la ruta del componente vulnerable por su representación codificada para eludir determinadas reglas WAF.
- El parche de Oracle y la revisión de registros con rutas normalizadas son más fiables que bloquear una cadena literal.
La vulnerabilidad de Oracle PeopleSoft que salió a la luz en junio vuelve a estar bajo explotación. Esta vez, según el análisis de Mandiant y Google Threat Intelligence Group, el grupo UNC6240, asociado a ShinyHunters, ha adaptado su solicitud para pasar por delante de filtros que parecían cerrar el acceso al componente afectado. El informe, difundido durante la noche en España, convierte una diferencia de codificación de un carácter en una alerta práctica para quienes administran PeopleSoft.
Una P codificada abre la ruta bloqueada
El punto de entrada es Environment Management Hub, o EMHub, un componente administrativo de PeopleSoft. La vulnerabilidad CVE-2026-35273 permite ejecutar código a distancia en instalaciones expuestas y sin corregir. Mandiant describe peticiones dirigidas a /%50SEMHUB/hub, donde %50 es la codificación de la letra «P». Un filtro que busque literalmente /PSEMHUB/ antes de decodificar la URL puede no reconocer la nueva escritura. El servidor de aplicaciones, en cambio, la interpreta y entrega la petición al mismo componente.
Ese detalle separa dos controles que suelen confundirse. Bloquear una secuencia de caracteres no equivale a eliminar la vulnerabilidad. La regla perimetral puede ser útil como medida temporal si trabaja sobre la ruta ya normalizada, pero una comparación literal anterior a la decodificación deja abierta la variante que documenta Mandiant. El caso muestra por qué una auditoría que solo compruebe la existencia de una regla WAF podría pasar por alto sistemas todavía explotables.
Antes de ejecutar la carga completa, los atacantes envían, según el informe, entre cinco y quince peticiones de prueba. Una respuesta puede revelar el sistema operativo del servidor sin dejar archivos ni interrumpir el servicio. Por ello, una solicitud sospechosa aislada no demuestra por sí sola que se haya instalado una puerta trasera, pero tampoco debe descartarse por ausencia de ficheros nuevos.
De universidades a siete ámbitos de actividad
El informe que Mandiant publicó en junio situó las primeras intrusiones observadas entre el 27 de mayo y el 9 de junio de 2026, cuando el fallo era desconocido públicamente. La mayoría de los objetivos de aquella muestra eran instituciones educativas. Oracle publicó su aviso extraordinario de seguridad el 10 de junio. Desde entonces, el problema dejó de ser un zero-day, pero los sistemas sin parche siguieron ofreciendo un punto de entrada.
La nueva investigación describe web shells en decenas de sistemas de todo el mundo y menciona educación superior, tecnología, servicios informáticos, sanidad, agricultura, transporte y sector público. No ofrece una lista pública de víctimas ni una cifra total de organizaciones afectadas. Tampoco permite concluir que todas las instalaciones PeopleSoft de esos sectores estén comprometidas. Lo comprobable es el cambio de alcance en la muestra observada por los investigadores: la campaña ya no aparece concentrada en universidades.
| Aspecto | Junio | Septiembre |
|---|---|---|
| Situación del fallo | Explotación previa al aviso de Oracle del 10 de junio | Explotación de sistemas todavía sin corregir |
| Objetivos descritos | Predominio de educación superior | Siete ámbitos citados por Mandiant |
| Ruta relevante | /PSEMHUB/ |
Variante codificada /%50SEMHUB/ |
La comparación de los dos informes deja una conclusión más precisa que el simple recuento de sectores: la adaptación de la ruta convierte en insuficiente una defensa temporal aplicada tras el primer aviso, si esa defensa nunca fue acompañada por el parche. No se trata de una vulnerabilidad nueva con otro identificador, sino de una manera distinta de llegar al mismo componente vulnerable.
La revisión no acaba al buscar web shells
Mandiant identifica dos formas de ejecución. En algunos sistemas el atacante instala archivos JSP que permiten volver a enviar órdenes al servidor. En otros, los comandos se ejecutan directamente y la respuesta vuelve por HTTP, sin que aparezca un nuevo archivo. Un equipo que solo busque web shells puede, por tanto, no detectar la segunda modalidad. El informe advierte asimismo de que, detrás de un balanceador, pueden existir varios nodos y no basta con examinar el primero que responda.
La guía de actuación empieza por aplicar el parche indicado en el aviso de Oracle. También recomienda desactivar EMHub en configuraciones con varios servidores cuando no sea necesario, o retirar la aplicación PSEMHUB en las configuraciones de un solo servidor siguiendo las instrucciones del fabricante. Son decisiones que debe tomar el equipo responsable de la instalación, tras comprobar cómo se usa ese componente; no afectan, según Mandiant, a las sesiones normales de la interfaz de PeopleSoft cuando se restringen esos servicios administrativos.
Para investigar una posible intrusión, la búsqueda debe abarcar peticiones a la ruta literal y sus variantes codificadas, solicitudes POST al componente y accesos a JSP inesperados. Mandiant propone revisar el directorio de la aplicación, procesos de shell iniciados por WebLogic y herramientas de administración remota no previstas. Si se confirma una intrusión, aconseja preservar pruebas y cambiar las credenciales que pudiera leer la cuenta de servicio, incluidas conexiones a bases de datos y otros sistemas a su alcance.
El riesgo real está en la falsa contención
PeopleSoft suele albergar procesos de recursos humanos, nóminas y otras funciones sensibles. El nuevo informe describe técnicas con capacidad para acceder a credenciales y datos, pero no afirma que todos los objetivos hayan sufrido extracción de información. Para los responsables de seguridad, esa distinción importa: detectar la ruta codificada exige investigar qué ocurrió después en cada servidor, no dar por demostrada una fuga ni cerrar el caso porque no haya un fichero malicioso visible.
La lección operativa que deja la comparación entre junio y septiembre es concreta. Un WAF puede reducir exposición, pero el parche corta la causa y la revisión de rutas normalizadas permite comprobar si la protección provisional falló. Las organizaciones que mantuvieron PeopleSoft sin corregir deberían tratar la aparición de peticiones a /%50SEMHUB/ como una señal para examinar todos los nodos, las cuentas accesibles y posibles movimientos posteriores, incluso si el panel del WAF no registró un bloqueo.
