AISVS

The first of its kind: how one unbounded request body became a denial-of-service class across every major MCP SDK --- title: "The first of its kind: how one unbounded request body became a denial-of-service class across every major MCP SDK" published: true description: "In April 2026 I reported CVE-2026-39313. Six months later the same flaw had been found and patched in the official Python, Java, Go, Ruby, PHP and TypeScript MCP SDKs. Here is the full class, and why most scanners still cannot see the worst of it." tags: security, mcp, ai, devsecops --- The one-line version In April 2026 I reported CVE-2026-39313, a denial-of-service flaw in an MCP server framework. It was the first CVE of its kind: an unbounded HTTP request body, CWE-770, that lets a single unauthenticated request exhaust a Model Context Protocol server's memory and take it offline. Over the next six months the identical flaw was found and patched in at least nine more MCP projects, including the official Python, Java, Go, Ruby, PHP and TypeScript SDKs. A third-party analysis in July called it "a new vulnerability category." By October two of those CVEs sat in the SDKs that the whole ecosystem is built on, together serving close to half a billion downloads a month. This is the story of that class: how far it spread, who patched and who is still exposed, and why the two worst ones are effectively invisible to the scanners most teams rely on. Every claim below links to a primary source. What the bug actually is MCP servers speak over an HTTP transport: Streamable HTTP, Server-Sent Events, and OAuth routes. To handle a request, the server reads the request body into memory before it does anything else. The flaw is simple and brutal. The read loop has no size limit. It keeps appending chunks to a buffer until the client stops sending or the process dies. There is no authentication in front of it, because the body is read before any auth check runs. So an attacker who can reach the endpoint sends one large POST, or a slow endless stream, and the server allocates memory until it is killed by the OOM reaper. One request, one dead server, no credentials required. This is CWE-770, allocation of resources without limits. It is not exotic. That is exactly why it turned up everywhere. CVE-2026-39313: the first one The first public advisory of this class was in mcp-framework, a popular TypeScript framework for building MCP servers. In versions 0.2.21 and below, the readRequestBody() function in the HTTP transport concatenated body chunks into a string with no cap. The framework even had a maxMessageSize configuration value, but readRequestBody() never referenced it. The limit existed on paper and was never enforced in code. A single large POST to /mcp crashed the server. I reported it, it was fixed in 0.2.22, and the advisory published on 16 April 2026. - Advisory (GitHub, GHSA-353c-v8x9-v7c3): github.com/QuantGeekDev/mcp-framework/security/ad… - CVSS 4.0 8.7 (High), CWE-770 At the time it looked like one framework's mistake. It was not. It was not a bug. It was a pattern. Here is the timeline of the same unbounded-body denial-of-service turning up across the MCP ecosystem, as advisories and patches landed through 2026: - 16 April — mcp-framework, CVE-2026-39313 (the first). - April to June — Google's MCP Toolbox for Databases had the identical io.ReadAll with no limit, reported four days after my advisory and fixed in June. No advisory, no CVE. - July — the official Go SDK added a request-body cap, shipped as OOM protection in its release notes, with no advisory and no CVE. - 30 July — the Ruby SDK, CVE-2026-67432. A 512 MB POST grew a worker from 44 MB to 1.66 GB. Fixed with a 4 MiB default cap. - 19 August — the PHP SDK, CVE-2026-53965, the client-side version: an unbounded SSE buffer. The Java SDK shipped a matching client-side SSE fix the same day. - 16 September — rmcp, the Rust SDK, CVE-2026-63128. - 11 October — mcp-go, CVE-2026-108859. - 14 October — the official Python SDK, CVE-2026-109527, and the official Java SDK, CVE-2026-108395. Both credited to me among the reporters. - 20 and 27 October — the official TypeScript SDK, CVE-2026-111768 and a follow-up advisory. Nine-plus independent projects. The same root cause. The same fix every single time: a default body-size cap, almost always 4 MiB. In July an independent write-up looked at this and called CVE-2026-39313 the first documented denial-of-service against the MCP HTTP transport and "a new vulnerability category." That is the right framing. This was not a run of unrelated bugs. It was one design gap in how MCP transports read input, replicated across every language the protocol ships in. The two that carry the protocol Most of the class lived in frameworks and bindings. Two of them did not. They were in the reference SDKs that nearly every MCP deployment imports. CVE-2026-109527, the official Python SDK (mcp). In versions before 1.29.1, and in the 2.0 pre-releases through 2.0.1, the Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes all buffered complete request bodies with no maximum size. An unauthenticated remote client could send a large declared or streamed body that consumed several times its own size in process memory, and repeat it until the server died. - Advisory (GHSA-fmmv-w9g8-j3gc): github.com/modelcontextprotocol/python-sdk/securi… - Fixed in 1.29.1. CVSS 7.5 (High), CWE-770. - The mcp package serves over 235 million downloads a month on PyPI. CVE-2026-108395, the official Java SDK. Unbounded request-body reads in the mcp-core HTTP server transports, same class, same impact. - Advisory (GHSA-4x8c-5vv7-973f): github.com/modelcontextprotocol/java-sdk/security… - CVSS 7.5 (High), CWE-770. For scale: the official TypeScript SDK pulls around 257 million downloads a month, the Python SDK 235 million. When the flaw sits in the SDK rather than a single server, every server built on that SDK inherits it the moment it exposes an HTTP transport. Who patched, -> Red Hat rated CVE-2026-109527 Important, assessed 44 of its products, and issued three errata: - RHSA-2026:92510 (OpenShift AI 3.4), RHSA-2026:92666 and RHSA-2026:92667 (Satellite 6.19 and 6.18). - Of the 44 products assessed, 35 are affected, 6 not affected, 3 marked will-not-fix. - access.redhat.com Debian tracks the same CVE against python-mcp at severity grave, and at the time of writing the package in unstable is still unfixed. - bugs.debian.org Downstream products started bumping their pins through October: OpenMetadata merged its upgrades, Red Hat's Open Data Hub opened fix PRs, and several hundred automated "bump mcp" pull requests have landed across GitHub since the advisories went live. So the serious operators with security teams are moving. The question is everyone else. The specification still does not require this For all the patching, the root cause has never been closed at the design level. As of early November 2026 the MCP security best-practices document still contains no guidance on request-body size limits. Every SDK solved it independently, with its own default, because the specification never told them to. That is why the same fix had to be rediscovered six, seven, eight times over. The MCP server security guidance that does exist, including the National Security Agency and CISA information sheet on MCP, discusses resource-exhaustion denial of service as a general risk but points implementers at no concrete control for this. The one place that could stop the whole class at the design level still does not mention it. The blind spot: most scanners cannot see the worst two This is current as of 3 November 2026, and it may change the day the databases catch up. Check it yourself. CVE-2026-39313, the npm one, has a full global GitHub advisory. It is in OSV, it is in npm audit, and a scan of a vulnerable project flags it. The two SDK CVEs do not behave the same way. CVE-2026-109527 and CVE-2026-108395 exist only as repository-level advisories on the Python and Java SDK projects. They were never promoted into the global GitHub Advisory Database. The downstream effect is a chain of blindness: - They are absent from the global GitHub advisory mirror, so GitHub Dependabot does not alert on them. - They are absent from OSV, so osv-scanner and everything built on OSV misses them. Querying a vulnerable mcp version returns the other 2026 CVEs but not this one. - They have no record in the PyPA advisory database, so pip-audit finds nothing. - NVD lists both as "Awaiting Analysis" with no version data, so even NVD-driven scanners have no range to match on. The practical result: a server running a vulnerable mcp package can be scanned by pip-audit, osv-scanner, Dependabot, or a popular MCP-specific scanner that wraps pip-audit, and come back clean for the denial-of-service flaw. The patch shipped, the advisory was written, and the machine-readable plumbing that is supposed to warn people never carried it. The enterprise distribution trackers, Red Hat, Debian and SUSE, do carry it, because they ingest from their own CNA and NVD feeds. Red Hat has even published a machine-readable VEX file for it. But the developer-facing supply-chain tools that most teams actually run do not. If you depend on pip-audit or Dependabot to tell you about this, right now they will not. What an attacker gets, and who is at risk You are exposed if you run an MCP server that: - exposes an HTTP-based transport (Streamable HTTP or SSE), as opposed to stdio only, and - is reachable by any client you do not fully trust, which includes the public internet, a shared internal network, or a browser-reachable origin, and - runs a vulnerable version of the framework or SDK below. The attack needs no authentication, no credentials, and no user interaction. One oversized or endless request crashes the process. Repeat it and the service stays down. It is trivially scriptable. There is no data theft here, the impact is pure availability, but for an agent backend that other systems depend on, taking it offline on demand is the whole game. Stdio-only servers and deployments already sitting behind a reverse proxy with its own request-body limit are not exposed in the same way. That proxy limit is also your fastest mitigation while you patch. The fix Upgrade. The fixed versions: - mcp-framework (npm): 0.2.22 or later. - MCP Python SDK (mcp on PyPI): 1.29.1 or later. The fix adds max_request_body_size with a DEFAULT_MAX_REQUEST_BODY_SIZE of 4 MiB in the transport security layer. - MCP Java SDK: the patched mcp-core release. - MCP Go SDK: v1.7.0 or later, which enforces DefaultMaxRequestBodyBytes of 4 MiB. - Ruby SDK (mcp gem): 0.23.0 or later. - PHP SDK, Rust rmcp, mcp-go, TypeScript SDK: upgrade to the latest; all shipped the same body-size cap through the autumn. If you cannot upgrade immediately, put a reverse proxy in front with a client body limit (for example nginx client_max_body_size), and make sure your HTTP transport is not reachable from untrusted networks. Where your SDK exposes a configurable limit, set it explicitly rather than trusting the default, especially if you legitimately handle large payloads. How to find it in your estate - Inventory every MCP server you run and whether it exposes an HTTP transport or stdio only. - For Python, do not trust pip-audit alone for this one today. Check the installed mcp version directly: anything below 1.29.1 is vulnerable. - For npm, npm audit will catch mcp-framework below 0.2.22. - For Java and Go, check the SDK version against the fixed releases above, because the advisories are not yet in the global databases your SCA tooling reads. - Grep your own HTTP handlers for the pattern itself: a body read with no length cap, io.ReadAll(r.Body) in Go, request.body.read with no bound in Ruby, a string += chunk loop in Node, before any size check. If you wrote a custom transport, you may have reproduced the class yourself. The lesson The MCP ecosystem grew faster than its security guidance. A single gap in how transports read input became a denial-of-service class that reached every major SDK in the protocol, and the one control that prevents it is still not written into the specification. The fixes exist now. The specification guidance still does not. And for the two CVEs in the core SDKs, the automated warning system that the rest of us depend on is, as of today, silent. If you run MCP in production, do not wait for a scanner to tell you. Check the versions yourself. References - CVE-2026-39313, mcp-framework: github.com/QuantGeekDev/mcp-framework/security/ad… - CVE-2026-109527, MCP Python SDK: github.com/modelcontextprotocol/python-sdk/securi… - CVE-2026-108395, MCP Java SDK: github.com/modelcontextprotocol/java-sdk/security… - Red Hat, CVE-2026-109527: access.redhat.com - Debian tracker (grave), python-mcp: bugs.debian.org - OWASP AISVS, MCP transport payload-size control citing CVE-2026-39313: github.com/OWASP/AISVS/blob/main/1.0/research/cha… --- Raza Sharif, CyberSecAI Ltd. Reported CVE-2026-39313 and is credited on CVE-2026-109527 and CVE-2026-108395. All vulnerabilities were handled through coordinated disclosure and are fixed in the versions listed above. Contact: contact@agentsign.dev.

Auditing LLM Agents Against 214 OWASP AISVS Requirements: Rico Komenda and Jim Manico at Global AppSec USA 2026 OWASP's AI Security Verification Standard (AISVS) released version 1.01 on October 5, 2026, growing from 191 to 214 testable requirements, with most of the growth in its MCP security chapter. AISVS lists security requirements for applications built on LLMs, agents and retrieval-augmented generation (RAG). Writing "verify that" in a standard is easy, while checking it against a running AI system is not. In their Global AppSec USA 2026 workshop, "Hands-On AI Security Assessment with OWASP AISVS", on Friday, November 6 at 10:30 a.m. in Golden Gate, Rico Komenda and Jim Manico walk through practical assessment scenarios using the standard. Speakers: - Rico Komenda, Senior Product Security Engineer - Jim Manico, Founder, Manicode Security Participants work through real requirements from chapters on prompt injection defense, agentic action security, RAG and vector database hardening, as well as output safety controls. They learn to scope an AI security assessment and select a verification level. They then apply AISVS requirements to LLM-based applications, autonomous agents and MCP-connected tools, so a laptop is needed to follow along. AISVS has three levels. Level 1 is a baseline, Level 2 covers systems handling sensitive data or consequential decisions, and Level 3 is for high assurance. Version 1.01 includes requirements such as rejecting, rather than truncating, inputs that exceed token limits at Level 1. At Level 2, retrieved or tool content must never gain higher priority than the system's own instructions. The MCP security chapter grew from 23 requirements to 40 between versions. On October 20, 2026, the project deferred a planned 2.0 to focus on version 1.02. Rico Komenda is a Senior Product Security Engineer who works on the attack surface of AI-integrated systems. He co-leads AISVS with Jim Manico, Otto Sulin and Russ Memisyazici. Jim Manico founded Manicode Security, which trains developers in secure coding, and founded AISVS. He co-leads OWASP ASVS and wrote "Iron-Clad Java: Building Secure Web Applications." Both speakers also present the AISVS project showcase on Thursday at 10:30 a.m. in Seacliff CD. Komenda gives a talk on security chaos engineering for AI on Thursday at 1:45 p.m. The same team ran this workshop at Global AppSec EU 2026 in Vienna in June. The AISVS repository holds every released version, with requirement IDs that never get renumbered. To go deeper on the topic, start here: - ITSPmagazine podcast: Jim Manico on building AISVS (audio) - OWASP AISVS on GitHub (1.01 release and requirements) - OWASP AISVS project page - LRQA Cyber Labs: AISVS 1.0 chapter-by-chapter - VirtusLab: AISVS 1.0 requirement walkthrough Security testers asked to assess AI features without a defined test scope will practice building one from published requirements. Which AISVS verification level would your production AI features need to meet?

Turning AI Risks Into Testable Security Requirements With OWASP AISVS: Rico Komenda and Jim Manico at Global AppSec USA 2026 OWASP's AI Security Verification Standard reached version 1.0 in June 2026, with 12 chapters of testable requirements for applications built on models, LLMs and AI agents. Most AI security guidance describes risks at a high level. Engineering teams deciding whether an AI-enabled application is secure enough to ship need requirements they can check one by one. AISVS adapts the idea behind OWASP's Application Security Verification Standard (ASVS) for web apps: security should be verifiable and measurable. It turns AI risks into requirements a team can use in design review, testing, procurement and production readiness. In their Global AppSec USA 2026 talk, "OWASP AISVS: Bringing Order to AI Security Chaos", on Thursday, November 5 at 10:30 a.m. in Seacliff CD, Rico Komenda and Jim Manico explain how the standard was built, along with how teams can apply it. Speakers: - Rico Komenda, Senior Product Security Engineer - Jim Manico, Founder, Manicode Security The speakers argue that security practice still assumes deterministic software, while AI systems produce probabilistic output and make decisions on the fly. AISVS keeps the parts of conventional secure development that still apply, then adds new verification categories where they do not. The new categories cover prompts, models, agents, training data, retrieval-augmented generation (RAG), tool use, output handling and AI governance. The talk also shares lessons from building the standard, including where it differs from traditional AppSec. The AISVS project page lists 12 chapters, from training data integrity through MCP security to monitoring and anomaly detection. Requirements fall into three levels: a baseline, a level for production or customer-facing apps, and a level for safety-critical or regulated systems. Rico Komenda is a Senior Product Security Engineer who works on the attack surface of AI-integrated systems and secure agentic development. He is one of the AISVS project leaders, along with founder Jim Manico, Otto Sulin and Russ Memisyazici. Komenda contributes to the OWASP GenAI Security Project. He previously worked as a Senior Security Consultant at adesso SE. At Global AppSec EU 2025 in Barcelona, he co-presented "Builders and Breakers: A Collaborative Look at Securing LLM-Integrated Apps," taking the red team side with live data poisoning demos. His other talks include "Pentesting LLM-integrated applications" at JavaLand 2025. Jim Manico founded Manicode Security, which trains developers in secure coding. He founded AISVS and wrote "Iron-Clad Java: Building Secure Web Applications." He also co-leads OWASP ASVS along with the OWASP Cheat Sheet Series. Komenda also presents "Security Chaos Engineering for AI Application Architectures" on Thursday at 1:45 p.m. The two speakers then run a hands-on AISVS assessment workshop on Friday, November 6 at 10:30 a.m. in Golden Gate. The pair first presented AISVS together in a lightning talk at Global AppSec EU 2026 in Vienna, before version 1.0 shipped. LRQA Cyber Labs has since published a chapter-by-chapter overview of the 1.0 release. To go deeper on the topic, start here: - OWASP AISVS GitHub repository - OWASP AISVS project page - LRQA Cyber Labs: OWASP AISVS 1.0 chapter-by-chapter overview - VirtusLab: OWASP AISVS 1.0 walkthrough - ITSPmagazine interview with Jim Manico on AISVS AppSec teams asked to sign off on AI features, without a checklist that fits them, will find one here. What would your team check first before approving an AI feature for production?

Locking Down Claude Code and Codex Before They Write Insecure Code: Jim Manico at Global AppSec USA 2026 AI coding assistants can mishandle secrets, overreach with dangerous permissions and produce code that looks correct while quietly violating security requirements, according to Jim Manico's workshop description. Manico, who co-leads the OWASP Cheat Sheet Series, teaches developers to take control of those assistants instead of trusting them by default. In a 2025 interview, he said top AI coding tools, including Claude and Copilot, generate insecure code by default unless prompted for security. The workshop starts by setting up Claude Code and Codex environments from scratch. Participants configure permission controls, project-level security rules in a claude.md file, hooks and sandboxing. In his Global AppSec USA 2026 training, "Secure Code with AI: Building a Trustworthy Spec-Driven AI Code Workflow", on Wednesday, November 4 at 9:00 a.m. in Seacliff D, Jim Manico walks participants through a demo-driven workflow on real codebases. Speaker: Jim Manico, Founder, Manicode Security Spec-driven development means writing the security requirements down before any code is generated, so the assistant works from them. Participants load secure coding prompts aligned with OWASP guidance to push the tools toward secure-by-default output. They then use Claude Code alongside Codex for code generation, independent security review, test creation and vulnerability detection. The workshop catalogs insecure patterns AI assistants commonly produce: weak authorization, injection flaws, insecure secret handling, unsafe dependencies and insufficient validation. Jim Manico founded Manicode Security, which trains developers in secure coding. He is a Java Champion, author of "Iron-Clad Java: Building Secure Web Applications" and co-leader of the OWASP Application Security Verification Standard (ASVS). He founded and leads OWASP AISVS, a catalog of testable security requirements for AI-enabled systems organized into 12 chapters. He also gives the AISVS talk at the conference on Thursday, November 5 at 10:30 a.m. He invests through Aviso Ventures in security startups including Semgrep, Edgescan and DefectDojo. He is a Strategic Technical Advisor to Edgescan. The workshop extends his recent teaching. At SecAppDev 2026 he ran "Enterprise AI Coding with Claude Code," a workflow built on repository governance files such as CLAUDE.md, SECURITY.md and REQUIREMENTS.md. At Global AppSec EU 2025 he presented "Leveraging AI for Secure React Development with Effective Prompt Engineering." To go deeper on the topic, start here: - AI-Powered Secure Coding (Jim Manico, Edgescan on-demand webinar) - Model Context Protocol (MCP) Security slides (SecAppDev 2026) - Using AI to Write Secure React.JS Code slides (SecAppDev 2025) - OWASP AISVS on GitHub - OWASP Cheat Sheet Series Developers who already ship code from AI assistants, along with the security engineers who review it, will leave with a configuration they can copy to their own repositories. What security rules have you written into your own AI coding assistant's configuration?

@liran_tal Agreed. This may help both as a machine-readable security guide and a verification standard. We put tons of work into this! OWASP/AISVS

@ottosulin Wut up Otto! Otto is one of the co-authors of the AISVS owasp/AISVS