MagnoSec
Panel de control de Splunk Enterprise mostrando alertas de seguridad y logs de sistema comprometido por CVE-2026-20253

MagnoSec Blog

Splunk Enterprise RCE sin Autenticación: CVE-2026-20253 en Explotación Activa y CISA Exige Parche Inmediato

Por Equipo MagnoSec5 min de lectura

El contexto: qué ha pasado y por qué importa

Splunk Enterprise es el SIEM más desplegado del mundo. Gobiernos, bancos, telecos, hospitales y equipos SOC dependen de él para centralizar logs, detectar amenazas y responder a incidentes. Por eso, cuando aparece una vulnerabilidad que permite a un atacante remoto ejecutar código en un Splunk Enterprise sin necesidad de credenciales, el impacto no se mide en servidores individuales sino en la capacidad de detección de organizaciones enteras. CVE-2026-20253 es exactamente ese escenario: un fallo en el endpoint del servicio PostgreSQL sidecar de Splunk que carece de controles de autenticación, permitiendo que cualquier persona con conectividad de red hacia el servidor pueda crear o truncar archivos arbitrarios en el sistema. La explotación activa ya está confirmada por el propio Splunk PSIRT, y CISA ha elevado la vulnerabilidad a su catálogo KEV (Known Exploited Vulnerabilities) con fecha límite de parcheo este domingo.

Antecedentes y evolución de la amenaza

El componente vulnerable no es el Splunk Web frontal que todos los analistas conocen, sino el servicio PostgreSQL sidecar que se ejecuta en segundo plano en los Splunk Enterprise a partir de la versión 10.0.0. Este servicio está diseñado para dar soporte a funcionalidades como Edge Processor, OpAmp y pipelines de datos SPL2, pero el endpoint expuesto no implementa ningún mecanismo de autenticación. Cualquier atacante que pueda alcanzar la red del servidor Splunk puede invocar operaciones de archivos —creación, truncado, modificación— sin presentar credenciales. La investigadora de watchTowr publicó una prueba de concepto funcional el 12 de junio demostrando cómo esta capacidad de manipulación de archivos se traduce en ejecución remota de código, y desde entonces Shadowserver ha identificado aproximadamente 1.400 instancias de Splunk expuestas a internet, 952 de ellas en Norteamérica y 223 en Europa.

Así funciona: los detalles técnicos

El mecanismo de explotación es quirúrgico. El servicio sidecar de PostgreSQL acepta comandos de manipulación de archivos a través de un endpoint de red que, al no requerir autenticación, puede ser invocado por cualquier cliente con conectividad TCP hacia el puerto correspondiente. Un atacante puede utilizar esta capacidad para sobrescribir archivos de configuración de Splunk, inyectar complementos maliciosos en los directorios de apps, o manipular scripts ejecutables que Splunk carga durante su ciclo de operación normal. Dado que Splunk Enterprise se ejecuta típicamente con privilegios elevados para acceder a logs del sistema y fuentes de datos diversas, la ejecución de código obtenida hereda ese nivel de privilegio. En entornos donde Splunk está integrado con Active Directory para autenticación de analistas, el compromiso del servidor SIEM puede convertirse en el primer paso de un ataque de movimiento lateral hacia los controladores de dominio.

Impacto real en organizaciones y empresas

Para un atacante, comprometer el SIEM de una organización no es simplemente comprometer un servidor más: es obtener el mapa completo de la infraestructura, los logs de autenticación de todos los sistemas, las direcciones IP internas, los nombres de usuario y en muchos casos las configuraciones de seguridad de firewalls, endpoints y sistemas de detección. Con acceso al Splunk, el atacante sabe exactamente qué está siendo monitorizado y qué no, qué umbrales de alerta están configurados y qué actividad pasaría desapercibida. Es el equivalente a robar el plano del sistema de alarma antes de entrar a un edificio. Peor aún: si el atacante decide no explotar el acceso inmediatamente sino mantener persistencia silenciosa, puede modificar las consultas de búsqueda y las alertas programadas para crear puntos ciegos que utilizará en futuras fases del ataque. La víctima cree que su SIEM está funcionando mientras el atacante opera dentro de los huecos que él mismo ha creado.

Cómo MagnoSec aborda esta amenaza en sus auditorías

En MagnoSec, las auditorías de infraestructura que realizamos incluyen la verificación sistemática de la superficie de exposición de los sistemas de monitorización y gestión. Splunk, Elastic, Grafana, PRTG, Nagios y herramientas similares son objetivos de alto valor para un atacante porque concentran visibilidad y suelen tener conectividad privilegiada con el resto de la infraestructura. Durante nuestros ejercicios de red team y pentesting de infraestructura, la identificación de un SIEM expuesto en un segmento de red accesible es un hallazgo crítico que documentamos con prioridad máxima. La segmentación de red adecuada —aislando los sistemas de gestión y monitorización en una red de administración separada, inaccesible desde la red de usuarios y desde internet— es la defensa primaria contra vulnerabilidades como CVE-2026-20253. Si el servicio sidecar de PostgreSQL no es alcanzable desde una red hostil, la vulnerabilidad no puede ser explotada, independientemente de si el parche está aplicado o no.

Qué puedes hacer ahora: acciones concretas

La mitigación de CVE-2026-20253 requiere acción inmediata en tres frentes. Primero, aplicar el parche publicado por Splunk en el advisory SVD-2026-0603 para las versiones 10.2.0 a 10.2.3 y 10.0.0 a 10.0.6. Si el parche no puede aplicarse de inmediato, deshabilitar el servicio PostgreSQL sidecar elimina el vector de ataque, aunque con la contrapartida de que las funcionalidades de Edge Processor, OpAmp y pipelines SPL2 dejarán de funcionar. Segundo, verificar que las instancias de Splunk no están expuestas a internet ni a segmentos de red no confiables —si Shadowserver encuentra 1.400 instancias expuestas, la probabilidad de que alguna sea tuya no es cero—. Tercero, revisar los logs de acceso al servicio PostgreSQL sidecar en busca de actividad inusual previa al parche, particularmente operaciones de creación o modificación de archivos originadas desde IPs que no pertenecen al segmento de administración. Si encuentras evidencia de explotación, no basta con parchear: el servidor debe ser considerado comprometido y requiere un análisis forense completo antes de volver a confiar en los datos que produce.

Temas tratados

Splunk · CVE-2026-20253 · RCE · SIEM · PostgreSQL · CISA · KEV · explotación

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?