The SIEM used to be the place you went to find the breach. It is quietly turning into a place the breach can start.
Splunk’s October advisory cycle makes the point better than any analyst deck. On Oct 7 Splunk published SVD-2026-1004 for its MCP Server app, the piece that lets AI assistants call into Splunk. CVE-2026-76286, rated 5.3, is a server-side request forgery through custom API tools. In versions below 1.2.1, a user who runs a custom tool could have their Splunk authentication token sent to whatever URL that tool was configured with. If someone else controls that URL, they get the token and can act as that user (Splunk SVD-2026-1004).
Medium severity. Easy to skip. Don’t.
Read the mechanics, not the score. The CVSS math is low because exploitation needs a privileged tool author and a user who clicks run. That is exactly how agent tooling gets used. One person builds a tool. Ten people, or ten agents, call it. The trust boundary isn’t the network anymore. It’s who wrote the tool definition.
And this isn’t the first MCP Server fix. Splunk’s August bulletin, SVD-2026-0808, updated again on Oct 7, carried CVE-2026-76404 in the same app: a deserialization bug rated 9.1 critical that let a user with the admin role run arbitrary commands on the underlying OS. Same bulletin, Splunk AI Toolkit: a handler that swapped the caller’s session key for a system token (CVE-2026-76391, 8.3), and model loading that could execute code through embedded pickle content (CVE-2026-76395, 8.8) (Splunk SVD-2026-0808).
Look at that list again. Token swapping. Pickle deserialization. Outbound requests to attacker-picked URLs. Those aren’t SIEM bugs. They’re AI app bugs, now living inside the system that holds every log you own. SecurityWeek’s Oct 8 roundup also counted three critical fixes in Splunk Enterprise itself (SecurityWeek).
Why this matters for the platform fight. Every SIEM vendor is racing to bolt agents onto the data lake. It’s the right product call. Analysts want to ask questions in English and have something run the search. But a SIEM with an agent layer is a high-value identity broker. It holds credentials to cloud APIs, EDR consoles and ticketing systems. Put an MCP server in front of it and you’ve built a very privileged API that accepts instructions from models.
The platform pitch says one vendor, one data plane, fewer seams. True. It also means one MCP server compromise reaches the whole estate. Best-of-breed buyers have a counterargument here for once: blast radius.
What we’d do Monday.
Inventory first. Is the Splunk MCP Server app installed anywhere, including the test instance someone stood up in August? If it is, get to 1.2.1. Splunk’s own fallback is to turn the app off or remove it.
Then audit who holds mcp_tool_admin. That capability is now a code-signing key in practice. Treat it like one. Small group, reviewed, logged.
Review every custom API tool’s destination URL. Anything not on a domain you own deserves a hard question. Pull outbound connections from search heads and flag new destinations. A SIEM calling a URL it never called before is a detection, not noise.
Finally, scope tokens. If an agent runs a search, it should run with the narrowest token you can give it, not the analyst’s full session.
The bigger read. Security vendors want to be trusted with AI agents. Their own agent connectors are now landing in patch bulletins with the same bug classes as everyone else. That’s not a scandal. It’s normal software. But it ends the idea that the security stack is exempt from the agent attack surface. The SOC’s tooling is now part of the attack surface you have to manage.
Buyers should ask every SIEM and XSIAM-style vendor the same three things: how are agent tools authored and approved, what token does an agent actually use, and how do you log what the model asked versus what ran. Vendors with clean answers will win the agent era. The ones who say “it’s just an integration” are telling you where the next advisory comes from.