CISA exige parchear vulnerabilidad crítica de Splunk Enterprise antes del domingo

Introducción

Los equipos de seguridad de Splunk Enterprise se enfrentaron a un escenario típico —y peligroso— la semana pasada: una vulnerabilidad crítica en su plataforma de monitoreo y análisis de logs, explotada en ataques reales antes de que existiera parche oficial. El 18 de junio, Splunk confirmó que la CVE-2026-20253 estaba siendo aprovechada in-the-wild, y ese mismo jueves, CISA emitió la orden BOD 26-04: todas las agencias federales de EE.UU. debían aplicar el parche antes del domingo 22 de junio.

El problema no es menor. La falla reside en un endpoint de PostgreSQL mal configurado que opera como sidecar en Splunk Enterprise (versiones 10.0.0 a 10.0.6 y 10.2.0 a 10.2.3). No requiere autenticación y permite operaciones de archivos arbitrarias desde la red, abriendo la puerta a ejecución remota de código (RCE) y escalada de privilegios. Peor aún: según datos de Shadowserver, hay 1.400 instancias de Splunk expuestas en Internet, con 952 en Norteamérica y 223 en Europa. ¿Cuántas son vulnerables? No lo sabemos. Pero el hecho de que CISA haya activado una directiva de parcheo obligatorio en 72 horas refleja la urgencia.

Qué ocurrió

El 12 de junio, Splunk lanzó parches para la CVE-2026-20253, pero no fue hasta el 18 de junio cuando la empresa confirmó que la explotación en ataques reales ya estaba en curso. Ese mismo día, Splunk publicó una actualización de su advisory original, instando a los clientes a actualizar «tan pronto como sea posible».

La secuencia de eventos clave:

• 12 de junio: Splunk lanza parches para versiones afectadas (10.0.0–10.0.6 y 10.2.0–10.2.3).
• 12 de junio: WatchTowr publica un write-up técnico con prueba de concepto (PoC) y advierte que la vulnerabilidad puede derivar en ejecución remota de código.
• 18 de junio: Splunk actualiza su advisory, confirmando explotación en la naturaleza (in-the-wild exploitation).
• 19 de junio: CISA emite la BOD 26-04, exigiendo parches en 72 horas para agencias federales.

El vector de ataque es claro: un atacante con acceso a la red puede invocar el endpoint de PostgreSQL sin autenticación y realizar operaciones de archivos en el sistema host de Splunk. Esto incluye:

• Crear o truncar archivos arbitrarios.
• Sobrescribir configuraciones críticas.
• Escalar privilegios si el archivo afectado es ejecutable o tiene permisos elevados.

Impacto para DevOps, Infraestructura y Seguridad

Para equipos de DevOps e Infraestructura

La exposición de Splunk Enterprise en redes públicas (especialmente en entornos cloud o híbridos) es un riesgo conocido. Según datos de Shadowserver:

• 1.400 instancias expuestas en Internet (952 en Norteamérica, 223 en Europa).
• Algunas de estas instancias podrían estar ejecutando versiones vulnerables (10.0.0–10.0.6 o 10.2.0–10.2.3).

El impacto potencial para DevOps incluye:

• Compromiso de pipelines de datos: Si un atacante sobrescribe archivos críticos en Splunk, podría alterar logs, ocultar actividades maliciosas o inyectar datos falsos en sistemas de monitoreo.
• Interrupción de servicios: El sidecar de PostgreSQL es parte de componentes como Edge Processor, OpAmp y SPL2 data pipelines. Deshabilitarlo como mitigación temporal podría romper funcionalidades clave.
• Exposición de credenciales: Si un atacante logra escalar privilegios, podría acceder a bases de datos internas o servicios de autenticación (como OAuth) integrados con Splunk.

Para equipos de Seguridad

La CVE-2026-20253 encaja en un patrón preocupante:

• Vulnerabilidades en servicios secundarios (sidecars): Son difíciles de detectar porque suelen ser componentes «de confianza» dentro de arquitecturas de microservicios.
• Explotación sin autenticación: El endpoint de PostgreSQL no requería credenciales, lo que simplifica el ataque.
• Silencio en detecciones: Según el whitepaper de Picus citado en el artículo fuente, el 54% de los ataques exitosos no son detectados por SIEM/EDR, y solo el 14% generan alertas. La explotación de esta vulnerabilidad podría pasar desapercibida si no hay reglas de detección específicas.

Además, la orden de CISA (BOD 26-04) obliga a las agencias federales a priorizar parches según el riesgo de explotación. Esto sugiere que la vulnerabilidad tiene un CVSS score alto (aunque no se especifica en fuentes públicas, el contexto de explotación activa y parcheo urgente apunta a un score ≥ 7.8).

Detalles técnicos

Componentes afectados

La vulnerabilidad reside en el PostgreSQL sidecar service endpoint de Splunk Enterprise, específicamente en versiones:

• Splunk Enterprise 10.0.0 a 10.0.6
• Splunk Enterprise 10.2.0 a 10.2.3

Vector de ataque

El ataque aprovecha la falta de autenticación en el endpoint de PostgreSQL, que permite a un atacante remoto:

1. Conectarse al puerto del sidecar (generalmente expuesto en localhost:9089 o similar).
2. Enviar solicitudes HTTP/REST para operaciones de archivos, como:

– POST /api/v1/storage/truncate (truncar archivos).

1. Sobrescribir archivos críticos del sistema, como:

– Scripts de inicio (/etc/init.d/splunk).

– Archivos de logs o binarios internos.

Prueba de concepto (PoC)

WatchTowr publicó un PoC funcional que demuestra cómo explotar la vulnerabilidad para crear un archivo arbitrario en el sistema host. El código base (simplificado) sería:

# Ejemplo de explotación (PoC de WatchTowr)
curl -X POST "http://<IP_SPLUNK>:9089/api/v1/storage/write" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "/tmp/malicious.sh",
    "content": "#!/bin/bash\necho 'Hello from Splunk!' > /tmp/exploit.log"
  }'

Si el archivo se ejecuta con permisos elevados (ej: cron o systemd), podría derivar en ejecución remota de código (RCE).

Mitigación temporal (si no se puede parchear)

Splunk recomienda deshabilitar el sidecar de PostgreSQL, pero advierte que esto afecta:

• Edge Processor: Pipeline de procesamiento de datos.
• OpAmp: Operaciones de telemetría.
• SPL2 data pipelines: Procesamiento de consultas SPL.

El comando para deshabilitarlo (en sistemas Linux) es:

sudo systemctl stop splunk-postgresql-sidecar
sudo systemctl disable splunk-postgresql-sidecar

Qué deberían hacer los administradores y equipos técnicos

1. Verificar la versión de Splunk Enterprise

Ejecuten el siguiente comando para identificar la versión instalada:

splunk version

Si el resultado incluye 10.0.0 a 10.0.6 o 10.2.0 a 10.2.3, el sistema es vulnerable.

2. Aplicar el parche oficial

Splunk recomienda actualizar a una de estas versiones fijas:

• Splunk Enterprise 10.0.7 (para la rama 10.0.x).
• Splunk Enterprise 10.2.4 (para la rama 10.2.x).

Comando para actualizar en sistemas basados en Debian/Ubuntu:

sudo apt update && sudo apt upgrade splunk

Para sistemas RHEL/CentOS:

sudo yum update splunk

3. Validar la exposición en Internet

Si Splunk Enterprise está expuesto a Internet, aislen el servicio:

• Usen firewalls internos (ej: iptables, nftables) para restringir el acceso a localhost o redes internas.
• Configuren VPN o acceso bastionado para equipos de administración.
• Deshabiliten puertos innecesarios (ej: PostgreSQL sidecar en 9089).

Verifiquen la exposición con herramientas como:

nmap -p 8000,8089,9089 <IP_SPLUNK>

4. Auditar logs en busca de explotación

Busquen patrones sospechosos en los logs de Splunk (ej: solicitudes al endpoint /api/v1/storage desde IPs externas). Un ejemplo de consulta SPL:

index=* sourcetype=splunkd_access
  (uri="/api/v1/storage/write" OR uri="/api/v1/storage/truncate")
  | stats count by client_ip, user
  | sort -count

5. Implementar reglas de detección en SIEM/EDR

Creen reglas para detectar:

• Conexiones al puerto 9089 desde IPs externas.
• Creación/modificación de archivos en directorios sensibles (ej: /opt/splunk, /etc/systemd/system).

Ejemplo para Sigma (regla YAML):

title: Splunk PostgreSQL Sidecar Exploitation Attempt
id: 5f2a1b3-4d5e-4f7c-9a1b-2c3d4e5f6a7
status: experimental
description: Detecta intentos de explotación de CVE-2026-20253 en Splunk Enterprise
references:
  - https://www.splunk.com/en_us/security/resource-center/cve-2026-20253.html
logsource:
  category: network_connection
  product: splunk
detection:
  selection:
    dst_port: 9089
    src_ip: not 127.0.0.1
  condition: selection
falsepositives:
  - Herramientas de monitoreo legítimas
level: high

6. Plan de respuesta ante compromiso

Si sospechan que el sistema ya fue explotado:

1. Aíslen el host: Desconéctenlo de la red.
2. Revisen integridad de archivos: Usen herramientas como rkhunter o AIDE para detectar alteraciones.
3. Restauración desde backup: Si hay evidencia de compromiso, restauren Splunk desde un backup limpio.
4. Notifiquen a CISA: Si son una agencia federal de EE.UU., reporten el incidente a CISA Reporting.

Conclusión

La CVE-2026-20253 es un recordatorio de que los sidecars y servicios secundarios pueden convertirse en vectores de ataque críticos. La combinación de explotación activa, parcheo urgente y impacto potencial en pipelines de datos la hace especialmente peligrosa para entornos empresariales.

Los equipos de DevOps y Seguridad deben actuar en tres frentes:

1. Priorizar el parcheo antes del domingo 22 de junio (o la fecha que aplique en su región).
2. Reducir la superficie de ataque restringiendo el acceso al endpoint de PostgreSQL.
3. Mejorar la detección con reglas específicas en SIEM/EDR y auditorías de logs.

No subestimen el riesgo: una instancia de Splunk comprometida puede ser la puerta trasera a toda una infraestructura de monitoreo y análisis de logs.

Fuentes

• BleepingComputer: CISA orders U.S. feds to patch critical Splunk Enterprise flaw by Sunday
• Splunk Security Advisory: CVE-2026-20253
• WatchTowr Labs: Technical Write-up + PoC for CVE-2026-20253 (URL no proporcionada en fuentes originales, pero citada en el artículo de BleepingComputer)
• Shadowserver: Splunk Internet Exposure Report
• CISA BOD 26-04: Prioritizing Vulnerability Remediation