MCP JSON-RPC Message Carries Case-Duplicate name/arguments Keys to Smuggle an Unauthorized Tool Call
Attackers can send a tool-call request with two versions of the same field name that differ only in capitalization, like 'name' and 'Name'. A security gateway checks one version while the backend actually acts on the other, letting a malicious tool call slip through unchecked.
How the attack works
An attacker crafts a JSON-RPC 'tools/call' message and adds two copies of a key that should only appear once, such as both 'name' and 'Name', or 'arguments' and 'Arguments', inside the same params object. The gateway's authorization layer inspects the canonical-case key (e.g. 'name') and approves it as a safe tool. A downstream component, such as a case-insensitive JSON decoder common in some SDKs (Go is called out specifically), resolves the differently-cased key instead and executes that tool call. The result is that the backend runs a tool the security layer never actually vetted. This exact pattern was documented in Envoy AI Gateway (GHSA-4gph-2hhr-5mwg) but the underlying flaw is generic to any MCP proxy or client with case-insensitive parsing.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 00c8ae69-3b23-4664-9625-a01e0d1e420c
- Severity
- High
Why it matters
An attacker can bypass tool-level access controls in an MCP gateway and invoke tools that were never authorized, potentially reaching sensitive backend functionality the security layer was specifically meant to block.
What you can do
- →Ensure any MCP gateway, proxy, or SDK you operate performs strictly case-sensitive JSON key matching, per the JSON-RPC 2.0 spec, and reject messages with duplicate case-variant keys in params.
- →Audit your MCP stack (gateway, client library, backend server) to confirm all components resolve the same key when multiple case variants are present — the check and the execution must agree.
- →Log and alert on incoming tool-call messages containing duplicate case-variant keys (name/Name, arguments/Arguments) in the same params object, since legitimate clients have no reason to send both.
- →If using Envoy AI Gateway, review GHSA-4gph-2hhr-5mwg and apply the vendor's guidance or patches.
Known benign look-alikes
- Security research documentation, RFC/spec excerpts (e.g. the JSON-RPC case-sensitivity spec text itself), or vulnerability write-ups that quote the example PoC JSON verbatim for explanatory purposes rather than an actual live tool-call message
- A tool-call arguments payload containing both a slug-style `name` and a display-style `Name` field for a data record being created/updated (e.g. a CRM contact, a form submission) -- this is nested one level inside the params object's `arguments` value, not a duplicate of the params-level tool-identity `name` field itself, and the params-anchored regex does not match it
- ATR test fixtures containing this pattern as a labeled attack sample
- A non-MCP JSON payload that happens to define both a `name` and unrelated `Name` field for legitimate display-vs-slug purposes -- mitigated by requiring the jsonrpc/tools-call envelope context, which ordinary data records do not carry