Splunk MCP Server: Clear-Text Token Exposure in Logs (CVE-2026-20205)
The Splunk MCP Server app wrote session and authorisation tokens to the Splunk _internal index in clear text. Any user with the mcp_tool_admin capability or access to that index could read active credentials for other sessions and replay them. Splunk published the advisory alongside a patch to version 1.0.3 on April 15, 2026. Exploitation requires high privileges by default, but in Splunk environments where _internal access is granted broadly or admin accounts are compromised, it becomes a direct credential harvesting path for any session using the MCP server.
What happened
The Splunk MCP Server app is Splunk's integration layer for connecting AI agents to the Splunk platform. In versions below 1.0.3, the application failed to redact or mask session and authorisation tokens before writing them to the Splunk _internal index as part of its standard logging behaviour.
The impact depends on who can read that index. By default, the admin role receives _internal access, which limits the practical blast radius to privileged insiders or compromised administrator accounts. However, Splunk environments frequently have custom roles, and the presence of the dedicated mcp_tool_admin capability means MCP-specific administrators may have held this exposure without realising it.
A user reaching these logs recovers live session and authorisation tokens for any session that interacted with the MCP server during the logging window. Those tokens can be replayed to impersonate the original user, escalate privileges within Splunk, or reach any downstream system that trusts Splunk-mediated authentication.
Splunk disclosed the vulnerability as CVE-2026-20205 (CVSS 7.2) on April 15, 2026 under advisory SVD-2026-0407, simultaneously releasing version 1.0.3 of the MCP Server app which prevents token values from being persisted to logs.
The PolicyLayer angle
The structural failure here is one that MCP surfaces amplify: agent authentication tokens are high-value credentials that persist across many tool calls, and any sink that writes them without redaction hands the entire session to whoever controls that sink. In a traditional API context, session tokens in logs are a well-understood risk. In an MCP context, those tokens grant the agent's full scope of tool access, which in Splunk's case means search, data export, and administrative functions.
The concrete controls that reduce this class of exposure: treat MCP session tokens as secrets with the same handling requirements as API keys; audit every logging path in MCP server implementations for sensitive value leakage; restrict mcp_tool_admin and _internal index access using the principle of least privilege, with separate review from the standard admin-role assignment process. A policy layer that inventories the credentials that MCP sessions carry, and flags when those credentials appear in observable outputs including logs, creates the audit trail needed to detect this before it becomes a breach.
Mitigations
Upgrade the Splunk MCP Server app to version 1.0.3 or later. After upgrading, rotate all session and authorisation tokens that may have been logged in prior versions. Audit which roles in your Splunk instance have access to the _internal index and restrict that access to administrator-level roles only. Review which users hold the mcp_tool_admin capability and remove it from any account that does not require it.
FAQs
Yes, all Splunk MCP Server app versions below 1.0.3 are affected. The default admin-only restriction on the _internal index limits exploitation to privileged users, but any organisation that has granted broader _internal access or that uses the mcp_tool_admin capability is at elevated risk.
A recovered session token grants the same Splunk access as the session's original user. Depending on that user's role, this can include data search and export, administrative functions, or access to downstream systems that trust Splunk-mediated credentials. In an MCP context, the token also authorises any tool the original user had delegated to the agent.