El endpoint Postgres de Splunk Enterprise que viene sin autenticacion y termina en RCE

Contexto del incidente

El 18 de junio de 2026 CISA sumo el CVE-2026-20253 al catalogo KEV con fecha de remediacion BOD 26-04 que vence el 21 de junio, apenas tres dias. La vulnerabilidad fue divulgada por Splunk el 10 de junio en el advisory SVD-2026-0603 y el viernes 13 de junio los investigadores de watchTowr Labs publicaron la cadena completa de explotacion que convierte el bug en RCE pre-autenticado. CVSS 9.8 (Critical) con vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H y CWE-306 (Missing Authentication for Critical Function).

El problema vive en el sidecar de PostgreSQL que Splunk introdujo a partir de la version 10. Es un proceso auxiliar (binario splunk-postgres, unos 66 MB en Go) que escucha en loopback el puerto 5435 para la base Postgres y el 33669 para su propia API HTTP. La API interna expone /v1/postgres/recovery/backup y /v1/postgres/recovery/restore sin ninguna autenticacion, y la UI web de Splunk (puerto 8000) hace de proxy reverso hacia esos endpoints reenviando las requests tal cual, sin agregar headers ni chequeos. El resultado: cualquier persona que llega al puerto 8000 de tu instancia Splunk puede pegarle a la API del sidecar sin haberse logueado.

El detalle que vuelve esto una bomba es que ambos endpoints delegan a pg_dump y pg_restore con argumentos que vienen del cuerpo del request, y libpq interpreta el parametro database como cadena de conexion completa. Eso habilita hostaddr=atacante.com para apuntar el dump a una base controlada por el atacante, y passfile=/opt/splunk/var/packages/data/postgres/.pgpass para reutilizar el archivo de credenciales en texto plano que el sidecar tiene sembrado. Combinado con un SQL malicioso que use lo_export() para escribir un archivo arbitrario, el flujo termina en overwrite de un script Python que Splunk corre por scheduler y, ahi, RCE como el usuario splunk. Splunk Cloud no esta afectado (no usa Postgres sidecars), pero Splunk Enterprise on AWS viene con el sidecar habilitado por defecto, asi que el universo de instancias vulnerables sin parchar es enorme.

Una pieza de software que recolecta los logs de toda tu organizacion y termina siendo el eslabon mas debil de la cadena.

Como proteger tu infraestructura?

1. Parche Splunk Enterprise a 10.2.4 o 10.0.7 cuanto antes

Es el fix completo. Splunk Enterprise 10.2.0 a 10.2.3 y 10.0.0 a 10.0.6 son las versiones afectadas; 10.4.0 y las 9.x no entran en la lista. La rama 9.4 y 9.3 no tienen el sidecar Postgres, asi que no necesitan parche. Si corres Splunk Cloud, no tenes que hacer nada del lado de la plataforma, pero si adentro de tu tenant tenes Secure Gateway con la app sin actualizar, el CVE-2026-20251 (companion, CVSS 8.8, deserializacion insegura via jsonpickle) si te toca. La guia completa de versiones esta en la seccion Solution del advisory SVD-2026-0603.

2. Si no podes parchear ya, deshabilita el sidecar Postgres

Edita $SPLUNK_HOME/etc/system/local/server.conf y agrega el bloque [postgres] disabled = true. Despues reinicia Splunk. Cuidado: no apliques este workaround si tu instancia usa Edge Processor, OpAmp o pipelines SPL2, porque las rompes. Para esos casos, la opcion es la mitigacion de red del punto siguiente. Si deshabilitas el sidecar, la busqueda core, el indexado y los dashboards siguen funcionando normal, asi que en la mayoria de los deployments lo unico que se pierde es el backup/restore interno del sidecar (que el 90% de las organizaciones no usa).

3. Bloquea el endpoint a nivel de red y monitoreo

Hasta que parchees, ninguna pieza de tu red que no sea el propio proceso de Splunk tiene que poder llegar a /en-US/splunkd/__raw/v1/postgres/recovery/. ACL en el WAF o en el reverse proxy que tengas delante del puerto 8000 (HAProxy, F5, CloudFront con WAF, etc.) que dropee cualquier request a esos paths. Y fundamental: levanta una alerta en tu SIEM o IDS por conexiones salientes al puerto 5432 desde el host de Splunk. La fase 2 de la cadena (el dump contra la base del atacante) requiere que Splunk haga una conexion TCP saliente al Postgres del atacante; ese egreso es anomalo y detectable con una regla de Suricata o con un dashboard basico en el mismo Splunk (auto-monitoreo) que liste netstat -an | grep :5432 con estado ESTABLISHED y origen el host local.

4. Parchea el companion CVE-2026-20251 (jsonpickle)

En el mismo batch de advisories del 10 de junio Splunk libero SVD-2026-0601 con CVE-2026-20251 (CVSS 8.8). Este vive en la app Splunk Secure Gateway y es una deserializacion insegura de jsonpickle en el KV Store: un usuario con cualquier rol (no necesita admin) puede inyectar clases Python arbitrarias y terminar ejecutando codigo. Si no podes actualizar la app a 3.10.6 / 3.9.20 / 3.8.67 hoy, el workaround oficial es desinstalar la app. Antes de sacarla, asegurate de que ninguna de tus busquedas dependa de los features de Secure Gateway (mobile access, dashboard sharing).

Indicadores de compromiso (IoC)

Estos son los artefactos y senales concretas que tenes que cazar en logs de tu SIEM, EDR, WAF y file integrity monitor para detectar intentos de explotacion del CVE-2026-20253 o comprometimiento en curso. La cadena tiene tres senales fuertes que son faciles de alertar: el path traversal contra el endpoint de backup, el egreso Postgres anomalo, y la modificacion de scripts Python bajo /opt/splunk/etc/apps/.

• Endpoint de backup con Authorization vacio: POST /en-US/splunkd/__raw/v1/postgres/recovery/backup con header Authorization: Basic Og== (que decodea a :, usuario y password vacios). Es la firma exacta del detection artifact generator de watchTowr y la forma mas limpia de saber si tu instancia esta expuesta.
• Path traversal en el parametro backupFile: requests con "backupFile": "../../../../../../../../../tmp/<archivo>" o rutas absolutas hacia /opt/splunk/etc/apps/. Splunk no canonicaliza el path antes de pasarselo a pg_dump -f.
• Conexion saliente al puerto 5432 desde el host de Splunk: en condiciones normales el proceso splunk-postgres solo habla con su propia base local. Si ves un ESTABLISHED hacia una IP publica en 5432, alguien esta cursando la fase 2 del ataque (dumpear una base controlada).
• Modificacion de /opt/splunk/etc/apps/*/bin/*.py fuera de ventanas de upgrade: el script que Splunk corre por scheduler es /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Cualquier write ahi, o a cualquier bin/<script>.py dentro de apps cargadas, es senal de RCE consumado.
• Presencia del archivo .pgpass en /opt/splunk/var/packages/data/postgres/: formato *:*:*:postgres_admin:<hash> en texto plano. El archivo existe legitimo, pero si lo lee un proceso externo al sidecar es senal de la fase 3 del ataque en curso.
• Tabla con CHECK constraint que llama a lo_export(): si tu DBA Splunk audita el catalogo de Postgres y encuentra funciones definidas por usuarios que envuelven lo_from_bytea() + lo_export() en un CHECK, es la firma exacta del payload que watchTowr documenta.

# 1) Detectar exposicion del endpoint (watchTowr DAG, safe to run)
#    Devuelve 400 + "Failed to decode" = vulnerable
curl -sk -X POST \
  -H "Authorization: Basic ZGFnOg==" \
  -H "Content-Type: application/json" \
  -d '{"database":"search_metadata","backupFile":"backuptest"}' \
  https://tu-splunk.example.com:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup

# 2) Regla Suricata para el egreso Postgres anomalo desde el host Splunk
alert tcp $SPLUNK_HOST any -> !$SPLUNK_NET 5432 (msg:"CVE-2026-20253 Splunk egreso Postgres saliente"; flow:to_server,established; classtype:trojan-activity; sid:2026202531; rev:1;)

# 3) SPL para cazar el patron del attack chain en tu propio Splunk
index=_internal source=*splunkd_access.log
  uri_query="*postgres/recovery/backup*" OR uri_query="*postgres/recovery/restore*"
| stats count values(Authorization) as auth_headers values(clientip) as src_ips
        values(uri_query) as queries
  by uri_path status
| where status=200 AND mvcount(auth_headers)=1 AND auth_headers="$SPLUNKD_EMPTY_BASIC$"

# 4) FIM: tripwire/auditd sobre /opt/splunk/etc/apps/*/bin/*.py
#    Cualquier write a *.py fuera de un upgrade legit dispara alerta
auditctl -w /opt/splunk/etc/apps -p wa -k splunk-app-pymod
ausearch -k splunk-app-pymod | grep -E "syscall=(2|82|open|creat|truncate|rename)" | grep "\.py"