Alerta de seguridad Splunk vulnerabilidad crítica CVE-2026-20253 que podría permitir ejecución remota de código

Splunk ha publicado parches críticos para una falla en Splunk Enterprise que, según la compañía y los investigadores que analizaron el problema, permite realizar operaciones de archivo sin autenticación y potencialmente escalar hasta ejecución remota de código. Identificada como CVE-2026-20253 y con una puntuación CVSS de 9.8, la vulnerabilidad se localiza en el servicio "PostgreSQL sidecar" que algunas instalaciones on‑premises usan junto con Splunk Enterprise y que carece de controles de autenticación en ciertos endpoints.

El riesgo es alto por dos razones: primero, cualquier usuario con acceso de red a ese servicio puede invocar funciones de copia/recuperación de bases de datos sin credenciales; segundo, la secuencia de operaciones permitidas (volcar un dump, restaurarlo e invocar funciones de la base de datos) ofrece una primitiva de escritura arbitraria en el sistema de archivos, que a su vez puede convertirse en ejecución de código si se sobrescribe un script que Splunk ejecuta regularmente. Splunk indica que las versiones afectadas son 10.0.0 a 10.0.6 (corregido en 10.0.7) y 10.2.0 a 10.2.3 (corregido en 10.2.4); Splunk Enterprise 10.4 no está afectada y Splunk Cloud tampoco usa esos sidecars, por lo que no se ve impactada.

Los detalles técnicos publicados por investigadores muestran cómo, al usar los endpoints de backup/restore del sidecar, un atacante puede dropear un volcado controlado por él en el host objetivo y provocar que la instancia local de PostgreSQL ejecute sentencias definidas en ese dump. Entre esas sentencias puede incluirse la creación de funciones que llamen a utilidades como lo_export para extraer BLOBs y escribir archivos en rutas del sistema, por ejemplo sobreescribiendo scripts Python que Splunk carga automáticamente, lo que convierte una escritura arbitraria en ejecución remota de código.

Aunque hasta ahora no hay evidencia pública de explotación masiva en entornos productivos, la publicación del método hace que esta vulnerabilidad sea atractiva para actores oportunistas. Por eso las organizaciones deben actuar con rapidez: el tiempo entre la disponibilidad de un exploit funcional y los intentos de abuso puede ser muy corto.

La primera y más importante medida es aplicar los parches oficiales: actualizar a 10.0.7 o a 10.2.4 (u otra versión más reciente que ya incluya la corrección). Splunk mantiene avisos de seguridad y notas de versión donde explicar la mitigación y los builds afectados; es recomendable seguir la guía del proveedor y descargar los fixes desde fuentes oficiales. Puede consultar el repositorio de avisos de Splunk y la entrada del CVE en bases públicas como la NVD para confirmar detalles técnicos y seguimiento del CVE: Splunk Security Notices y NVD - CVE-2026-20253.

Si por alguna razón no es posible actualizar de inmediato, existen mitigaciones compensatorias que reducen la superficie de ataque: bloquear el acceso de red al servicio PostgreSQL sidecar mediante reglas de firewall y segmentación, limitar la exposición de los endpoints de backup/restore a redes internas de gestión, y aplicar listas de control de acceso para que solo hosts conocidos y confiables puedan conectarse. Además, impedir que instancias Splunk puedan abrir conexiones salientes a bases de datos controladas por terceros evita una parte del vector usado por los investigadores.

En paralelo a parchear o aislar, es imprescindible buscar señales de compromiso. Conviene inspeccionar integridad y cambios en rutas críticas como /opt/splunk (especialmente archivos y scripts en etc/apps/*/bin), revisar logs internos y de auditoría en busca de llamadas a los endpoints de recuperación o de actividades de dump/restore, y monitorizar procesos y conexiones de PostgreSQL que apunten a bases de datos externas. Si se identifican modificaciones no autorizadas, las máquinas afectadas deben ser aisladas y tratadas siguiendo procedimientos de respuesta a incidentes, incluida la restauración desde copias limpias y la rotación de credenciales asociadas.

Finalmente, este incidente recuerda dos lecciones operativas: la primera, nunca exponer servicios de administración o sidecars sin controles de acceso robustos; la segunda, complementar el parcheo con controles de detección y segmentación de red que impidan que una primitiva de archivo o base de datos se convierta en ejecución remota de código. Mantener inventario actualizado de componentes y una política de revisión de cambios en archivos ejecutables reduce la capacidad de un atacante de persistir silenciosamente tras una intrusión.

La recomendación clave es clara: actualizar ahora, bloquear el acceso a los sidecars si no puede parchearse inmediatamente, y llevar a cabo una búsqueda proactiva de indicadores de abuso en los entornos afectados. Para detalles técnicos adicionales y seguimiento del estado del parche, consulte las páginas oficiales indicadas y las publicaciones de los investigadores que analizaron el fallo.