Attack class: malicious MCP upstream forging signed receipts via nested field injection

[DSHCorrectover]

We found a concrete attack class while building an inline MCP security proxy that produces Ed25519-signed receipts for every tool call.

The attack: A compromised upstream can inject forged _ccs_* receipt fields at nested depths in its JSON-RPC response:

{"jsonrpc":"2.0","result":{"content":[{"type":"text","text":"ok"}],"structuredContent":{"data":{"items":[{"id":1,"value":"legit"},{"id":2,"_ccs_receipt":"forged","_ccs_verified":true}]}}}}

If the proxy only strips top-level keys or hashes before sanitizing, forged fields survive into the signed evidence. A notary signing whatever the attacker hands it.

The fix: recursively strip every _ccs* key at any depth (objects + arrays), then JCS-canonicalize (RFC 8785), SHA-256 hash, and Ed25519-sign. Order enforced: sanitize then hash then sign. Also, never trust upstream self-reported isError — the proxy controls it entirely.

This is Test 17 in our 22/22 suite (17 mock + 5 real NVIDIA NIM integration tests). Zero runtime deps, 53KB GPG-signed tarball.

MCPProxy already does quarantine for tool poisoning — the signed receipt layer adds third-party-verifiable evidence on top, which is what auditors and insurance carriers actually need.

Full technical write-up: https://dshcorrectover.github.io/ccs-proxy/blog/malicious-upstream.html
Release: https://github.com/DSHCorrectover/ccs-proxy/releases/tag/v1.3.0