Splunk MCP Server logs auth tokens in clear text (CVE-2026-20205)
Splunk's MCP Server app wrote users' session and authorization tokens unmasked into the _internal index — a CWE-532 secrets-in-logs flaw that turns log access into token theft. Fixed in app v1.0.3.
What is this?
CVE-2026-20205 is a sensitive-information-disclosure flaw in the Splunk MCP Server app, the connector that lets LLM agents query a Splunk deployment over the Model Context Protocol. Splunk published advisory SVD-2026-0407 on April 15, 2026 (bug ID VULN-64757), rating it CVSS 3.1 7.2 (High) with vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H and classifying it as CWE-532 (Insertion of Sensitive Information into Log File). It was credited to Charlie Huggard of Splunk and resurfaced in coverage during the broader June 2026 Splunk security-update wave.
In plain terms: the app wrote users’ session and authorization tokens in clear text into Splunk’s _internal index. Anyone who could read that index — or the underlying log files — could harvest live credentials belonging to other users. All app versions below 1.0.3 are affected.
How it works
This is not a clever prompt-injection chain or a memory-corruption bug. It is the oldest mistake in the book, transplanted into the agent stack: a service that handles bearer credentials logs them verbatim instead of redacting them.
The MCP Server app brokers requests between an MCP client (the agent) and Splunk. To do that it handles per-user session tokens and authorization tokens. On the logging path, those values were emitted unmasked into events that land in the _internal index:
# Conceptual shape of the leaked log event (token redacted here)
... mcp_tool=search user=analyst session_token=[REDACTED] authorization=Bearer [REDACTED] ...There is no special exploit code. Per Splunk and SentinelOne, an actor reaches the tokens through ordinary means:
- holding a role that can read the
_internalindex, or the high-privilegemcp_tool_admincapability; or - having local read access to the log files on the Splunk host.
By default only the admin role can read _internal, which is what keeps this at “High” rather than “Critical” and is why the vector lists PR:H. But the precondition is fragile: many real deployments broaden _internal access for troubleshooting or dashboards, and a single compromised or over-privileged account turns a routine log query into a credential dump. Recovered tokens then enable session hijacking, privilege escalation, and lateral movement into systems the impersonated user could reach.
Why it matters
MCP servers are quietly becoming the most sensitive component in an agent deployment: they sit between an autonomous model and a real backend, and they almost always hold or proxy authentication material. That makes their logging hygiene a first-class security property, not an afterthought. CWE-532 is mundane in isolation, but in an MCP server it converts a low-bar primitive — “read some logs” — into “impersonate other users of the platform.”
The Splunk case is also a useful reminder that the same class of bug recurs across the ecosystem. The advisory sits inside a cluster of 2026 Splunk information-disclosure CVEs, and tokens-in-logs has shown up repeatedly wherever MCP connectors were shipped quickly. The lesson generalizes to any MCP server, gateway, or proxy you run: assume every credential it touches will eventually be written somewhere unless you have explicitly proven otherwise.
A second point is exposure window. Because the leak is passive and persistent, tokens may already be sitting in historical index buckets and archived logs. Patching the app stops new tokens from being written, but it does nothing about credentials already captured — which is why rotation, not just upgrade, is part of the response.
Defenses
Upgrade the Splunk MCP Server app to v1.0.3 or later. The fix masks session and authorization tokens before they are written, closing the write path (per SVD-2026-0407).
Rotate exposed tokens. Treat any session/authorization token used through a pre-1.0.3 server as potentially compromised. Invalidate active sessions and reissue credentials; upgrading alone does not purge tokens already in _internal or in archived logs.
Tighten access to internal data. Restrict the _internal index to administrator-level roles only, and audit/revoke the mcp_tool_admin capability from accounts that do not strictly need it. Add file-integrity monitoring on the Splunk log directories and segment local file-system access to the host.
Hunt for prior abuse. Review searches against _internal that filter for authentication fields, bulk exports from internal indexes, and anomalous session reuse from new locations or devices — the indicators Splunk and SentinelOne list for this flaw.
Apply the durable rule to every MCP server. Redact secrets before logging, never after; keep credential-handling components on a no-network, no-secrets-at-rest footing where possible; and review what your MCP connectors emit at every log level before you put them in production. A “safe” tool that proxies tokens is only as safe as its quietest debug line.
Status
| Item | Detail |
|---|---|
| CVE | CVE-2026-20205 (CWE-532) |
| Advisory | Splunk SVD-2026-0407, published 2026-04-15 |
| Severity | CVSS 3.1 7.2 High (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) |
| Affected | Splunk MCP Server app, versions below 1.0.3 |
| Fixed | Splunk MCP Server app v1.0.3 |
| Precondition | _internal index read access, mcp_tool_admin capability, or local log access |
| Credit | Charlie Huggard, Splunk |
| Action | Upgrade to ≥ 1.0.3, rotate tokens, restrict _internal, audit mcp_tool_admin |