CVE-2026-20253: el sidecar de PostgreSQL que dejó sin autenticación a Splunk Enterprise

Splunk Enterprise es, para buena parte de los equipos de seguridad del mundo, la plataforma sobre la que se construye la detección: ingesta logs, correlaciona eventos y alimenta los SOC que deberían avisar cuando algo va mal. En junio de 2026 se confirmó que esa misma plataforma tenía una vulnerabilidad crítica que permitía a un atacante no autenticado escribir archivos arbitrarios en el sistema y, encadenando el fallo, ejecutar código remoto. El caso es CVE-2026-20253, y su recorrido (desde la publicación del parche hasta la explotación activa confirmada por CISA) es un ejemplo bastante limpio de cuánto tiempo real tienen hoy los defensores entre un aviso y un ataque.

Dónde está el fallo

Según el aviso oficial de Splunk (SVD-2026-0603), el problema afecta a Splunk Enterprise 10.2.0–10.2.3 y 10.0.0–10.0.6, con una puntuación CVSSv3.1 de 9.8 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Las versiones 9.4 y anteriores no están afectadas. La causa raíz, catalogada como CWE-306 (ausencia de autenticación en una función crítica), reside en el servicio sidecar de PostgreSQL que Splunk introdujo para soportar funciones internas como Edge Processor, OpAmp y las canalizaciones de datos SPL2.

Ese sidecar escucha en el puerto 5435 y, en teoría, solo debería ser accesible localmente. El problema es que la interfaz web pública de Splunk reenvía peticiones hacia endpoints internos de recuperación de PostgreSQL, como /en-US/splunkd/__raw/v1/postgres/recovery/backup. Esos endpoints exigen una cabecera de autorización HTTP Basic, lo que sugiere que hacen falta credenciales, pero, según describieron varios investigadores que analizaron el aviso (entre ellos Picus Security y el equipo de SecureLayer7), el sidecar acepta cualquier credencial, incluidas vacías, porque no valida nada por su cuenta: se limita a pasar el usuario recibido a herramientas de PostgreSQL como pg_dump.

De escritura de archivos a ejecución de código

El aviso de Splunk describe el fallo como creación o truncado arbitrario de archivos sin autenticación. Pero un atacante puede ir más allá manipulando parámetros de la cadena de conexión de PostgreSQL (como hostaddr y passfile) para forzar a la instancia de Splunk a conectarse a una base de datos controlada por el propio atacante. Desde ahí es posible importar SQL malicioso y convertir la primitiva de escritura de archivos en ejecución remota de código con los privilegios del usuario de Splunk.

Ese salto de "escritura de archivos" a "RCE completo" no lo hizo público Splunk, sino WatchTowr Labs, que el 12 de junio de 2026 (dos días después de que Splunk publicara los parches) difundió un análisis técnico junto con una prueba de concepto funcional. Es un patrón que se repite con frecuencia: el fabricante documenta el impacto de forma conservadora y son investigadores externos quienes demuestran hasta dónde llega realmente el fallo, acortando de facto la ventana de la que disponen los equipos para parchear antes de que exista un exploit utilizable.