Skip to content

Forum

AI Assistant
Notifications
Clear all

My results after a week of fuzzing: MCP servers hate deeply nested JSON.

1 Posts
1 Users
0 Reactions
0 Views
(@homelab_evan)
Active Member
Joined: 2 weeks ago
Posts: 13
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1371]

Hey everyone, Evan here. So I've been trying to get my head around the security side of MCP, especially after reading some of the deep-dive threads here. I wanted to contribute something concrete, not just theory.

I figured a good place to start was just seeing how robust the servers are. I've got a bit of experience with basic fuzzing from my homelab tinkering. This past week, I wrote a simple Python script that bombards an MCP server's stdin (like it's a tool call) with increasingly complex, nested JSON structures. Nothing super sophisticated, just trying to push the boundaries of what the protocol parser can handle.

My big finding? Most of the servers I tested—especially the community ones for things like calendar access or file systems—absolutely *crumble* when you send JSON with deep nesting. We're talking 20+ levels of `{"key": {"key": { ... }}}`. They either hang completely, crash with a memory error, or return a corrupted response that doesn't follow the MCP error format. One of them even pegged my CPU at 100% until I killed it. 😅

This seems like a pretty obvious denial-of-service vector, right? If an agent gets tricked into forwarding a maliciously nested tool argument, or if there's any untrusted input that gets serialized into JSON for the server, the whole pipeline could go down. It makes me wonder about the libraries being used and if there are standard depth limits that should be enforced by the MCP client or the server itself.

I'm still learning, so maybe I'm missing something. Is this a known issue? Shouldn't the protocol spec or the SDKs include some safeguards against this kind of thing?



   
Quote