La vulnerabilidad crítica CVE-2026-35273 que el grupo aprovechó desde mayo resultó ser una cadena de tres fallos distintos reportados juntos.
ShinyHunters explotó una vulnerabilidad crítica en Oracle PeopleSoft desde mayo de 2026 que los investigadores que la reportaron describieron esta semana como tres fallos encadenados, no uno solo. Oracle parcheó los tres bajo el identificador CVE-2026-35273 en junio de 2026. La raíz del problema es un Server-Side Request Forgery (SSRF, falsificación de solicitud del lado del servidor) que permite alcanzar una interfaz de gestión interna porque PeopleSoft confía en su propia dirección loopback sin validación adicional.
Tres fallos reportados, un solo CVE asignado
Los investigadores que descubrieron la vulnerabilidad confirmaron que lo que Oracle documentó como CVE-2026-35273 en realidad agrupa tres fallos distintos que funcionan en cadena. El primero es el SSRF que permite a un atacante forzar al servidor PeopleSoft a realizar solicitudes HTTP hacia sí mismo. El segundo aprovecha que PeopleSoft confía implícitamente en las solicitudes que provienen de su dirección loopback (127.0.0.1), lo que permite eludir controles de autenticación en interfaces de gestión que deberían estar restringidas. El tercer fallo en la cadena permite ejecutar acciones administrativas una vez que el atacante alcanzó esa interfaz interna.
La decisión de Oracle de agrupar los tres fallos bajo un único identificador CVE complica el análisis de exposición para los equipos de seguridad que gestionan inventarios de vulnerabilidades. Un CVE único sugiere un parche atómico, pero la cadena implica que cada uno de los tres componentes podría haber sido explotable de forma independiente si el atacante encontraba rutas alternativas para alcanzar los mismos puntos de falla. No está documentado si Oracle evaluó cada fallo por separado antes de consolidarlos en un solo identificador.
Cómo ShinyHunters aprovechó la ventana de exposición
ShinyHunters comenzó a explotar la vulnerabilidad en mayo de 2026, al menos un mes antes de que Oracle publicara el parche en junio. No está confirmado si el grupo descubrió la cadena de forma independiente o si tuvo acceso a información sobre el reporte antes de la publicación del parche. Lo que sí está documentado es que la explotación activa ocurrió durante la ventana en que las organizaciones con instancias de PeopleSoft expuestas a internet no tenían forma de mitigar el problema más allá de aislar los sistemas de la red pública.
PeopleSoft es una suite de aplicaciones empresariales que gestiona recursos humanos, finanzas y cadena de suministro. Las instancias suelen contener datos sensibles de empleados, nóminas, contratos y transacciones financieras. La capacidad de alcanzar interfaces de gestión interna sin autenticación previa convierte esta cadena de fallos en un vector directo para exfiltración de datos o modificación de registros críticos. No hay información pública sobre cuántas organizaciones fueron comprometidas durante la ventana de mayo a junio, ni sobre qué datos específicos extrajo ShinyHunters en esas operaciones.
Exposición estructural en América Latina
Oracle PeopleSoft tiene adopción significativa en el sector público y en grandes empresas de América Latina, particularmente en Brasil, México y Chile, donde se usa para gestión de nómina y recursos humanos en ministerios, universidades y corporaciones financieras. La dependencia de sistemas ERP (planificación de recursos empresariales) heredados en la región amplifica el impacto de vulnerabilidades críticas como CVE-2026-35273, porque muchas organizaciones operan versiones de PeopleSoft con ciclos de actualización lentos o postergados por complejidad operativa.
No hay reportes públicos de compromiso específico de instancias latinoamericanas durante la ventana de explotación de mayo a junio de 2026. Sin embargo, la combinación de exposición a internet de interfaces de gestión empresarial y la práctica regional de mantener sistemas críticos sin segmentación de red adecuada crea un escenario de riesgo estructural. Las organizaciones que no aplicaron el parche de junio de 2026 en los 30 días posteriores a su publicación quedaron expuestas a explotación por parte de ShinyHunters o de otros actores que replicaron la técnica después de que la cadena de fallos se hiciera pública.
Por qué confiar en loopback sin validar es un patrón recurrente
La confianza implícita en solicitudes que provienen de la dirección loopback (127.0.0.1) es un patrón de diseño inseguro que aparece en múltiples productos empresariales. La lógica detrás de esta decisión de arquitectura es que las solicitudes internas del servidor hacia sí mismo se asumen legítimas porque no atraviesan la red externa. El problema es que un SSRF permite a un atacante externo forzar al servidor a realizar esas solicitudes internas, convirtiendo la confianza en loopback en un bypass de autenticación.
Este patrón ya se documentó en vulnerabilidades críticas de otros sistemas empresariales en los últimos tres años. La diferencia en el caso de PeopleSoft es que la cadena de tres fallos requiere menos pasos de explotación que casos anteriores: el SSRF alcanza directamente la interfaz de gestión sin necesidad de escalar privilegios adicionales o explotar un segundo componente separado. La simplicidad de la cadena explica por qué ShinyHunters pudo operacionalizarla en mayo, apenas semanas después de que los investigadores reportaran el fallo a Oracle.
Nuestro análisis
CVE-2026-35273 expone dos problemas sistémicos en la gestión de vulnerabilidades empresariales. El primero es la práctica de consolidar múltiples fallos bajo un único identificador CVE, lo que reduce la granularidad del análisis de riesgo y complica la priorización de parches en entornos con miles de sistemas. Un equipo de seguridad que revisa CVE-2026-35273 en su inventario no tiene forma de saber, sin leer el análisis técnico completo, que está frente a una cadena de tres fallos que requiere validar tres puntos de control distintos en su implementación de PeopleSoft.
El segundo problema es la ventana de explotación activa antes de la disponibilidad del parche. ShinyHunters operó durante al menos un mes con acceso a una técnica que no tenía mitigación efectiva más allá del aislamiento de red. Esto refuerza el patrón que ya se observó en otros casos de 2026: los grupos de exfiltración de datos priorizan vulnerabilidades en sistemas empresariales con alta concentración de información sensible y ciclos de parche lentos. La pregunta que queda abierta es si Oracle recibió el reporte de los investigadores antes de mayo, y si la ventana de explotación podría haberse reducido con un proceso de parche acelerado para fallos críticos en productos con adopción masiva en infraestructura corporativa.