Splunk Enterprise CVE-2026-20253 (CVSS 9.8): RCE sin autenticación en el SIEM que monitoriza toda tu infraestructura

Splunk Enterprise, la plataforma SIEM y de observabilidad de seguridad más extendida en entornos corporativos, tiene una vulnerabilidad crítica de ejecución remota de código sin autenticación. CVE-2026-20253 (CVSS 9.8) fue publicada el 10 de junio de 2026 en el advisory oficial SVD-2026-0603 de Splunk. La causa raíz: los endpoints del servicio PostgreSQL Sidecar de Splunk Enterprise no tienen controles de autenticación, lo que permite a cualquier usuario con acceso a la red invocar operaciones de fichero sin credenciales y, en una cadena de explotación documentada por watchTowr Labs y Orca Security, escalar a ejecución remota de código completa en el servidor. Las versiones afectadas son Splunk Enterprise 10.0.0 a 10.0.6 (fijado en 10.0.7) y 10.2.0 a 10.2.3 (fijado en 10.2.4). Splunk Cloud no está afectado. El PoC técnico completo está siendo amplificado hoy — la ventana para parchear antes de que un exploit público esté ampliamente disponible se está cerrando.

‍

¿Qué se sabe de CVE-2026-20253 y la cadena de RCE pre-autenticada?

Los hechos documentados por Splunk (advisory SVD-2026-0603), watchTowr Labs, Orca Security, GBHackers, The Hacker News, SecurityWeek y The Cyber Express son los siguientes:

• Vulnerabilidad: ausencia total de controles de autenticación (CWE-306: Missing Authentication for Critical Function) en el servicio PostgreSQL Sidecar de Splunk Enterprise. Los endpoints HTTP /v1/postgres/recovery/backup y /v1/postgres/recovery/restore son accesibles por cualquier usuario con acceso a la red sin necesidad de credenciales.
• CVSS 9.8 (Critical): vector de ataque de red, sin privilegios previos, sin interacción del usuario, confidencialidad e integridad completamente comprometidas.
• Versiones afectadas: Splunk Enterprise 10.0.0 a 10.0.6 (parcheado en 10.0.7) y 10.2.0 a 10.2.3 (parcheado en 10.2.4). El componente PostgreSQL Sidecar fue introducido en Splunk Enterprise v10, por lo que versiones anteriores a la 10.x no están afectadas.
• Splunk Cloud NO está afectado: la plataforma gestionada de Splunk no utiliza PostgreSQL sidecars, por lo que las organizaciones con Splunk Cloud están a salvo de CVE-2026-20253.
• Splunk Enterprise en AWS es el caso de mayor riesgo: el PostgreSQL Sidecar Service está habilitado y activo por defecto en los despliegues de Splunk Enterprise en AWS, lo que hace que esas instancias sean vulnerables sin necesidad de ninguna configuración adicional.
• Acceso a través del proxy de Splunk: aunque el servicio PostgreSQL Sidecar escucha en localhost, es accesible desde el exterior a través del mecanismo de proxy de la interfaz web principal de Splunk. Cualquier atacante que llegue al puerto web de Splunk puede alcanzar estos endpoints vulnerables.
• CVEs adicionales publicados en el mismo advisory: CVE-2026-20251 (CVSS 8.8): RCE mediante deserialización insegura de datos del App Key Value Store (KV Store) a través de la librería Python jsonpickle en la aplicación Splunk Secure Gateway. Requiere un usuario con privilegios bajos. CVE-2026-20258: XSS y SSRF en Splunk Secure Gateway.

‍

Por qué comprometer el SIEM es comprometer la seguridad de toda la organización

CVE-2026-20253 no es una vulnerabilidad en un servidor web o una base de datos periférica. Splunk Enterprise es el SIEM — el sistema donde converge toda la telemetría de seguridad de la organización. Comprometer Splunk con acceso de ejecución de código tiene implicaciones que van mucho más allá del servidor en sí:

1. Un atacante con RCE en Splunk tiene acceso a todos los logs de seguridad. Splunk ingiere logs de firewalls, endpoints, servidores de autenticación, aplicaciones críticas y sistemas de nube. Con ejecución de código en el servidor, un atacante puede leer, exfiltrar o manipular toda esa telemetría.
2. El atacante puede cegar al equipo SOC. Splunk es la consola desde la que el equipo de seguridad detecta y responde a incidentes. Un atacante con RCE puede eliminar o alterar logs, desactivar alertas, modificar dashboards y, en definitiva, operar de forma invisible dentro de la red mientras el SOC ve lo que el atacante quiere que vea.
3. Las credenciales de integración de Splunk son claves de acceso a toda la infraestructura. Splunk se conecta mediante API keys y tokens a todos los sistemas que monitoriza: Cloud providers (AWS, Azure, GCP), Active Directory, sistemas ITSM, herramientas de ticketing, pipelines de CI/CD. El servidor de Splunk almacena o referencia todas esas credenciales. Con RCE, un atacante puede exfiltrarlas todas.
4. Acceso al archivo .pgpass. La cadena de explotación documentada por watchTowr Labs incluye el acceso al archivo .pgpass de PostgreSQL, que almacena credenciales de base de datos en texto plano. Estas credenciales pueden proporcionar acceso directo a la base de datos de configuración de Splunk y a todos los datos almacenados en ella.

‍

Cómo funciona la cadena de explotación de CVE-2026-20253

La cadena de explotación completa, documentada por watchTowr Labs y Orca Security, sigue estos pasos:

1. Acceso a los endpoints sin autenticación. El atacante envía peticiones HTTP a los endpoints vulnerables del servicio PostgreSQL Sidecar (/v1/postgres/recovery/backup y /v1/postgres/recovery/restore) a través del proxy de la interfaz web de Splunk. No se requieren credenciales.
2. Escritura de archivos arbitrarios mediante lo_export. Los endpoints de backup y restore interactúan con PostgreSQL, lo que permite al atacante abusar de la función lo_export de PostgreSQL, que extrae un BLOB (Binary Large Object) de la base de datos y lo guarda como un archivo en el sistema de ficheros del servidor. El atacante puede crear un BLOB con contenido malicioso y exportarlo a cualquier ruta del sistema de ficheros con los permisos del proceso Splunk.
3. Escalada a RCE mediante sobrescritura de scripts Python. Splunk ejecuta scripts Python para múltiples funciones internas. Sobrescribiendo un script Python que Splunk ejecuta con contenido controlado por el atacante, el código malicioso se ejecuta en el contexto del proceso de Splunk en la próxima ejecución del script.
4. Acceso a credenciales vía .pgpass. Como paso adicional, el atacante puede leer el archivo .pgpass de PostgreSQL, obteniendo las credenciales de la base de datos de Splunk en texto plano.

‍

Lecciones clave y checklist de mitigación para administradores de Splunk Enterprise

Paso 1 — Verificar exposición (inmediato):

• Confirmar la versión de Splunk Enterprise instalada. Si es 10.0.0-10.0.6 o 10.2.0-10.2.3, la instancia es vulnerable. Versiones anteriores a 10.x no tienen el componente PostgreSQL Sidecar y no están afectadas.
• Verificar si el PostgreSQL Sidecar Service está activo: $SPLUNK_HOME/bin/splunk status splunk-postgresql-sidecar. En despliegues on-premise no necesariamente está activo por defecto, pero en AWS sí.
• Verificar si los endpoints vulnerables son accesibles desde redes no confiables a través del proxy de Splunk.

Paso 2 — Actualización urgente (acción prioritaria):

• Actualizar Splunk Enterprise a la versión 10.0.7 o superior (para la rama 10.0.x), o a 10.2.4 o superior (para la rama 10.2.x). Consultar el advisory SVD-2026-0603 en advisory.splunk.com para los paquetes de actualización.
• Junto a CVE-2026-20253, aplicar también los parches para CVE-2026-20251 (RCE en Secure Gateway) y CVE-2026-20258 (XSS/SSRF) que se incluyen en las mismas versiones corregidas.

Paso 3 — Mitigaciones temporales si el parcheo no puede realizarse hoy:

• Deshabilitar el PostgreSQL Sidecar Service si no es operativamente necesario: $SPLUNK_HOME/bin/splunk disable splunk-postgresql-sidecar.
• Bloquear el acceso a los endpoints vulnerables mediante un WAF o reglas de red que impidan el acceso a las rutas /v1/postgres/recovery/* desde redes no confiables.
• Aislar Splunk de acceso externo directo si la arquitectura no lo requiere: Splunk no debería ser accesible desde internet en la mayoría de los entornos corporativos.

Paso 4 — Investigación forense (si el sistema pudo estar expuesto desde el 10 de junio):

• Revisar los access logs del servidor web de Splunk en busca de peticiones a los endpoints /v1/postgres/recovery/backup y /v1/postgres/recovery/restore desde el 10 de junio.
• Auditar el sistema de ficheros del servidor en busca de archivos creados o modificados recientemente en rutas donde el proceso Splunk tiene permisos de escritura.
• Verificar la integridad de los scripts Python en el directorio de Splunk en busca de modificaciones no autorizadas.
• Revisar el archivo .pgpass de PostgreSQL y rotar las credenciales si hay indicios de compromiso.

‍

La ciberseguridad como prioridad estratégica

CVE-2026-20253 en Splunk Enterprise es un recordatorio de que las herramientas de seguridad también son superficie de ataque. Un SIEM con una vulnerabilidad crítica de RCE no protege a la organización — es el vector por el que la organización puede ser comprometida de forma completa e invisible. El DBIR 2026, que analizamos hace tres semanas, confirmó que las vulnerabilidades sin parchear son el vector #1 de brechas. CVE-2026-20253 es la manifestación más directa de ese patrón: un componente introducido en Splunk v10 sin controles de autenticación, publicado el 10 de junio con detalle técnico completo, con PoC amplificándose hoy. Las organizaciones españolas que usan Splunk Enterprise on-premise tienen un plazo muy corto antes de que la barrera técnica de explotación caiga a cero.

‍

Apolo Cybersecurity: evaluación y protección de entornos Splunk Enterprise ante CVE-2026-20253

En Apolo Cybersecurity ayudamos a organizaciones con Splunk Enterprise a verificar la exposición ante CVE-2026-20253: verificación del estado de la versión instalada y del servicio PostgreSQL Sidecar, aplicación urgente del parche SVD-2026-0603, implementación de mitigaciones temporales mientras se planifica la actualización, revisión forense de logs de acceso desde el 10 de junio, y evaluación de la segmentación de red alrededor de la infraestructura Splunk.

Si tu organización usa Splunk Enterprise 10.x on-premise y no has aplicado la actualización a 10.0.7 o 10.2.4, este lunes por la mañana es el momento de hacerlo. El sistema que debería detectar los ataques no puede ser el vector de entrada.

‍