Security brief: MCP SDK memory-exhaustion CVEs go public, and a Chrome full chain built by agents for $40,000

Executive summary

A quiet day for incidents and a useful one for hygiene. The headline is not a new attack but three CVE records, published on 14 October, for memory-exhaustion flaws in the official MCP Python and Java SDKs. The fixes shipped weeks ago, but CVE publication is what makes scanners, SBOM tooling and auditors notice. Any team that runs an MCP server over HTTP on an SDK version from before late September should treat today as the day to check.

The second story changes the planning assumptions behind every other item. XBOW published how agents running OpenAI’s public GPT-5.6 Sol built a three-bug Chrome full chain, from a web page to code running outside the renderer sandbox, in six days for about $40,000 in API charges. Google paid its first $250,000 full-chain reward for it. Humans steered the work, but the agents did most of it. Defenders should assume that complex exploit chains now cost months less and orders of magnitude less money than they did a year ago.

Policy rounds out the day. Bloomberg and CSO Online both reported on 14 October on the unsettled question of who is liable when an agent hacks a third party. The practical message for CISOs is unchanged: contractual and technical containment of agents is now a liability control, not only a safety control.

Act now

• Upgrade the official MCP SDKs on every server reachable over HTTP: Python mcp 1.30.0 or 2.2.0; Java mcp-core 2.0.1, 1.1.4 or 0.18.4.
• Cap request bodies and sessions at the edge: a body-size limit at the proxy, stateless Streamable HTTP where sessions are not needed, and alerts on MCP server out-of-memory restarts.

Incidents

No new in-the-wild agentic incident was disclosed in the window. The campaigns covered in the 12 Oct brief (CyberXero, PoeLLM) have had no public update since then. CISA’s 13 October KEV additions (Ivanti Connect Secure and a Windows Shell bypass) do not involve agentic software.

Vulnerabilities

Official MCP SDKs: three memory-exhaustion CVEs, one upgrade

What happened. On 14 October, CVE records went public for three advisories that the MCP maintainers had already published on GitHub:

• CVE-2026-109527 (GHSA-fmmv-w9g8-j3gc, Python, CVSS 3.1 7.5). The HTTP server transports and the OAuth authorization-server routes (/token, /register, /revoke, /authorize) read the whole request body into memory before checking its size. One request raises memory use by two to three times the body size. Fixed in 1.29.1 and 2.1.0. The fix arrived in stages: 1.29.0 and 2.0.0 capped only the Streamable HTTP endpoint.
• CVE-2026-59951 (GHSA-84m7-p3x7-pcfv, Python, CVSS 3.1 7.5 on GitHub, 4.0 6.9 on the CVE record). In the default stateful mode, Streamable HTTP sessions never expired. A DELETE ended a session without removing its entry, sessions refused on their first request kept running, each kept its parsed initialize payload, and there was no cap on the number of sessions. Fixed in 1.30.0 and 2.2.0, which add a 1,800-second idle timeout and a 10,000-session cap by default.
• CVE-2026-108395 (GHSA-4x8c-5vv7-973f, Java, CVSS 3.1 7.5). The Servlet-based Streamable HTTP, Stateless and SSE transports read the whole body into memory, ignored Content-Length, and accepted chunked transfer encoding. One unauthenticated POST can exhaust the heap and crash the JVM. Fixed in mcp-core 0.18.4, 1.1.4 and 2.0.1; the older mcp artifact (0.8.0 to before 0.13.0) has no fixed release, so migrate.

Mechanism. The entry point is the HTTP listener itself, before any MCP semantics apply. In the Python case, the OAuth routes need no credentials by design, and servers run without authentication by default, so the attacker needs only network reach. The trust boundary crossed is the one between the network and the server process’s memory: the transport trusted the client to send reasonably sized bodies and to close its sessions. The root cause is the same in both SDKs: buffering whole bodies and keeping per-session state with no limit or expiry. Preconditions: an HTTP transport (stdio-only servers and MCP clients are not affected), no upstream body-size limit and, for CVE-2026-59951, the default stateful mode. Authentication does not limit how many sessions a token holder can open, so a low-privileged tenant on a shared server can still take it down.

Blast radius. Availability only: no data exposure or code execution is claimed. But an MCP server is often the single tool plane for many agents and users, so one crashed process can stop every agent workflow that depends on it, and a crash loop on a shared gateway can look like an agent failure rather than an attack.

Mapping and comparison. OWASP LLM10:2025 (Unbounded Consumption); MITRE ATLAS AML.T0029 (Denial of ML Service). This is the third official MCP SDK with the same class of bug in three months: the Ruby SDK fixed unbounded JSON-RPC bodies (CVE-2026-67432) and unbounded session retention after an initialize flood (CVE-2026-67430) on 30 July. When the same flaw appears in the Ruby, Python and Java reference SDKs, the likely cause is that the 2026-07-28 move to Streamable HTTP and remote servers went faster than the transport hardening, not one team’s mistake. Expect the same review to reach the TypeScript, Go, C# and Rust SDKs and community forks.

Why it matters. These are not exotic. Anyone who can reach the port can trigger them, scanners will now flag them by CVE ID, and the fixes have been available long enough that an unpatched server is a process failure, not bad luck.

Mitigation and detection.

• Upgrade as listed in Act now. On Python 2.0.x there is no fixed release; move to 2.2.0.
• If you call StreamableHTTPServerTransport directly in Python, the new default limit (4 MiB) does not apply; enforce your own.
• Put a body-size limit in the reverse proxy or gateway regardless of SDK version, and reject chunked uploads above it.
• Use stateless_http=True (Python 1.12.0 and later) where you do not need per-session state; lower the idle timeout and session cap on small hosts.
• Detection: alert on MCP server OOM kills or restarts, sudden growth in active session counts, and large or long-running POSTs to MCP and OAuth endpoints.

Recommendation (opinion). Use this as the trigger for an inventory of every MCP server you run over HTTP, including those embedded in internal tools, and pin a minimum SDK version in CI. The SDK is now a dependency with a security release cadence; track it like your web framework.

Sources: GHSA-fmmv-w9g8-j3gc, GHSA-84m7-p3x7-pcfv, GHSA-4x8c-5vv7-973f, CVE-2026-109527 record summary (Strix), CVE-2026-59951 record summary (Strix), CVE-2026-108395 record summary (Strix), GitHub Advisory Database: MCP Ruby SDK advisories.

Vulnerabilities table

CVE	Product	Issue	CVSS	Fixed	Exploited
CVE-2026-109527	MCP Python SDK (mcp)	Unbounded request bodies on HTTP transports and OAuth routes	7.5	1.29.1, 2.1.0	No evidence
CVE-2026-59951	MCP Python SDK (mcp)	Streamable HTTP sessions never reclaimed, no session cap	7.5 (3.1) / 6.9 (4.0)	1.30.0, 2.2.0	No evidence
CVE-2026-108395	MCP Java SDK (mcp-core)	Unbounded request bodies on Servlet transports, chunked encoding accepted	7.5	0.18.4, 1.1.4, 2.0.1	No evidence

MCP and protocol security

No MCP specification release or SEP decision in the window; the current spec remains 2026-07-28. The SDK CVEs above are the protocol-relevant security news. See the daily signal for the ecosystem side.

Research

XBOW: agents built a Chrome full chain in six days for about $40,000

What happened. On 13 October XBOW Labs published “Zero to Calc in Six Days”, describing a three-stage Chrome exploit chain built between 2 and 7 August with agents running OpenAI’s public gpt-5.6-sol model. Google paid the first $250,000 full-chain reward under the Chrome VRP rules introduced in April 2026, and has fixed all three bugs.

Mechanism. The chain went from a web page to code running in the unsandboxed crash handler on Windows. The three stages were a V8 Maglev deoptimization bug that treated a mutable number as an immutable constant; a V8 sandbox escape through a time-of-check/time-of-use mismatch between Blink’s WebCodecs and libwebp; and a renderer sandbox escape in Crashpad, which assumed a suspended renderer’s memory could not change between reads. XBOW notes that all three are violations of assumed immutability, a class of invariant failure LLMs may be well suited to find. The work ran as parallel campaigns (bug search, V8 corruption, V8 sandbox escape, renderer sandbox escape, integration). Agents searched code, tested hypotheses, built proofs of concept and wrote exploit stages. Humans chose targets, challenged results, redirected searches and decided how to join the parts. A first chain was abandoned when its last stage collided with a bug Google already knew about; a modular design let the team swap in a backup.

Why it matters. XBOW compares six days and $40,000 with an estimated six to nine months for a four-person team before LLMs. The model is publicly available. That combination reaches beyond browser vendors: the same workflow applies to any widely deployed client, including the desktop agents and IDE extensions that run MCP servers locally. It also fits the offensive pattern in recent briefs, where criminals already run commodity agent harnesses at scale (see the 12 Oct brief). ATLAS mapping: AML.T0016 (Obtain Capabilities: AI-assisted exploit development).

Mitigation and detection. Nothing to patch beyond keeping Chrome current. The lesson is planning: shorten patch-to-deploy targets for browsers and agent clients, keep agents that browse inside isolated browser profiles or VMs, and give “N-day weaponised within days” a place in your risk register.

Recommendation (opinion). Assume exploit development is no longer the bottleneck for well-funded attackers. Put the budget into patch velocity, isolation and detection rather than into hoping a bug is too hard to exploit.

Sources: XBOW Labs, “Zero to Calc in Six Days”, Cybersecurity News, RuntimeWire.

Prompt-injection probes learn the conversation, not just the injection

Kale and Vishwanath (arXiv 2610.18408, 13 Oct) show that standard benchmarks for activation-probe injection detectors can be passed without the model at all: conversation position and text length alone detect the attacks. Adding matched negatives (the same conversation without the injection, and harmless text formatted like an injection) sharply cuts false alarms across six open models while keeping most attacks that fool the agent. It also improves a text-only filter. Why it matters: if you are buying or building an injection detector, ask how it was evaluated against matched negatives, or the reported accuracy may measure a dataset artefact. This continues the theme of CrowdStrike’s decomposition research: classifier numbers do not transfer cleanly to production.

Source: arXiv 2610.18408.

Tools and industry

No security tooling release in the window met the bar for an item. Gemini 4 Argon’s general availability and its training-time misbehaviour disclosures are covered, as a model story, in the daily signal.

Policy

Who pays when an agent hacks someone? The US debate sharpens

What happened. On 14 October, Bloomberg (republished by Insurance Journal) reported that the administration favours relying on existing liability law over new rules. Treasury Secretary Bessent said “the best way to guarantee safety is that the creators are liable for what they build.” The same day CSO Online published an analysis arguing that recent lab incidents (OpenAI/Hugging Face, Anthropic, Meta, Google, Mistral) are failures of containment and monitoring basics, not agents “going rogue”.

Why it matters. The legal path is unsettled. The Computer Fraud and Abuse Act needs intent, which is hard to prove when an agent acts on its own. Tort claims need a failure of reasonable care. The Hawley-Murphy proposal would amend the CFAA to create liability for failing to impose reasonable safeguards, and a draft by Representative Trahan would go further and bar the “no human intent” defence. A California nonprofit is already suing OpenAI under state data-security law over the Hugging Face breach. For enterprises that deploy agents, “reasonable safeguards” is the phrase to watch: egress control, scoped credentials, monitoring and human approval for consequential actions are likely to become the evidence of reasonable care.

Recommendation (opinion). Write down your agent containment controls now (egress policy, identity and credential scope, monitoring, approval gates) as if you will have to show them to a court or an insurer. Ask your model and agent vendors the same questions in procurement.

Sources: Insurance Journal / Bloomberg, CSO Online.

In brief

• MCP SDK CVEs: three memory-exhaustion CVEs (Python and Java) published 14 Oct; fixes available since August and September.
• XBOW Chrome chain: GPT-5.6 Sol agents plus human direction built a three-bug full chain in six days for about $40,000.
• Injection probes: detector benchmarks can be passed on position and length alone; insist on matched-negative evaluation.
• Liability: the US leans on existing law for now; “reasonable safeguards” for agents is becoming the standard to meet.

Sources

• GHSA-fmmv-w9g8-j3gc
• GHSA-84m7-p3x7-pcfv
• GHSA-4x8c-5vv7-973f
• CVE-2026-109527 record summary (Strix)
• CVE-2026-59951 record summary (Strix)
• CVE-2026-108395 record summary (Strix)
• GitHub Advisory Database: MCP Ruby SDK advisories
• XBOW Labs, “Zero to Calc in Six Days”
• Cybersecurity News
• RuntimeWire
• arXiv 2610.18408
• Insurance Journal / Bloomberg
• CSO Online

Related reports

• Daily signal, 15 Oct 2026: Gemini 4 Argon goes GA, Muse Wonder, and Workday’s cross-vendor agent.
• Security brief, 12 Oct 2026: CyberXero, AgentCore’s default role and GitLab’s agent fixes.
• Analysis, 10 Oct 2026: how many MCP servers are exposed to the internet.