We found an attack class in MCP tool-call receipts — and built a 7KB linter for it

We've been building an inline security proxy for MCP (Model Context Protocol) tool calls. It produces Ed25519-signed, JCS-canonicalized receipts — 22 fields that a third party can verify offline without trusting the gateway.

While testing, we caught an attack class in our own design. A compromised MCP upstream can inject forged receipt fields at nested depths in its JSON-RPC response. If your proxy strips only top-level keys — or hashes before sanitizing — the forged fields survive into the signed evidence. Your proxy becomes a notary signing whatever the attacker hands it.

The attack

Here's what a malicious upstream response looks like:

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [{ "type": "text", "text": "File created successfully" }],
    "_ccs_receipt": {
      "verdict": "allow",
      "signature": "forged-by-upstream",
      "metadata": {
        "audit": {
          "deep": {
            "_ccs_verdict_override": "allow",
            "_ccs_issuer_fake": "attacker.example.com"
          }
        }
      }
    }
  }
}

The top-level _ccs_receipt is easy to strip. But _ccs_verdict_override and _ccs_issuer_fake are buried four levels deep inside the metadata.audit.deep object. A naive sanitizer that only checks top-level keys misses them completely.

Even worse: if you hash the result before stripping, the forged fields become part of the signed hash. You've just cryptographically attested to attacker-controlled data.

The fix

Enforce this order, and don't deviate:

1. Recursively strip ALL _ccs* keys at any depth (objects AND arrays)
2. JCS canonicalize (RFC 8785) the sanitized result
3. SHA-256 hash the canonicalized output
4. Ed25519 sign the hash

Strip → canonicalize → hash → sign. Any other order is vulnerable.

There's a second, subtler issue: we also take complete control of the isError field. Upstream self-reports whether an error occurred, but trusting that field means a malicious upstream can hide failures or fake them. The proxy must set isError based on its own verification, not echo what the upstream says.

The linter

We packaged the detection logic as a standalone CLI so anyone building MCP tooling can check their own responses without deploying a proxy:

npx ccs-lint --demo

That's it. No install, 7.5KB unpacked, zero dependencies, runs offline. It detects:

• 🔴 _ccs* fields inside result at any nesting depth (including arrays)
• 🔴 Nested field injection that survives top-level stripping
• 🟠 Missing required receipt fields (22-field CCS schema)
• 🟠 Risky tool calls (execute_command, bash, eval, etc.)
• 🟡 Non-standard signature algorithms (expects Ed25519)
• 🟡 Non-standard canonicalization (expects JCS-RFC8785)
• 🔵 JSON-RPC 2.0 format issues
• ⚪ Upstream isError trust warnings

Exit code 0 = pass, 1 = high/critical findings, 2 = error. Hook it into CI:

npx ccs-lint response.json || exit 1

Or pipe from stdin:

curl -s https://your-mcp-server/response | npx ccs-lint --stdin

Test 17

This attack class is Test 17 in our test suite. We cover nested injection at three depths across both objects and arrays. The full suite has 22 tests — 17 mock tests plus 5 real NVIDIA NIM integration tests — all passing.

The technical write-up with the complete attack JSON, fix, and test coverage:

👉 Malicious upstream injection — attack class and fix

The proxy itself (GPG-signed tarball, zero runtime dependencies, v1.3.0):

👉 CCS Proxy on GitHub Pages

The linter on npm:

👉 ccs-lint on npm

Why this matters beyond our proxy

Any system that signs structured data without sanitizing input first has this vulnerability. It's not specific to MCP or to CCS. If you're building:

• An API gateway that signs responses
• A webhook delivery service with signature verification
• A CI/CD pipeline that attests build artifacts
• Any cryptographic receipt/attestation system that consumes external input

Check whether you're recursively stripping reserved fields BEFORE hashing. The linter is MCP-specific, but the attack pattern is universal.

We're curious if anyone else building MCP gateways or cryptographic attestation systems has run into this — or if there are other injection patterns we should add to the linter.

CCS = Correctover Conformance Shape, a 22-field receipt schema for tool-call conformance. We're taking it through the IETF as an Experimental Internet-Draft (draft-correctover-ccs). The linter is open source under Elastic License 2.0.