Splunk lanzó actualizaciones para corregir una falla crítica (CVE-2026-20253) en Splunk Enterprise que permite la ejecución remota de código y operaciones de archivos sin autenticación. El problema radica en la falta de controles de seguridad en un servicio de PostgreSQL, afectando versiones anteriores a la 10.2.4 y 10.0.7. Se recomienda actualizar inmediatamente, aunque Splunk Cloud no se ve afectado por esta vulnerabilidad.





Splunk ha lanzado actualizaciones de seguridad para solucionar un fallo de seguridad crítico en Splunk Enterprise que podría ser explotado para realizar operaciones de archivos sin autenticación e incluso la ejecución remota de código.

La vulnerabilidad, identificada como CVE-2026-20253, tiene una calificación de 9.8 en el sistema de puntuación CVSS.

"En las versiones de Splunk Enterprise anteriores a 10.2.4 y 10.0.7, un usuario no autenticado podría crear o truncar archivos arbitrarios a través de un endpoint del servicio sidecar de PostgreSQL", afirmó Splunk en una alerta esta semana [SVD-2026-0603].

"La vulnerabilidad existe porque el endpoint del servicio sidecar de PostgreSQL carece de controles de autenticación, lo que permite que cualquier usuario con acceso a la red invoque operaciones de archivos sin credenciales".

El problema ha sido solucionado en las siguientes versiones:

* Splunk Enterprise 10.0.0 a 10.0.6 - Solucionado en 10.0.7
* Splunk Enterprise 10.2.0 a 10.2.3 - Solucionado en 10.2.4
* Splunk Enterprise 10.4 - No afectado

Splunk, que forma parte de Cisco, señaló que Splunk Cloud no se ve afectado por la vulnerabilidad ya que no se utilizan sidecars de Postgres en dicho producto.

De qué trata el fallo

El viernes, watchTowr Labs publicó [detalles técnicos adicionales] sobre el CVE-2026-20253, afirmando que podría explotarse para lograr la ejecución remota de código pre-autenticada en sistemas susceptibles a través de los endpoints "/v1/postgres/recovery/backup" y "/v1/postgres/recovery/restore".

La cadena de ataque funciona de la siguiente manera:

* Conectarse a una base de datos controlada por el atacante y volcar su contenido en un archivo arbitrario utilizando el endpoint /backup
* Cargar el volcado de la base de datos controlada por el atacante en la instancia local de PostgreSQL utilizando el endpoint /restore, incluyendo un argumento "passfile" que especifique la ruta a un archivo ".pgpass [.pgpass]" ("/opt/splunk/var/packages/data/postgres/.pgpass") que contenga la contraseña del usuario "postgres_admin"
* Las consultas SQL definidas en el volcado de la base de datos serán ejecutadas por la instancia PostgreSQL de Splunk

Un atacante podría aprovechar esta debilidad para definir una nueva función que utilice lo_export (una función utilizada para extraer un BLOB de la base de datos y guardarlo como un archivo en el sistema de archivos) para escribir contenido controlado por el atacante en un archivo, tras lo cual la función se ejecuta durante el proceso de restauración.

"En este punto, podemos autenticarnos, restaurar SQL controlado por el atacante e interactuar con la base de datos local", dijeron los investigadores de seguridad Piotr Bazydlo y Yordan Ganchev. "Una vez que pudimos restaurar SQL controlado por el atacante en la instancia local de PostgreSQL, armamos rápidamente una plantilla de volcado de base de datos que nos permitió una escritura de archivo controlada".

Armado con una primitiva de escritura de archivos arbitrarios en el sistema de archivos de Splunk, un atacante podría escalar más allá hasta la ejecución remota de código sobrescribiendo un script de Python que Splunk ejecuta frecuentemente (por ejemplo, "/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py") para incluir el payload malicioso.

Toda la secuencia de acciones es la siguiente:

* Crear una base de datos y configurarla de modo que un usuario pueda autenticarse sin contraseña y concederle permisos suficientes para invocar funciones como lo_export
* Usar el endpoint /backup para dejar un volcado de la base de datos remota en el sistema de archivos de Splunk
* Usar el endpoint /restore para cargar el volcado de la base de datos maliciosa, activar la ejecución de la función maliciosa durante el proceso de restauración y escribir un script de Python controlado por el atacante en el sistema de archivos de Splunk

Aunque no hay evidencia de que el fallo haya sido explotado en la naturaleza, la disponibilidad de los detalles del exploit puede ser suficiente para impulsar a los actores de amenazas a realizar intentos oportunistas. Es fundamental que te apresures a aplicar las correcciones para mantenerte protegido.

Fuente:
THN