Splunk ha revelado CVE-2026-76268, que afecta a las versiones de Splunk Enterprise anteriores a 10.4.3 y 10.2.7. Un atacante no autenticado con acceso de red a la API REST de Patroni en un miembro del clúster de cabezas de búsqueda puede ejecutar los comandos del sistema operativo que elija. Las versiones 10.0.x y 9.4.x no están afectadas.

Lo que me preocupa de este caso es que la API de Patroni queda expuesta sin autenticación para lo que el aviso denomina «operaciones de configuración críticas». No se trata de una mala configuración que usted haya introducido. Es una decisión de diseño integrada en el propio producto. Los controles perimetrales y la segmentación de red son lo único que se interpone entre un atacante y la ejecución de comandos a nivel de sistema operativo en un nodo que, en la mayoría de los entornos, tiene acceso a datos sensibles de registros y seguridad.

Desde el punto de vista del IAM, esto es un ejemplo clásico de fallo en la autenticación de cuentas de servicio y APIs. Cualquier API que acepte cambios de configuración debe exigir una credencial, sin excepciones. Las interfaces «internas» no son una excusa válida. En mi experiencia, las APIs «internas» de este tipo son exactamente el punto donde los atacantes pivotan una vez que han superado el perímetro. La interfaz de Patroni, al parecer, nunca recibió ese mensaje. Es probable que sus herramientas de detección tampoco supieran vigilarla, porque nadie esperaba que fuera una superficie de ataque.

Los clústeres de cabezas de búsqueda de Splunk no son despliegues marginales. Son habituales en empresas medianas y grandes que ejecutan cargas de trabajo SIEM, lo que significa que el radio de impacto aquí puede ser considerable. Si un atacante ejecuta comandos del sistema operativo en una cabeza de búsqueda, puede manipular la ingesta de registros, borrar rastros o utilizar el nodo como punto de lanzamiento. El acceso que Splunk tiene al resto de su entorno agrava la situación en comparación con el compromiso de una aplicación cualquiera.

Si ejecuta una versión afectada, aplique el parche a 10.4.3 o 10.2.7 de inmediato. Mientras programa esa ventana de mantenimiento, compruebe si el puerto de la API de Patroni es accesible desde algo más allá de los propios nodos del clúster. La segmentación de red no corrige la vulnerabilidad, pero reduce la ventana de exposición antes de que llegue el parche. Tras parchear, revise los registros de acceso del endpoint de Patroni y busque llamadas inesperadas. Si no puede obtener esos registros, ese es un problema aparte que merece atención.