August 2026 agent-framework and MCP-server CVE batch — Spring AI tool-authorization bypass, PyCharm's unauthenticated Jupyter MCP, Splunk MCP RCE, LangChain SitemapLoader SSRF, and an LLM proxy that trusts a header for identity

View raw markdownEdit on GitHub ↗

TL;DR

One week's worth of CVEs across the AI-agent and MCP-server surface, grouped because they repeat the same four mistakes rather than because they share an actor. Headline items:

  • Spring AI — CVE-2026-59318: the per-request tool list Spring AI advertises to the model as a boundary isn't fully enforced at dispatch, so a tool not made available to the current request can still be invoked.
  • JetBrains PyCharm — CVE-2026-75060 (CVSS 8.4): the IDE exposed Jupyter MCP tools with no authentication, giving local code execution with no auth and no user interaction. Fixed in 2026.2.1.
  • Splunk MCP Server app — CVE-2026-76404 (CVSS 9.1, critical): unsafe deserialization in credential management → OS command execution. Fixed in 1.2.1, alongside nine Splunk AI Toolkit CVEs.
  • langchain-community — CVE-2026-72848 (CVSS 7.7): SitemapLoader applies restrict_to_same_domain only to leaf entries, so nested sitemaps SSRF into internal addresses — and the response comes back inside the returned Documents, making it a read-SSRF.
  • Headroom LLM proxy — CVE-2026-77776 (CVSS 9.3, critical): the proxy takes the memory owner from a client-supplied x-headroom-user-id header with no binding to the caller's credentials.

What happened

Spring AI — the advertised tool list is not the enforced one (2026-08-20/21)

CVE-2026-59318 / GHSA-wmqr-wxf2-6449 (Moderate, CVSS 6.5, CWE-863). Spring AI presents a per-request tool list to the model as a boundary, but does not fully enforce it at dispatch — a tool that was not made available to the current request can nonetheless be invoked, which is privilege escalation whenever request-scoped tool sets are how you separate privilege levels. Affects Spring AI 2.0.0, 1.1.0–1.1.8, and 1.0.0–1.0.9; fixed in 2.0.1 for open source, with 2.0.0.1 / 1.1.9 / 1.0.10 as Enterprise-Support-only backports.

This is the "decorator-as-documentation" class this repo has tracked since Semantic Kernel, now aimed at the request-scoped tool list rather than an SDK annotation. The general form: anything a framework shows the model as a constraint must also be checked where the call is actually dispatched. Telling the model about a limit is prompt engineering; enforcing it at dispatch is security.

Two siblings in the same batch:

  • CVE-2026-59279 / GHSA-2g9x-r8w8-qjff (High, CVSS 7.5, CWE-770) — the MCP Streamable HTTP server transport (WebFlux and WebMvc) puts no limit on retained sessions and requires no client authentication by default → unauthenticated remote memory exhaustion. Another entry in this repo's standing "MCP servers are unauthenticated network services by default" pattern. Affects Spring AI 2.0.0; the GHSA page does not state a patched version.
  • CVE-2026-59308 / GHSA-h4jw-w55g-65gf (Moderate, CVSS 4.2, CWE-668) — the Semantic Cache context hash doesn't isolate cached responses across different system prompts, so responses leak between unrelated contexts. Low CVSS, but for a multi-tenant deployment "another tenant's cached answer" is a data-isolation failure, not a caching quirk.

JetBrains PyCharm — an IDE shipping an MCP surface with the auth step missing (2026-08-17)

CVE-2026-75060 / GHSA-5686-8wvm-pm8w (High, CVSS 8.4, CWE-306 Missing Authentication for Critical Function). PyCharm exposed Jupyter MCP tools without authentication, letting a local attacker execute arbitrary code with no authentication and no user interaction. Fixed in PyCharm 2026.2.1.

Same shape as the Cline, OpenCode, Marimo, and AutoJack/AutoGen Studio entries in this repo's localhost cluster — and a reminder that the MCP surface an IDE opens on your behalf is one you did not choose to run and probably do not know is listening.

Splunk MCP Server — deserialization to OS command execution (2026-08-19)

CVE-2026-76404 / GHSA-3v49-2fcm-3rcj (Critical, CVSS 9.1), Splunk advisory SVD-2026-0808. The MCP Server app's credential-management component deserializes stored data without type validation; a user holding the Splunk admin role can supply or influence crafted serialized data and execute arbitrary OS commands on the host. Affects the Splunk MCP Server app < 1.2.1; fixed in 1.2.1.

The same advisory batch carries nine Splunk AI Toolkit CVEs (CVE-2026-76391 … CVE-2026-76399, CVSS 4.3–8.8), fixed in 6.0.0 / 6.0.1 — including CVE-2026-76395 (RCE via untrusted deserialization, 8.8), CVE-2026-76391 and CVE-2026-76394 (8.3, privilege management / missing authorization), and CVE-2026-76397 / CVE-2026-76399 (8.1, access control on experiment history and searches).

Authentication as admin is required for CVE-2026-76404, which lowers standalone urgency — but note the composition risk this repo keeps flagging: an MCP server is precisely the component an agent drives on your behalf, so "requires admin" means "requires the privilege the agent is probably already running with."

langchain-community — SitemapLoader read-SSRF (2026-08-21)

CVE-2026-72848 / GHSA-vg8m-4p2q-gcjh (High, CVSS 7.7, CWE-918). SitemapLoader.parse_sitemap applies the documented restrict_to_same_domain control only to leaf url entries — nested sitemap loc values go straight through to scrape_all([loc.text], "xml") unchecked. Anyone who controls or influences an ingested sitemap can steer the server at loopback, link-local, or RFC1918 addresses.

The aggravating detail: the fetched content is returned inside the resulting Documents, so this is a read-SSRF, not a blind one — cloud metadata, internal admin pages, and anything else reachable comes back into the pipeline (and, in a RAG setup, quite possibly into a model's context and then a user's answer). The GHSA page does not state affected or patched version ranges, so check langchain-community against the advisory directly rather than assuming a version is clean.

Same root shape as MLflow CVE-2026-64849: an SSRF guard that covers the obvious path and not the indirection one hop away.

Headroom LLM proxy — a header is not an identity (2026-08-21)

Two flaws in an LLM proxy, both amplified by a reference Docker Compose that binds 0.0.0.0 with no auth:

  • CVE-2026-77776 / GHSA-5vg3-c628-vf56 (Critical, CVSS 9.3) — the proxy derives the memory owner from the client-supplied x-headroom-user-id header without binding it to the caller's credentials (headroom/proxy/handlers/openai.py, chat-completion and WebSocket endpoints) → cross-user impersonation and access to other users' agent memory.
  • CVE-2026-77775 / GHSA-4j5r-9p93-j2px (High, CVSS 7.7, CWE-918) — clients choose the upstream via x-headroom-base-url; validation covers only scheme and hostname, so loopback, link-local, and RFC1918 destinations are reachable, responses are relayed back, and Authorization headers are forwarded unchanged to the attacker-chosen host. That last clause is the serious part: it hands your upstream LLM provider key to whatever host the caller names.

Neither GHSA page states affected or patched versions. This is a textbook instance of this repo's "central credentials cache" framing — an LLM proxy holds every upstream provider key for an org, so one header-trust bug is the union of every provider's API surface.

Also this window — MCP advisories entering the GHSA database

A cluster of MCP-server advisories was published to the GitHub Advisory Database between 2026-08-14 and 2026-08-19, but for several the original disclosure was June 2026 — the recent date is database ingestion, not discovery. Worth knowing so you don't read them as a fresh wave:

  • @contentful/mcp-server < 1.7.19 / @contentful/mcp-tools < 0.4.5 — CVE-2026-53957 / GHSA-2xhg-73j7-rrgx (CVSS 7.7). export_space / import_space pass LLM-controlled host and proxy arguments straight to the Contentful Management API client, so a prompt injection redirects the request — and the server's Personal Access Token — to an attacker endpoint. DB-published 2026-08-19; originally 2026-06-12.
  • chrome-devtools-mcp ≥ 0.24.0, ≤ 1.0.1 — CVE-2026-53766 / GHSA-8qf9-62x2-82pp (CVSS 6.1), patched 1.1.0. validatePath() uses path.resolve() instead of fs.realpath(), so a symlink that textually sits inside the workspace root escapes it, bypassing the MCP roots capability model. Notable because it is Google's own MCP server. DB-published 2026-08-17; originally 2026-06-16.
  • claude-faf-mcp ≤ 5.7.1, patched 5.7.2 — GHSA-rr55-jp92-8wp2 (CVSS 7.5, no CVE): arbitrary local file read/write via an unconfined path argument accepting absolute paths and ../. The advisory explicitly names prompt injection as the exploitation path (SSH keys, cloud credentials). Sibling advisories exist for faf-mcp (GHSA-j4r7-8ph4-43g3) and grok-faf-mcp (GHSA-cc2g-gq8c-r332).

@ooples/token-optimizer-mcp CVE-2026-55157 also entered the database on 2026-08-14; it is already tracked in the systemic MCP advisory.

Am I affected?

# Spring AI (Maven/Gradle)
grep -rn 'spring-ai' pom.xml build.gradle* 2>/dev/null

# LangChain community + any MCP servers in a Python env
pip list 2>/dev/null | grep -Ei 'langchain-community|mcp'

# npm-side MCP servers named above
npm ls @contentful/mcp-server @contentful/mcp-tools chrome-devtools-mcp \
       claude-faf-mcp faf-mcp grok-faf-mcp 2>/dev/null

# PyCharm build number — need 2026.2.1 or later
ls ~/Library/Application\ Support/JetBrains/ 2>/dev/null || ls ~/.config/JetBrains/ 2>/dev/null

Minimum safe versions established in this batch: Spring AI 2.0.1 · PyCharm 2026.2.1 · Splunk MCP Server app 1.2.1 · Splunk AI Toolkit 6.0.0/6.0.1 · @contentful/mcp-server 1.7.19 / @contentful/mcp-tools 0.4.5 · chrome-devtools-mcp 1.1.0 · claude-faf-mcp 5.7.2. For langchain-community, Headroom, and Spring AI's CVE-2026-59279, the advisory pages do not state fixed versions — check upstream directly rather than assuming.

If you run Headroom or any Spring AI MCP HTTP transport reachable beyond loopback, treat every upstream LLM provider key it holds as potentially exposed and rotate — the SSRF forwards Authorization headers verbatim.

If you are affected

Prevention

The four repeating mistakes in this batch, stated plainly: (1) a limit shown to the model is not a limit enforced at dispatch (Spring AI); (2) an MCP surface opened on the user's behalf still needs authentication (PyCharm, Spring AI transport); (3) an SSRF guard on the obvious path misses the indirection one hop away (LangChain nested sitemaps, Headroom's base-URL override); (4) a request header is never an identity (Headroom).

Sources