java-sdk

Java 接 MCP，还得自己拼协议？ MCP 官方 Java SDK，客户端服务端都包，同步异步都支持，Spring AI 共建，Java 17 起可用。 适合 Java 接 AI 工具的人，先看客户端，别抄服务端例子。 你 Java 接 MCP 先做客户端还是服务端？ #MCP #Java @grok modelcontextprotocol/java-sdk

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.

Java appからAI modelやtoolへの接続を、MCP interfaceで揃える。 MCP Java SDKはJava applicationがAI modelやtoolと標準化されたinterfaceでやり取りするためのproject群。同期・非同期のcommunicationに対応します。 modelcontextprotocol/java-sdk

AIに「読むだけ」と頼む前に、MCPの権限をどこで確かめるか たとえば、社内の案件一覧をAIに読ませ、状況をまとめてもらいたいとします。「更新はせず、読むだけで」と伝え、MCPで接続しました。その接続が本当に読み取りだけに制限されているか、何を見れば判断できるでしょうか。 MCPは、AIが外部の機能を使うための仕組みです。ここでは、その機能を「ツール」と呼びます。MCPを業務APIやデータへ接続する人に向けて、ツール一覧の表示と、操作を実行できる権限を分けて確かめる方法を整理します。 まず接続先の権限を絞る 読み取りだけを任せたいなら、AIへの指示に加えて、接続に使うアカウントや認証情報の権限を必要な範囲に絞ります。そのうえで、サーバーやAPI側が、呼出時に権限を検証する構成かを確認します。「読むだけで」という指示は作業の意図を伝えるものですが、接続先の権限設定を確かめたことにはなりません。 一覧から更新用のツールを外すことと、更新の要求を受け付けないことも、分けて見る必要があります。同じ設定で両方を管理できる製品もありますが、自分の接続がその構成になっているかを確かめます。 一覧にあることも、ないことも、実行可否の証拠にはならない MCPで一覧を取得する要求は tools/list、ツールを呼び出す要求は tools/call です。 GitHub MCP serverの2026年6月の個別要望には、権限のないツールも表示され、呼び出して 403 が返るまで権限不足が分からないという問題が書かれています。当時の実装についての報告なので、現在の全製品で同じ問題が続いているとは言えません。それでも、一覧にあることと実行できることが一致しない例として読めます。 逆に、一覧にないから安心とも限りません。取得時のJava SDKの公式文書は、一覧フィルタが制御するのは表示だけで、隠したツールも名前を指定して呼び出せると説明しています。そのため、実際に処理する側で権限を検証する必要があると明示しています。同SDKの実装説明であり、すべてのMCPサーバーが同じ動作をするという意味ではありません。 一覧は確認の入口になります。ただ、その接続が何を拒否するかを知るには、実行時の認可も確かめる必要があります。認可とは、その要求を実行する権限があるかを接続先で確かめることです。 一覧と呼出しを同じ管理設定で扱う実装例 この違いを管理する例として、Googleは2026年10月14日に、Apigee hybridでMCPを扱う方式を解説しています。対象の1.17.0は9月14日にリリースされたもので、10月14日が機能の初公開というわけではありません。 Apigeeは、APIへのアクセスを管理する製品です。公式の設定ガイドでは、クライアントに許可する操作を、API productという設定のまとまりで管理します。要求内容を解析するParsePayloadと認証ポリシー、API productの必要な設定がそろう場合、一覧を許可されたツールに絞ります。また、ガイドの認証ポリシーの説明では、登録されていないツールの要求は 401 Unauthorized で拒否するとしています。 注目したいのは、一覧の表示と呼出時の制御を、既存のAPI管理設定のもとで扱う点です。Apigee hybridでは、MCPの処理を自社クラスタ内に置く方式も説明されています。ただし、接続しただけですべてのMCPに同じ制御が付くわけではありません。小規模チームにもApigeeの導入が適する、導入すれば事故が減る、と実測した話でもありません。 自分の接続では、何を根拠に制限しているか 製品名より先に、使っている接続を一つ選び、次の表を埋めてみます。これは公式標準ではなく、この記事での点検案です。 見る場所 確かめる内容 根拠がない場合 接続先とアカウント 想定したサーバー・利用者・対象データか 確認が取れるまで機密データを渡さない 表示される一覧 どのツールが見え、どの設定で絞っているか 非表示だけで実行不能と判断しない 呼出時の権限 サーバー・ゲートウェイ・APIのどこで拒否するか 読み取り専用の確認は未完了と記録する 対象データの権限 どの案件・ファイルなどにアクセスできるか 不明な範囲へ対象を広げない 設定や既存の試験記録を見ても分からなければ、接続の管理者に確かめます。拒否の試験が必要なら、管理者が許可した隔離環境と無害なテスト対象を使います。本番の更新・削除ツールを「拒否されるはず」と試すことは、この点検案には含めません。 また、技術的に操作する権限があっても、今回その変更をしてよいと本人が判断したことにはなりません。接続に更新権限が必要な場面でも、その都度の変更内容を誰が確認するかは別に決めます。 「読むだけ」を、確認できた範囲で言う 最初にすることは、接続を増やすことではありません。今使っている一つの接続で、表示を絞る設定と、実行時に権限を検証する設定を見つけることです。 たとえば「更新ツールは一覧に出ないが、呼出時に拒否する仕組みは未確認」と分かったなら、読み取り専用を確認済みにはしません。分かった点と未確認の点を分けて残せば、管理者へ確かめる箇所も絞れます。 この確認表の効果や、個々の接続の安全性を実機で検証したものではありません。AIへの指示、ツール一覧、実行時の権限を分けて見ることが、何を根拠に作業を任せているかを確かめる出発点になります。

MCP Java SDK: The official Java SDK for Model Context Protocol servers and clients (3.7k stars) What it does All text below is quoted directly from the project README. >This SDK enables Java applications to interact with AI models and tools through a standardized interface, supporting both synchronous and asynchronous communication patterns. Architecture and Design Decisions: - Pragmatic – makes developers productive quickly - Interoperable – aligns with widely used libraries and practices - Pluggable – allows alternatives where projects prefer different stacks - Grounded in team familiarity – we chose technologies the team can be productive with today, while remaining open to community contributions that broaden the SDK - JSON serialization – mapping between JSON and Java types - Programming model – supporting asynchronous processing, cancellation, and streaming while staying simple for blocking use cases - Observability – logging and enabling integration with metrics/tracing - Remote clients and servers – supporting both consuming MCP servers (client transport) and exposing MCP endpoints (server transport with authorization) >./mvnw clean install -DskipTests Repository modelcontextprotocol/java-sdk Repository stats |Metric|Value| |:-|:-| |Stars|3,735| |Forks|1,100| |Last release|v2.1.0 (2026-10-16)| |Languages|Java 100%| |Contributors|90| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude: 2, Copilot: 1| |AI co-authored commits|Claude: 2, Copilot: 1| Main contributor |Field|Value| |:-|:-| |Name|Christian Tzolov| |GitHub|@tzolov| |Commits to this repo|312 (top contributor)| |Bio|R&D Software Engineer, Spring team at Broadcom | Spring AI Lead | Apache Software Foundation Committer.| |Company / Location|Amsterdam, Netherlands| |X / Twitter|@christzolov| |Followers|812| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.