El servidor MCP de Splunk registra tokens de autenticación en texto claro (CVE-2026-20205)

¿Qué es esto?

CVE-2026-20205 es un fallo de divulgación de información sensible en la app Splunk MCP Server, el conector que permite a los agentes LLM consultar un despliegue de Splunk mediante el Model Context Protocol. Splunk publicó el aviso SVD-2026-0407 el 15 de abril de 2026 (ID de error VULN-64757), con una puntuación CVSS 3.1 de 7,2 (alta), vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, clasificado como CWE-532 (inserción de información sensible en un archivo de registro). Se atribuye a Charlie Huggard, de Splunk, y resurgió durante la oleada de actualizaciones de seguridad de Splunk de junio de 2026.

En términos sencillos: la app escribía los tokens de sesión y de autorización de los usuarios en texto claro en el índice _internal de Splunk. Cualquiera que pudiera leer ese índice — o los archivos de registro subyacentes — podía recolectar credenciales activas pertenecientes a otros usuarios. Todas las versiones de la app anteriores a la 1.0.3 están afectadas.

Cómo funciona

No se trata de una ingeniosa cadena de inyección de prompts ni de un fallo de corrupción de memoria. Es el error más antiguo del oficio, trasplantado a la pila agéntica: un servicio que maneja credenciales bearer las registra tal cual en lugar de enmascararlas.

La app MCP Server hace de intermediaria entre un cliente MCP (el agente) y Splunk. Para ello maneja tokens de sesión y de autorización propios de cada usuario. En la ruta de registro, esos valores se emitían sin enmascarar en eventos que aterrizan en el índice _internal:

# Forma conceptual del evento de log filtrado (token redactado aquí)
... mcp_tool=search user=analyst session_token=[REDACTED] authorization=Bearer [REDACTED] ...

No se requiere código de explotación especial. Según Splunk y SentinelOne, un atacante alcanza los tokens por medios ordinarios:

1. teniendo un rol que puede leer el índice _internal, o la capacidad de alto privilegio mcp_tool_admin; o
2. teniendo acceso de lectura local a los archivos de registro del host Splunk.

Por defecto, solo el rol admin puede leer _internal, lo que mantiene el nivel en «alto» en lugar de «crítico» y explica el PR:H del vector. Pero el requisito previo es frágil: muchos despliegues reales amplían el acceso a _internal para tareas de diagnóstico o paneles, y una sola cuenta comprometida o con privilegios excesivos convierte una consulta de logs rutinaria en una recolección de credenciales. Los tokens recuperados habilitan después el secuestro de sesión, la escalada de privilegios y el movimiento lateral hacia los sistemas accesibles para el usuario suplantado.

Por qué importa

Los servidores MCP se están convirtiendo discretamente en el componente más sensible de un despliegue agéntico: se sitúan entre un modelo autónomo y un backend real, y casi siempre poseen o retransmiten material de autenticación. Eso hace de su higiene de registro una propiedad de seguridad de primer orden, no una ocurrencia tardía. CWE-532 es trivial de forma aislada, pero en un servidor MCP convierte una primitiva de bajo coste — «leer algunos logs» — en «suplantar a otros usuarios de la plataforma».

El caso de Splunk también recuerda que esta clase de fallo se repite en todo el ecosistema. El aviso se inscribe en un grupo de CVE de divulgación de información de Splunk en 2026, y el patrón «tokens en los logs» reaparece allá donde se entregaron conectores MCP con prisas. La lección sirve para cualquier servidor, pasarela o proxy MCP que ejecute: asuma que cada credencial que toque acabará escrita en algún sitio, salvo que haya demostrado lo contrario de forma explícita.

Un segundo punto es la ventana de exposición. Como la fuga es pasiva y persistente, puede que los tokens ya estén en buckets de índice históricos y en logs archivados. Parchear la app detiene la escritura de tokens nuevos, pero no hace nada con las credenciales ya capturadas — por eso la rotación, y no solo la actualización, forma parte de la respuesta.

Defensas

Actualice la app Splunk MCP Server a la v1.0.3 o superior. La corrección enmascara los tokens de sesión y de autorización antes de escribirlos, cerrando la ruta de escritura (según SVD-2026-0407).

Rote los tokens expuestos. Trate cualquier token de sesión/autorización usado a través de un servidor anterior a 1.0.3 como potencialmente comprometido. Invalide las sesiones activas y reemita credenciales; actualizar por sí solo no purga los tokens ya presentes en _internal o en logs archivados.

Restrinja el acceso a los datos internos. Limite el índice _internal solo a roles de nivel administrador, y audite/revoque la capacidad mcp_tool_admin en cuentas que no la necesiten estrictamente. Añada monitorización de integridad de archivos en los directorios de logs de Splunk y segmente el acceso local al sistema de archivos del host.

Busque abusos previos. Revise las búsquedas en _internal que filtran campos de autenticación, las exportaciones masivas desde índices internos y las reutilizaciones de sesión anómalas desde nuevas ubicaciones o dispositivos — los indicadores que Splunk y SentinelOne enumeran para este fallo.

Aplique la regla duradera a todo servidor MCP. Redacte los secretos antes del registro, nunca después; mantenga si es posible los componentes que manejan credenciales sin red y sin secretos en reposo; y revise lo que sus conectores MCP emiten en cada nivel de log antes de pasarlos a producción. Una herramienta «segura» que retransmite tokens solo es tan segura como su línea de depuración más discreta.

Estado

Elemento	Detalle
CVE	CVE-2026-20205 (CWE-532)
Aviso	Splunk SVD-2026-0407, publicado el 2026-04-15
Gravedad	CVSS 3.1 7,2 alta (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Afectados	App Splunk MCP Server, versiones anteriores a la 1.0.3
Corregido	App Splunk MCP Server v1.0.3
Requisito previo	Acceso de lectura a _internal, capacidad mcp_tool_admin, o acceso local a los logs
Crédito	Charlie Huggard, Splunk
Acción	Actualizar a ≥ 1.0.3, rotar tokens, restringir _internal, auditar mcp_tool_admin