modelcontextprotocol / modelcontextprotocol/python-sdk

Mcp-Name accepts an orphan header, while Mcp-Param-* rejects it as a routing spoof

Đang mở
#3,269 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

improves spec compliance P3 spec-2026-07-28 v2
Ngôn ngữ chính
Python
Star
24.3k
Fork
4k
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
31

Mô tả

What

validate_mcp_param_headers rejects an orphan Mcp-Param-* header, one present when the body argument is absent or null. classify_inbound_request accepts an orphan Mcp-Name header.

The Mcp-Param-* posture is deliberate and documented, in tests/shared/test_inbound.py:

"""SDK-defined posture on a spec gap: an orphan header is the routing-spoof case; go rejects too, ts skips."""

The Mcp-Name path has no equivalent branch. src/mcp/shared/inbound.py, line 447 on main:

body_value = cast("Mapping[str, Any]", body["params"]).get(name_key)
if body_value is not None and decode_header_value(headers.get(MCP_NAME_HEADER)) != body_value:

When body_value is None the whole check is skipped, including the case where a header claims a name.

Reproducer

from mcp.shared.inbound import (
    MCP_METHOD_HEADER, MCP_NAME_HEADER, MCP_PROTOCOL_VERSION_HEADER,
    InboundModernRoute, classify_inbound_request,
)

V = "2026-07-28"
body = {"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {
    "arguments": {},
    "_meta": {"io.modelcontextprotocol/protocolVersion": V,
              "io.modelcontextprotocol/clientCapabilities": {}}}}

result = classify_inbound_request(body, headers={
    MCP_PROTOCOL_VERSION_HEADER: V,
    MCP_METHOD_HEADER: "tools/call",
    MCP_NAME_HEADER: "ping",          # claims a tool the body never names
})
assert isinstance(result, InboundModernRoute)   # passes today

Same shape for resources/read with uri.

Why this looks like an inconsistency rather than a decision

The existing Mcp-Name test covers a different case:

def test_header_rung_does_not_require_name_header_when_body_omits_the_named_param() -> None:
    """SDK-defined: ... the param's absence is INVALID_PARAMS later, not HEADER_MISMATCH here."""

matching_headers omits Mcp-Name when the body lacks the param, so this pins "body omits the param and no header is sent". That rationale reads correctly for that case: nobody asserted a name, so the defect is the missing param and INVALID_PARAMS is the right answer.

It does not obviously extend to a client that did assert one. There the header and body disagree, which is the condition the routing-spoof posture exists for, and Mcp-Name is the header an intermediary is most likely to route on, since it names the tool or resource rather than a secondary parameter.

To be clear about impact: the malformed request fails INVALID_PARAMS downstream either way, so nothing executes. The concrete cost is an intermediary routing or rate-limiting on a name the body never contained.

Ask

Is the Mcp-Param-* posture intended to apply to Mcp-Name? If so the fix mirrors the sibling branch, rejecting when body_value is None and the header is present, with a test alongside test_validate_mcp_param_headers_rejects_orphan_header_for_absent_or_null_argument.

If the asymmetry is intentional, a note in that test's docstring saying so would prevent the next reader drawing the same conclusion I did.

Happy to open the PR either way once you say which you would prefer.


AI disclosure per AI_POLICY: I directed this investigation and reviewed the result. The research and drafting were done by Claude Code, which found this while probing SEP-2243 handling with adversarial tests, having implemented the same validation in a TypeScript resource server. 87 probes against encode_header_value and decode_header_value found no defects there, including non-canonical base64, invalid UTF-8 and sentinel-literal collisions, so this is the only finding. Verified against main rather than the released 2.0.0 wheel.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu tại src/mcp/shared/inbound.py, ở nhánh classify_inbound_request quanh dòng 447, sau đó đọc tests/shared/test_inbound.py, đặc biệt là test_validate_mcp_param_headers_rejects_orphan_header_for_absent_or_null_argument và bài test Mcp-Name hiện có. Xác nhận với các maintainer về chủ trương dự kiến; được xem là hoàn tất khi có либо một regression test cùng validation tương ứng, либо một test docstring giải thích sự bất đối xứng có chủ ý.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
python
Lĩnh vực
api, security
Loại issue
Lỗi
Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
42/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.