Repository navigation
Server exits on a malformed JSON-RPC frame (denial-of-service) #701
Description
Hello, and apologies for the unsolicited report.
Your MCP server io.github.stackql/stackql-mcp (@stackql/mcp-server) was included in an automated
conformance study of publicly registered Model Context Protocol servers. The study
installed and executed every eligible server in the official registry and drove it
through a set of protocol checks. One result looked worth reporting to you directly.
What we observed
Server crashes or stops responding after a malformed JSON-RPC frame (severity: HIGH)
A single syntactically invalid frame from a client ends the session. Any client that garbles one message -- or any peer that sends one deliberately -- can terminate the server. This is a denial-of-service primitive.
Observed during the check malformed-json:
unresponsive after malformed input (eof)
Reproducing it
The harness is open source. With Docker installed:
git clone https://github.com/Ahmad-Faraj/mcp-conformance
cd mcp-conformance
python driver/mcpprobe.py --cmd "docker run --rm -i --init --memory 768m --cpus 1 --pids-limit 256 --security-opt no-new-privileges --cap-drop ALL node:22-slim npx -y @stackql/mcp-server@0.10.542"The relevant verdict is malformed-json in the JSON output.
Suggested fix
Wrap frame parsing so a JSON decode error is answered with a JSON-RPC parse error (-32700) and the read loop continues, instead of propagating.
About the study
This is part of an academic measurement study of MCP server conformance. Your
server is not named in the paper or the public dataset -- results are reported only
in aggregate, and servers behind security-relevant findings are pseudonymised. We are
contacting maintainers before publication so that anyone who wants to fix an issue
can do so first. There is no deadline attached and no follow-up is required.
If this is a false positive, we would genuinely like to know: the harness may be
wrong, and we will correct both it and the dataset.
Repository: https://github.com/Ahmad-Faraj/mcp-conformance
Activity
jeffreyaven commentedon Jul 31, 2026
Thanks @Ahmad-Faraj for the report, and for the care taken in how it was disclosed.
We reproduced this independently against the released
stackql-mcp-linux-x64.mcpbbundles for the current release.The fix will land in the next release: malformed frames will be answered with a -32700 parse error (
id: null) and the session will continue, with a regression test added to CI covering malformed input before and after valid traffic. We'll update this issue when the release is out.Ahmad-Faraj commentedon Jul 31, 2026
Thanks for reproducing it and for the quick turnaround.
One correction I should pass on rather than let stand. I reported this as a denial-of-service primitive, and a maintainer on another affected project pointed out that under stdio the client is the parent process and the only writer to the server's stdin, so anyone able to send a malformed frame can already terminate the subprocess directly. That is right, and I am revising the framing in the paper to a stdio robustness and conformance issue rather than a security one. The
-32700and continue behaviour you describe is still the correct fix, but the severity I attached to it was too high and you should weigh it accordingly when prioritising.Happy to re-run the check against the release when it lands, if that is useful for your regression test.
fix: stdio malformed-frame resilience, JSON() param fan-out, window/C…