La brecha de Splunk que elimina archivos sin inicio de sesión
6 min. de lectura
Una vulnerabilidad crítica en Splunk Enterprise permite a los atacantes crear y eliminar archivos en el servidor sin necesidad de autenticación. La agencia estadounidense CISA la incluye en su lista de vulnerabilidades explotadas activamente desde el 18 de junio. Más de 1.400 instancias están expuestas públicamente en internet en todo el mundo, 223 de ellas en Europa.
Lo más importante en resumen
- CVSS 9,8, no se requiere inicio de sesión. La vulnerabilidad CVE-2026-20253 se encuentra en el sidecar de PostgreSQL de Splunk Enterprise y permite crear y eliminar archivos sin autenticación.
- Los ataques ya están en curso. Tras la publicación del código de exploit el 12 de junio, la CISA incluyó la vulnerabilidad en su lista de fallos explotados activamente el 18 de junio, estableciendo un plazo para aplicar el parche hasta el 21 de junio para las agencias federales estadounidenses.
- La solución provisional conlleva la pérdida de funciones. Quien no pueda aplicar el parche de inmediato deberá desactivar el sidecar de PostgreSQL, perdiendo con ello el Edge Processor, OpAmp y las pipelines de datos SPL2.
Relacionado:Priorización de parches: por qué CVSS por sí solo frena tu SOC / Ingeniería de detección sin bloqueo de proveedor
Qué hace técnicamente posible la vulnerabilidad
¿Qué es CVE-2026-20253? Una vulnerabilidad crítica en el sidecar de PostgreSQL de Splunk Enterprise. Elude la autenticación, lo que permite a los atacantes crear y eliminar archivos en el servidor sin necesidad de iniciar sesión. El valor CVSS es de 9,8 sobre 10.
Splunk Enterprise ha incluido un sidecar de PostgreSQL desde hace varias versiones. Este servicio se ejecuta junto al proceso principal de Splunk y proporciona una base de datos relacional, entre otros componentes, al Edge Processor, al protocolo de telemetría OpAmp y a las pipelines de datos SPL2. Ahí es exactamente donde se encuentra el error.
CVE-2026-20253 consiste en la falta de una comprobación de autenticación. Un atacante no necesita iniciar sesión, no requiere tener una cuenta ni presentar una sesión válida. Puede crear y eliminar archivos en el sistema a través del servicio expuesto.
Puede parecer menos grave que una ejecución remota de código clásica. Sin embargo, el potencial de daño sigue siendo alto. Quien pueda crear y eliminar archivos sin autenticación tiene la capacidad de inutilizar componentes o eliminar registros. Dependiendo del entorno, este tipo de acceso puede escalar hacia ataques más complejos. El valor CVSS de 9,8 sobre 10 clasifica la vulnerabilidad como crítica, principalmente debido a la facilidad con la que puede explotarse sin necesidad de autenticación.
De un concepto de prueba a su explotación activa
La escalada tuvo lugar en pocos días. El equipo de respuesta a incidentes de seguridad de Splunk (Splunk Product Security Incident Response Team) confirmó los primeros ataques ya a principios de junio. El punto de inflexión lo marcó la publicación pública de un concepto de prueba.
Ses días entre el exploit público y el registro en KEV son una ventana muy estrecha. Tan pronto como circula un concepto de prueba, se reduce drásticamente el umbral para escaneos masivos contra sistemas expuestos. Quien espere al siguiente ciclo de mantenimiento regular, planea demasiado tarde.
¿Cuántos sistemas están ahora expuestos?
Splunk recopila logs del conjunto completo de la red, por lo que suele estar ampliamente distribuido. Una parte de las instancias está directamente conectada a Internet, a menudo por comodidad en entornos distribuidos.
Cada una de estas instancias expuestas es un objetivo directo. Incluso los servidores accesibles internamente siguen siendo vulnerables tan pronto como alguien tenga acceso a la red, por ejemplo tras un ataque de phishing. La exposición a Internet debe cerrarse primero, seguida inmediatamente de las instancias internas.
Parchear, apagar o aislar
La prioridad es clara. Splunk proporciona un parche. El informe de seguridad de Splunk sobre CVE-2026-20253 indica qué versiones afectadas hay y desde cuál versión se cierra la brecha. Quien gestione Splunk Enterprise compara su estado de versiones con este informe y aplica la actualización. Esta es la única medida que cierra realmente la brecha.
Si no es posible actualizar de inmediato, queda el recurso de emergencia: deshabilitar el PostgreSQL-Sidecar. Esto detiene el servicio vulnerable, pero tiene un costo. Edge Processor, OpAmp y las pipelines de datos SPL2 dejarán de funcionar. Para muchas entornos, esto representa una pérdida significativa de funcionalidad, apta solo como solución temporal.
Independientemente del estado del parche, la exposición a Internet debe someterse a revisión. En la práctica, rara vez hay razón para que un SIEM esté expuesto directamente a Internet. Limitar el acceso a redes internas y a un VPN reduce inmediatamente la superficie de ataque.
- Inmediatamente: Comprobar el estado de la versión, aplicar el parche.
- Si no es posible aplicar el parche: Desactivar el PostgreSQL-Sidecar, planificar la pérdida de funcionalidad.
- En cualquier caso: Revisar la exposición a Internet, limitar el acceso a redes internas y a un VPN.
- A continuación: Revisar los logs en busca de operaciones de archivos inesperadas y entradas eliminadas.
Por qué el SIEM es un objetivo especialmente delicado
Todo el conjunto de reglas de detección se basa en los logs del SIEM. Este sistema recoge los registros de todo el red en un único lugar. Si esta plataforma falla o es manipulada, el SOC pierde su fuente más importante de visión.
La posibilidad de borrar archivos agrava la situación. Un atacante que elimine los registros borra sus huellas precisamente donde normalmente se detectarían. Una brecha en el sistema de detección es por tanto más peligrosa que la misma brecha en un sistema periférico. Esta brecha afecta a la instancia que debería alertar sobre el ataque.
Para la práctica, esto significa: esta debilidad no es un parche común entre muchos. Se refiere a la componente de la que depende la credibilidad de todas las demás alarmas.
Preguntas frecuentes
¿Qué permite exactamente la CVE-2026-20253?
La vulnerabilidad en el Sidecar de PostgreSQL de Splunk Enterprise evita la autenticación. Un atacante puede crear y borrar archivos en el sistema sin datos de acceso válidos. Dependiendo del entorno, esto puede paralizar componentes o eliminar registros.
¿Están afectadas las empresas DACH, aunque la fecha límite de CISA solo aplica para organismos estadounidenses?
Sí. La fecha límite de CISA solo obliga a las autoridades federales estadounidenses, pero el riesgo técnico es idéntico en cualquier lugar. Splunk está en uso en muchos SOC de DACH, y las 223 instancias expuestas en Europa muestran que también aquí hay sistemas abiertos. Quien opera Splunk debe tratar el 21 de junio como una fecha límite propia.
¿Qué hacer si no es posible aplicar el parche inmediatamente?
Splunk recomienda como medida intermedia desactivar el servicio del Sidecar de PostgreSQL. Con ello se detiene el servicio vulnerable, aunque caen fuera de funcionamiento los procesadores de borde, OpAmp y las pipelines de datos SPL2. Esta medida solo está pensada como solución de emergencia hasta que se aplica el parche.
¿Cómo puedo saber si mi instalación de Splunk está expuesta?
El indicador más rápido es la accesibilidad desde el exterior: compruebe si el servicio del Sidecar de PostgreSQL responde desde Internet o desde segmentos no confiables. Dado que desde el 12 de junio existe un exploit público, toda instalación expuesta corre un riesgo inminente. El Splunk Advisory menciona reglas concretas de detección basadas en patrones de ataque confirmados; además, conviene revisar los logs en busca de operaciones inesperadas con archivos.
¿Por qué una vulnerabilidad en el SIEM es especialmente crítica?
El SIEM proporciona los registros para cada detección. Si se manipula, al equipo de seguridad le falta visión sobre su propia red. Como la vulnerabilidad también permite borrar archivos, un atacante puede eliminar sus huellas precisamente donde deberían detectarse.
Recomendaciones de lectura de la redacción
- Oracle PeopleSoft: vulnerabilidad explotada activamente, CISA advierte
- SIEM y XDR se fusionan: ¿Qué queda para los equipos?
- Vulnerabilidades del kernel de Linux: BSI advierte sobre escalada root
Más de la red de MBF Media
Implementación de NIS2: lista de verificación para pymes ahora
Fuente de la imagen: generada por IA (junio de 2026)
