Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#3,269 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
api, security

Direzione di ricerca

Inizia da src/mcp/shared/inbound.py, nel ramo classify_inbound_request intorno alla riga 447, poi leggi tests/shared/test_inbound.py, in particolare test_validate_mcp_param_headers_rejects_orphan_header_for_absent_or_null_argument e il test esistente per Mcp-Name. Conferma con i maintainer l’intento previsto; il lavoro è completato quando c’è un test di regressione con la validazione corrispondente oppure una docstring del test che spiega l’asimmetria intenzionale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

improves spec compliance P3 spec-2026-07-28 v2

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.

Lingua principale
Python
Stelle
24.3k
Fork
4k
Merge medio
1g 19m
PR unite (30g)
29

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/python-sdk

Tutte le issue di modelcontextprotocol/python-sdk

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.