Introducción
En el ecosistema de la seguridad corporativa, las plataformas SIEM son el núcleo del centro de operaciones: consolidan registros de eventos, detectan comportamientos anómalos y ofrecen a los equipos SOC visibilidad sobre todo el perímetro digital. Precisamente por eso, la vulnerabilidad CVE-2026-20253, divulgada públicamente el 12 de junio de 2026, exige atención inmediata. Afecta a Splunk Enterprise —una de las plataformas SIEM más extendidas en organizaciones empresariales— y permite a un atacante no autenticado ejecutar código arbitrario en el servidor objetivo. Puntuación CVSS: 9.8.
Un componente interno desplegado sin protección
La cadena de explotación gira en torno a un servicio auxiliar introducido con Splunk Enterprise versión 10: el PostgreSQL Sidecar. Este componente gestiona las operaciones de copia de seguridad y restauración de la base de datos interna mediante una API HTTP que expone los endpoints /v1/postgres/recovery/backup y /v1/postgres/recovery/restore. El problema es de diseño: no existe ninguna verificación de identidad a nivel de aplicación. La autenticación queda delegada íntegramente a la propia capa de base de datos, generando una brecha estructural entre ambos niveles.
El servicio escucha en puertos internos vinculados a la interfaz local, pero es accesible desde el exterior a través del puerto 8000 de la interfaz web de Splunk, que actúa como proxy transparente. Cualquier atacante con acceso a la interfaz de administración puede interactuar con este servicio sin necesidad de proporcionar ninguna credencial.
Una cadena de ataque en cuatro pasos, sin cuenta necesaria
El laboratorio watchTowr Labs documentó una cadena de ataque completa. En el primer paso, el atacante envía una solicitud al endpoint de copia de seguridad inyectando un parámetro de conexión PostgreSQL que apunta a un servidor bajo su control: el campo database acepta cadenas de conexión completas, incluido el parámetro hostaddr, que reemplaza la dirección de destino predeterminada.
Desde ese servidor malicioso, el atacante puede restaurar un volcado que contiene funciones PL/pgSQL diseñadas para escribir archivos arbitrarios en el sistema anfitrión. El paso siguiente consiste en recuperar las credenciales locales almacenadas en un archivo .pgpass, suficientes para autenticarse en la base de datos local de Splunk. Por último, la sobreescritura de un script Python ejecutado periódicamente por la plataforma deriva en ejecución de código bajo el usuario splunk. Sin escalada de privilegios previa, sin cuenta en la plataforma: basta con acceso de red al puerto 8000.
AWS, especialmente expuesto por defecto
Un factor diferencial distingue esta vulnerabilidad de las habituales: el servicio PostgreSQL Sidecar se activa por defecto en los despliegues de Splunk Enterprise sobre AWS, pero permanece inactivo o ausente en la mayoría de las instalaciones on-premise sobre Windows. Los entornos cloud quedaron expuestos desde el momento de la puesta en marcha, sin que los equipos operadores tuvieran que realizar ninguna acción adicional.
Este detalle ilustra un riesgo frecuentemente subestimado: la superficie de ataque de un despliegue en la nube puede diferir significativamente de su equivalente on-premise, incluso para el mismo proveedor y el mismo producto. Las políticas de bastionado concebidas para servidores físicos no se trasladan automáticamente al entorno cloud, y los componentes activados por defecto en entornos gestionados merecen una auditoría específica.
Implicaciones para los equipos de seguridad
Splunk publicó versiones corregidas el 10 de junio de 2026: las ramas 10.4.0, 10.2.4, 10.0.7, 9.4.12 y 9.3.13 incorporan el parche. La actualización es prioritaria para cualquier organización que opere Splunk sobre AWS, donde el servicio estaba activo sin que los equipos lo supieran necesariamente.
Más allá del parche inmediato, este incidente recuerda que las herramientas de seguridad deben someterse al mismo nivel de rigor que cualquier componente crítico: inventario de servicios expuestos, auditoría de endpoints internos y verificación de que la arquitectura de autenticación no delega responsabilidades en subcomponentes sin filtrar. Vigilar todo el entorno tecnológico no es suficiente si la propia herramienta de vigilancia no está blindada.