https://vulnerability.circl.lu/sightings/feed 2026-09-03T04:51:21.330611+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/b344273a-47ab-4723-a02c-69aa6b59ac79/export 2026-09-03T04:51:21.415522+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "b344273a-47ab-4723-a02c-69aa6b59ac79", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-67431", "type": "seen", "source": "https://gist.github.com/Correctover/36ce05054d457c4fb176b23f08f9962b", "content": "# MCP Protocol Security in 2026: Why Patching Isn't Enough \u2014 And What Runtime Verification Solves\n\n> **Author**: Guigui Wang, Correctover \n> **Date**: August 4, 2026 \n> **Relevance**: AI Agent infrastructure, MCP security, runtime verification standards\n\n---\n\n## TL;DR\n\nThe Model Context Protocol (MCP) has accumulated **at least 5 confirmed CVEs** in 2026 alone \u2014 DNS rebinding, session hijacking, session poisoning, cross-client data leaks, and Origin header bypass. Every single one follows the same pattern: the protocol trusts its environment without verifying it.\n\nI'm the author of **CCS (Correctover Computing Standard)**, the first IETF submission for AI Agent runtime verification (draft-correctover-ccs-00). This blog post shows how CCS's 7-dimensional runtime verification framework would have caught these vulnerabilities **systemically** \u2014 not as individual patches, but as a class of problems.\n\nIf you're running MCP-based AI agent infrastructure, you need to think about runtime verification, not just patching. Here's why.\n\n---\n\n## The MCP Vulnerability Catalog (2026)\n\n### CVE-2026-11624: DNS Rebinding Attack\n**Severity**: High \n**Affected**: All MCP server implementations prior to v0.25 \n**Root Cause**: Missing `Origin` header validation\n\nAn attacker-controlled domain uses DNS rebinding to redirect a victim's browser to `127.0.0.1`, where a local MCP server is running. Because the server doesn't validate `Origin` headers, it accepts connections from the browser context \u2014 allowing arbitrary tool execution.\n\n**Impact**: Any website a developer visits while running an MCP server locally could weaponize this. File reads, command execution, database access \u2014 all through the agent's tool interface.\n\n### CVE-2026-67431: Session Poisoning (Ruby SDK)\n**CVSS**: 8.3 (High) \n**Affected**: `mcp` Ruby gem < v0.23.0 \n**Root Cause**: Transport layer doesn't bind sessions to their owners\n\nThe stateful transport implementation failed to bind established sessions to their original owners or connection contexts. Any actor with access to a session ID can execute arbitrary tool calls.\n\n### CVE-2026-52869: Session Hijacking (Python SDK)\n**CVSS**: 7.1 (High) \n**Affected**: MCP Python SDK < v1.27.2 \n**Root Cause**: JSON-RPC requests routed purely on user-controlled session IDs without ownership validation\n\nA bearer-token-authenticated attacker can hijack and inject JSON-RPC messages into another client's session by supplying their session ID. The transport layer accepts any valid token and routes to the target session.\n\n### CVE-2026-25536: Cross-Client Data Leak (TypeScript SDK)\n**CVSS**: 7.1 (High) \n**Affected**: `@modelcontextprotocol/sdk` v1.10.0 through v1.25.3 \n**Root Cause**: Race condition in shared server/transport state\n\nWhen a single server or transport instance serves multiple clients, one client's tool results, notifications, and sampling requests can be delivered to another client. The trigger is ordinary concurrent load, not a crafted attack.\n\n### OX Security Findings: STDIO Transport Architecture\nThe MCP STDIO transport spawns a new process for every connection. This architectural choice means:\n- Each connection has its own process boundary (isolation?)\n- But also: each connection can access the full host system\n- No centralized verification of what the spawned process does\n\n---\n\n## The Pattern: Protocol Trust Without Runtime Verification\n\nLook at all five CVEs. They share a fundamental pattern:\n\n> **MCP trusts its environment. It assumes that if you have a valid connection, you're authorized. If you have a session ID, you own it. If you can reach localhost, you're a legitimate client.**\n\nThis is a **design-level assumption**, not a bug. And it's the same assumption that causes every new CVE.\n\nPatching one vulnerability doesn't fix the pattern:\n- Adding Origin validation fixes DNS rebinding but doesn't prevent the next spoofing attack\n- Binding sessions to owners prevents hijacking but doesn't validate what the session does\n- Isolating transport state prevents leaks but doesn't verify tool execution intent\n\nWhat MCP needs is not another patch. It needs **runtime verification** \u2014 continuous, systematic validation of every agent action against its authorization and intent.\n\n---\n\n## How CCS Solves This Systemically\n\nCCS (draft-correctover-ccs-00) is a 7-dimensional runtime verification framework submitted to IETF. Here's how each dimension addresses the MCP vulnerability pattern:\n\n### 1. Structure Verification\n**What it checks**: Is the incoming request structurally valid? Does it conform to the expected schema?\n\n**Catches**: Malformed JSON-RPC, unexpected tool call parameters, requests that don't match the server's capability declaration.\n\n### 2. Schema Verification \n**What it checks**: Does the request match the declared tool/resource schema?\n\n**Catches**: Cross-client data leaks (responses with wrong schema), session poisoning (requests with wrong parameter types).\n\n### 3. Latency Verification\n**What it checks**: Is the response time within expected bounds?\n\n**Catches**: DNS rebinding attacks (abnormal latency patterns when browser proxies to localhost), replay attacks (timing anomalies).\n\n### 4. Cost Verification\n**What it checks**: Does the operation stay within declared resource bounds?\n\n**Catches**: Resource exhaustion through tool spam, unexpected computational costs from hijacked sessions.\n\n### 5. Identity Verification\n**What it checks**: Is the requesting entity who it claims to be? Is the session bound to the authenticated principal?\n\n**Catches**: Session hijacking (CVE-2026-52869), session poisoning (CVE-2026-67431). CCS binds session identity to the authenticated principal at the transport layer.\n\n### 6. Integrity Verification\n**What it checks**: Has the data been tampered with? Is the response from the expected source?\n\n**Catches**: Cross-client data leaks (CVE-2026-25536), response injection. CCS verifies data integrity at the byte level.\n\n### 7. Security Verification\n**What it checks**: Does the observed behavior match the declared authorization policy?\n\n**Catches**: DNS rebinding (CVE-2026-11624), STDIO process escape. CCS verifies that every tool execution stays within the declared authorization boundary, regardless of the transport mechanism.\n\n### Performance\n- **P50 latency**: ~133\u03bcs (out-of-process) / ~7.5\u03bcs (in-process)\n- **Verification mode**: Continuous, per-action\n- **False positive rate**: 0% across 28 audited projects\n\n---\n\n## The Self-Evolution Problem\n\nHere's what makes this worse: MCP is a **living protocol**. New transports are added. New SDKs are implemented. New tool patterns emerge. Every change introduces new attack surfaces.\n\nStatic patches can't keep up. You need a verification engine that **evolves** with the protocol.\n\nThat's why CCS includes a self-evolving detection engine (MCPFuzz):\n- **Layer 1**: Static analysis of known vulnerability patterns\n- **Layer 2**: Dynamic fuzzing with semantic-aware test generation\n- **Layer 3**: Behavioral analysis that discovers new bypass patterns autonomously\n\nThis isn't a rule engine. It's an agent that continuously learns what \"normal\" MCP behavior looks like and flags deviations. It achieved **0 false positives** across 28 production projects in the agent ecosystem.\n\n---\n\n## What This Means for You\n\n### If you're an MCP server operator:\n- Upgrade to the latest SDK versions (v0.25+ for Python, v0.23.0+ for Ruby, v1.26.0+ for TypeScript)\n- Implement Origin header validation\n- Bind sessions to authenticated principals\n- Isolate transport state per client\n\nBut also: **deploy runtime verification**. The patches fix known CVEs. CCS prevents the next class of vulnerabilities.\n\n### If you're building on MCP:\n- Don't assume the protocol is secure. It's a living standard with fundamental trust assumptions.\n- Add CCS verification to your agent pipeline. 133\u03bcs overhead is negligible compared to the risk.\n- Audit your tool execution policies. What is your agent authorized to do? CCS enforces that at runtime.\n\n### If you're an enterprise deploying AI agents:\n- MCP is the connective tissue between your LLM and your enterprise tools (databases, APIs, file systems).\n- A vulnerability in MCP is a vulnerability in your entire agent infrastructure.\n- Runtime verification is not optional. It's the difference between \"we patched the known CVEs\" and \"we systematically prevent the class of problems.\"\n\n---\n\n## The Standard Matters\n\nCCS is not just my project. It's submitted to IETF (draft-correctover-ccs-00, Submission #167254). This means:\n- It's a community standard, not a vendor lock-in\n- It's transparent, auditable, and open\n- It's designed to be adopted across the ecosystem\n\nThe DOI (10.5281/zenodo.21783723) provides timestamped proof of priority. The ccs-verifier SDK is on PyPI (v0.4.1). The code is open source.\n\nI'm not selling anything. I'm establishing a standard and proving it works. The question is whether the ecosystem adopts it before or after the next major MCP vulnerability makes headlines.\n\n---\n\n## Resources\n\n- **CCS IETF Draft**: https://datatracker.ietf.org/submit/status/167254/\n- **CCS DOI**: https://doi.org/10.5281/zenodo.21783723\n- **ccs-verifier SDK**: https://pypi.org/project/ccs-verifier/\n- **GitHub**: https://github.com/Correctover/ccs-verifier\n- **MCP CVE-2026-11624**: https://cvereports.com/reports/CVE-2026-11624\n- **MCP CVE-2026-52869**: https://cvereports.com/reports/CVE-2026-52869\n\n---\n\n*Guigui Wang is the author of CCS and founder of Correctover. Correctover's mission is to make AI Agent runtime verification a standard practice, not an afterthought.*\n", "creation_timestamp": "2026-08-04T06:51:03.379559Z"} 2026-08-04T06:51:03.379559+00:00 https://vulnerability.circl.lu/sighting/1e681153-7a81-4e69-b8e0-2b0870cfa1b5/export 2026-09-03T04:51:21.423503+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "1e681153-7a81-4e69-b8e0-2b0870cfa1b5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-67431", "type": "seen", "source": "https://gist.github.com/alon710/eb7bbb63a594430d7d6ab18e1b915ebd", "content": "# CVE-2026-67431: CVE-2026-67431: Session Poisoning via Improper Access Control in Model Context Protocol Ruby SDK\n\n> **CVSS Score:** 8.3\n> **Published:** 2026-07-30\n> **Full Report:** https://cvereports.com/reports/CVE-2026-67431\n\n## Summary\nAn Improper Access Control vulnerability exists in the Model Context Protocol (MCP) Ruby SDK prior to version 0.23.0. The stateful transport implementation failed to bind established sessions to their original owners or connection contexts, enabling unauthorized actors with access to active session IDs to execute arbitrary tools or alter session state.\n\n## TL;DR\nA lack of session binding in the MCP Ruby SDK allows remote attackers possessing a valid session ID to execute arbitrary tool calls and manipulate session states.\n\n## Exploit Status: POC\n\n## Technical Details\n\n- **CWE ID**: CWE-284\n- **Attack Vector**: Network (AV:N)\n- **CVSS v4.0 Score**: 8.3\n- **EPSS Score**: 0.00276\n- **Exploit Status**: POC (in official repository tests)\n- **KEV Status**: Not Listed\n- **Impact**: High Integrity, Low Availability\n\n## Affected Systems\n\n- mcp (RubyGems)\n- Model Context Protocol Ruby SDK\n- **mcp**: < 0.23.0 (Fixed in: `0.23.0`)\n\n## Mitigation\n\n- Upgrade the mcp gem to version 0.23.0 or higher.\n- Implement the session_request_validator hook to validate incoming requests against active user authentication states.\n- Limit session idle timeouts and maximum concurrent sessions to reduce exposure.\n\n**Remediation Steps:**\n1. Identify all deployments using the mcp Ruby gem.\n2. Update the Gemfile to require version 0.23.0 or higher: gem 'mcp', '>= 0.23.0'.\n3. Execute bundle update mcp to install the patched version.\n4. Locate instantiate configurations of MCP::Server::Transports::StreamableHTTPTransport and define a custom session_request_validator callback.\n5. Ensure the callback validates that the user environment (cookies, tokens) matches the active session ownership context.\n\n## References\n\n- [https://www.cve.org/CVERecord?id=CVE-2026-67431](https://www.cve.org/CVERecord?id=CVE-2026-67431)\n- [https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-5p9g-j988-pcwv](https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-5p9g-j988-pcwv)\n- [https://github.com/modelcontextprotocol/ruby-sdk/commit/35466605319a34e4c7808712ae9bb1ca1afb2356](https://github.com/modelcontextprotocol/ruby-sdk/commit/35466605319a34e4c7808712ae9bb1ca1afb2356)\n- [https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v0.23.0](https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v0.23.0)\n- [https://nvd.nist.gov/vuln/detail/CVE-2026-67431](https://nvd.nist.gov/vuln/detail/CVE-2026-67431)\n\n\n---\n*Generated by [CVEReports](https://cvereports.com/reports/CVE-2026-67431) - Automated Vulnerability Intelligence*", "creation_timestamp": "2026-07-31T02:31:09.791759Z"} 2026-07-31T02:31:09.791759+00:00 https://vulnerability.circl.lu/sighting/feade581-b2be-4ef2-8950-fd2a58037a56/export 2026-09-03T04:51:21.423686+00:00 Joseph Lee https://vulnerability.circl.lu/user/syspect {"uuid": "feade581-b2be-4ef2-8950-fd2a58037a56", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-67431", "type": "published-proof-of-concept", "source": "https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-5p9g-j988-pcwv", "content": "", "creation_timestamp": "2026-07-30T16:35:20.729425Z"} 2026-07-30T16:35:20.729425+00:00 https://vulnerability.circl.lu/sighting/706fbabc-bd15-4add-9819-b116f1bc6170/export 2026-09-03T04:51:21.426381+00:00 Automation user https://vulnerability.circl.lu/user/automation {"uuid": "706fbabc-bd15-4add-9819-b116f1bc6170", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-67431", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3mrsu6t2mfx2q", "content": "CVE-2026-67431 - MCP Ruby SDK: Ruby SSE Session Poisoning\nCVE ID : CVE-2026-67431\n \n Published : July 29, 2026, 8:17 p.m. | 26\u00a0minutes ago\n \n Description : MCP Ruby SDK is the official Ruby SDK for Model Context Protocol servers and clients. Prior to 0.23.0, MCP::Server::Trans...", "creation_timestamp": "2026-07-29T21:21:23.968372Z"} 2026-07-29T21:21:23.968372+00:00