Splunk Enterprise: RCE pre-auth vía PostgreSQL sidecar sin autenticación (CVE-2026-20253)

Contexto del incidente

El 10 de junio de 2026 Splunk publicó el advisory SVD-2026-0603 describiendo CVE-2026-20253, una vulnerabilidad de Missing Authentication for Critical Function (CWE-306) en el servicio PostgreSQL sidecar que se instala junto a Splunk Enterprise. El endpoint expuesto para operaciones de archivo no implementa ningún control de autenticación: cualquier host capaz de alcanzarlo por red puede crear o truncar archivos en el sistema de archivos del servidor Splunk. El NVD y el vendor asignan CVSS v3.1 = 9.8 con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, es decir: red, baja complejidad, sin privilegios, sin interacción del usuario e impacto total en confidencialidad, integridad y disponibilidad.

El 18 de junio CISA agregó el CVE a su catálogo Known Exploited Vulnerabilities con fecha de remediación federal 21 de junio (ya vencida al cierre de este post), lo que la convierte en una de las prioridades operativas más altas para cualquier agencia o contractor que use Splunk. Splunk PSIRT confirmó además que existe explotación limitada en producción y los laboratorios watchTowr publicaron un análisis técnico con prueba de concepto que demuestra cómo la primitiva de file-write se convierte en RCE. El alcance afectado es estrecho pero crítico: sólo ramas 10.0.x y 10.2.x de Splunk Enterprise (10.0.0 a 10.0.6 y 10.2.0 a 10.2.3). Las versiones 9.4 y anteriores no incluyen el sidecar PostgreSQL y no están afectadas. Splunk Cloud tampoco está afectada — Splunk aclaró que el sidecar no se despliega en la plataforma cloud gestionada.

Un SIEM que no podés parchar a tiempo no sólo pierde visibilidad: se convierte en el primer pivote hacia el resto de tu red.

¿Cómo proteger tu infraestructura?

1. Aplicá el parche sin demora

Subí Splunk Enterprise a 10.0.7 o 10.2.4 según la rama que corras. Verificá la versión con $SPLUNK_HOME/bin/splunk version desde una shell del propio servidor (no desde la UI web, que puede quedar enganchada a una versión cacheada). Si administrás una flota distribuida, priorizá los deployment servers, los indexers con ingestión desde Internet y los search heads con acceso de analistas externos. El upgrade se puede hacer en caliente sobre una instancia single-node, pero en clústeres indexer seguí el procedimiento rolling de Splunk para no perder shards.

2. Si no podés parchear ya, desactivá el sidecar PostgreSQL

Splunk documenta una mitigación oficial: editar $SPLUNK_HOME/etc/system/local/server.conf y agregar la stanza [postgres] con disabled = true. Reiniciá el servicio con ./splunk restart y verificá que el puerto del sidecar (por defecto 5432 o el alternativo configurado en postgres_host/postgres_port) ya no esté abierto. Atención: no apliques esta mitigación si usás Edge Processor, OpAmp o pipelines de datos SPL2, porque dependen del sidecar. En ese caso la única salida válida es el upgrade.

3. Segmentá el acceso de red al puerto del sidecar

El sidecar PostgreSQL no debería estar reachable más allá del propio host. Bloqueá el puerto en el firewall perimetral y en las security groups de cloud con una regla que sólo permita 127.0.0.1 o el segmento de red de la red de management. Si el Splunk está detrás de un load balancer, asegurate de que el sidecar no esté publicado hacia Internet (un check rápido: curl -v telnet://<tu-splunk>:5432 desde una red externa debe dar connection refused). Adicionalmente, exigí TLS en cualquier forwarding entre forwarders y el indexer.

4. Monitoreá señales específicas del sidecar en tus logs

Activá el logging de splunkd_ui_access y splunkd_access con level = INFO en log.cfg. Buscá conexiones al puerto PostgreSQL desde IPs que no sean 127.0.0.1, intentos repetidos a /services/postgres/... o respuestas con código HTTP 200 a operaciones de lo_export. Una consulta SPL útil para cazar file-writes sospechosos en el propio Splunk es index=_internal source=*splunkd.log* "postgres" | stats count by host, uri_path, status. Sumá una alerta que dispare si el conteo de status=200 para endpoints postgres supera 5 por minuto desde una IP que no es localhost.

Indicadores de compromiso (IoC)

El vector de ataque se basa en operaciones de archivo desde una IP remota hacia el puerto del sidecar. Estos son los indicadores accionables que podés cruzar con tu SIEM, tu EDR y tus firewalls para detectar tanto un exploit en curso como una posible post-explotación.

• Endpoint vulnerable: https://<splunk-host>:8089/services/postgres/lo_export (o el puerto configurado en postgres_port dentro de server.conf). Cualquier acceso desde una IP que no sea 127.0.0.1 o el segmento de management es malicioso por definición.
• Path de escritura abusado: $SPLUNK_HOME/var/run/splunk/apptemp/ y rutas bajo $SPLUNK_HOME/bin/scripts/ o $SPLUNK_HOME/etc/apps/<app>/bin/. Splunk ejecuta scripts en estos paths en contexto del servicio splunkd, así que un archivo colocado ahí se ejecuta con los privilegios del usuario de Splunk.
• Función PostgreSQL abusada: lo_export(lo_oid, '/path/a/script.sh') combinado con grandes objetos creados vía lo_creat + lowrite. Conexiones al puerto del sidecar con un volumen anormal de operaciones lo_creat/lo_export son la firma más limpia del ataque.
• User-Agent y firma HTTP: los PoC públicos (watchTowr, Horizon3) usan python-requests o curl/8.x con verbos POST sobre el endpoint. Si tenés el sidecar expuesto, buscá en splunkd_access.log requests con User-Agent distinto a Splunkd y método POST sobre /services/postgres.

# SPL query para Splunk — corre esto en tu instancia UNA VEZ parchada
# para validar si tu entorno fue escaneado/explotado durante la ventana vulnerable
index=_internal source="*splunkd_access.log" uri_path="*/services/postgres*"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(clientip) as client_ips values(status) as statuses
        values(useragent) as user_agents
  by host uri_path
| where client_ips != "127.0.0.1" AND client_ips != "::1"
| sort -count
| head 50

# Regla Suricata de detección perimetral (bloquea el vector pre-auth)
alert http any any -> $SPLUNK_SERVERS any (msg:"CVE-2026-20253 Splunk postgres sidecar lo_export";
  flow:to_server,established; http.method; content:"POST";
  http.uri; content:"/services/postgres/lo_export"; nocase;
  classtype:web-application-attack; sid:202620253; rev:1;)