Vulnerabilidad crítica pre-auth RCE en Splunk Enterprise

Splunk ha publicado actualizaciones de seguridad de emergencia para corregir la vulnerabilidad crítica CVE-2026-20253, con una puntuación de CVSS 9.8, en el producto Splunk Enterprise. La vulnerabilidad permite que un atacante no autenticado cree y trunque archivos arbitrarios mediante un endpoint PostgreSQL sidecar sin protección, lo que, según los investigadores de watchTowr Labs, puede desarrollarse hasta un escenario completo de ejecución remota de código (RCE) sin autenticación previa. Se ven afectadas las versiones 10.0.0–10.0.6 y 10.2.0–10.2.3; las correcciones están disponibles en las versiones 10.0.7 y 10.2.4. Splunk Cloud no se ve afectado por la vulnerabilidad. Dada la publicación de detalles técnicos de explotación, la actualización debe considerarse una tarea prioritaria.

Naturaleza de la vulnerabilidad

Según el boletín oficial de Splunk, la causa raíz del problema es la ausencia total de autenticación en el endpoint PostgreSQL sidecar. Cualquier usuario con acceso de red a una instancia vulnerable de Splunk Enterprise puede invocar operaciones sobre el sistema de archivos sin aportar credenciales. El proveedor lo formula así: un usuario no autenticado puede crear o truncar archivos arbitrarios mediante el endpoint de servicio PostgreSQL sidecar.

Versiones afectadas y corregidas:

• Splunk Enterprise 10.0.0–10.0.6 — corregido en la versión 10.0.7
• Splunk Enterprise 10.2.0–10.2.3 — corregido en la versión 10.2.4
• Splunk Enterprise 10.4 — no se ve afectada
• Splunk Cloud — no se ve afectado (PostgreSQL sidecar no se utiliza en el producto en la nube)

Cadena de explotación: de la escritura de archivos a RCE

Los investigadores Piotr Bazydlo y Yordan Ganchev de watchTowr Labs han publicado un análisis técnico detallado que describe el camino desde el primitivo de escritura de archivos hasta la ejecución completa de código arbitrario. Es importante señalar: el boletín del proveedor confirma la posibilidad de realizar operaciones de archivo sin autenticación, mientras que la cadena completa de RCE ha sido descrita por los investigadores y aún no ha sido verificada de forma independiente.

Según los investigadores, el ataque utiliza dos endpoints:

• /v1/postgres/recovery/backup — para conectarse a una base de datos controlada por el atacante y volcar su contenido en un archivo arbitrario en el sistema de archivos de Splunk
• /v1/postgres/recovery/restore — para cargar un volcado malicioso en la instancia local de PostgreSQL utilizando el parámetro passfile, que apunta al archivo /opt/splunk/var/packages/data/postgres/.pgpass, que contiene la contraseña del usuario postgres_admin

El elemento clave del ataque es que las consultas SQL incrustadas en el volcado de la base de datos son ejecutadas por la instancia de PostgreSQL durante el proceso de restauración. Esto permite al atacante definir una función personalizada que utiliza lo_export, el mecanismo estándar de PostgreSQL para exportar grandes objetos (BLOB) a archivos en disco. A través de esta función, el atacante obtiene un primitivo de escritura controlada de contenido arbitrario en el sistema de archivos.

Para escalar hasta la ejecución de código, según watchTowr Labs, basta con sobrescribir un script de Python que Splunk ejecute de forma periódica — por ejemplo, /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Tras la sobrescritura, el código malicioso se ejecuta en el contexto del proceso de Splunk.

Secuencia completa del ataque

1. El atacante crea una base de datos PostgreSQL externa con una configuración que permite la autenticación sin contraseña y concede privilegios suficientes para invocar funciones como CREATE FUNCTION y lo_export
2. Mediante el endpoint /backup, el volcado de esta base se coloca en el sistema de archivos de Splunk
3. Mediante el endpoint /restore, el volcado malicioso se carga en la instancia local de PostgreSQL; durante la restauración se ejecuta la función maliciosa, que escribe en disco un script de Python controlado por el atacante

Evaluación del impacto

Splunk Enterprise es una de las plataformas SIEM más extendidas, utilizada para la agregación y el análisis de registros de seguridad en organizaciones de cualquier tamaño. La compromisión de un sistema SIEM supone una amenaza especialmente grave: el atacante obtiene no solo el control del servidor, sino también acceso potencial a los registros de seguridad de toda la infraestructura, lo que puede emplearse para planificar ataques posteriores y ocultar rastros.

La puntuación CVSS 9.8 refleja su criticidad: el ataque no requiere autenticación, puede ejecutarse de forma remota y conduce a la completa compromisión de la confidencialidad, integridad y disponibilidad. Corren un mayor riesgo las organizaciones cuyos despliegues de Splunk Enterprise son accesibles desde segmentos de red no confiables.

En el momento de la publicación no se han registrado casos confirmados de explotación en ataques reales, y la vulnerabilidad no figura en el catálogo CISA KEV. Sin embargo, la publicación de una descripción técnica detallada de la cadena de explotación incrementa de forma notable la probabilidad de ataques oportunistas en los próximos días.

Recomendaciones

• Actualice de inmediato Splunk Enterprise a las versiones 10.0.7 o 10.2.4, según la rama que utilice
• Restrinja el acceso de red a los endpoints /v1/postgres/recovery/backup y /v1/postgres/recovery/restore mediante segmentación de red y firewalls, como medida temporal hasta aplicar la actualización
• Verifique la integridad de los scripts de Python en el directorio /opt/splunk/etc/apps/, en particular del archivo ssg_enable_modular_input.py, para detectar cambios no autorizados
• Analice los registros de acceso al PostgreSQL sidecar en busca de solicitudes a los endpoints indicados desde orígenes no autorizados
• Si utiliza Splunk Enterprise versión 10.4 o Splunk Cloud, no es necesario actualizar: estos productos no se ven afectados

La combinación de máxima criticidad (CVSS 9.8), ausencia de necesidad de autenticación y disponibilidad pública de la descripción completa de la cadena de explotación convierte a CVE-2026-20253 en una de las vulnerabilidades prioritarias para su remediación inmediata. Las organizaciones que utilicen versiones afectadas de Splunk Enterprise deben aplicar las actualizaciones dentro de un ciclo de parcheo de emergencia, sin esperar a la ventana de mantenimiento planificada, y hasta que se complete la actualización deberían aislar el PostgreSQL sidecar de las redes no confiables.