MCP server fuzzing pipeline: AFL++, libFuzzer, and continuous corpus-based testing

What to fuzz in an MCP server

MCP servers have several distinct fuzzing surfaces:

• Tool argument parsing. The JSON-to-typed-argument parsing layer is the most impactful fuzzing target. Every tool call from an LLM passes through this code. Fuzzing finds: crashes on malformed JSON, type confusion on numeric types (integer overflow when a number argument is unexpectedly large), null dereferences on unexpected null values, and buffer issues in C/C++ MCP bindings.
• Input validation logic. After parsing, tool handlers validate argument values against domain constraints — URL format, file path validity, SQL query structure, regular expression patterns. Fuzzing with grammar-based mutators that produce near-valid inputs finds validation logic that accepts inputs it should reject (SSRF-enabling URLs, path traversal sequences, SQL injection fragments).
• Deserialization. MCP servers that cache responses, deserialize stored state, or parse upstream API responses have secondary deserialization surfaces. YAML, TOML, and binary serialization formats are particularly worth fuzzing for deserialization gadget chains.
• Authentication token parsing. JWT parsing, session token formats, and API key validation are high-value fuzzing targets because vulnerabilities here are authentication bypasses rather than just crashes.

AFL++ for native MCP bindings

AFL++ (American Fuzzy Lop Plus Plus) is the most widely deployed coverage-guided fuzzer. It instruments the target binary with coverage feedback hooks and mutates a seed corpus to maximize code coverage. For MCP servers with native components (C/C++ parsing libraries, Rust MCP server implementations, or native Node.js add-ons), AFL++ with its --instrument-all-callers and ASAN/UBSAN sanitizers finds memory safety bugs that are invisible to higher-level testing.

A minimal AFL++ harness for an MCP server's argument parser reads a tool call JSON from stdin and passes it through the parsing and validation pipeline with sanitizers enabled. The harness should exercise the full parsing-to-handler-entry code path, stopping before any actual API calls (mock the upstream client). This gives AFL++ complete visibility into the code that processes untrusted input.

Schema-driven corpus generation for JSON inputs

AFL++'s mutation-based approach works best when the seed corpus contains valid examples that cover all code paths. For MCP servers with JSON tool argument schemas (Zod, JSON Schema, Pydantic), the schema itself is a corpus generator: enumerate valid edge cases (empty arrays, maximum-length strings, nested object depth limits, unicode edge cases, numeric extremes) and generate a seed corpus from the Cartesian product of these edge values. This gives AFL++ a warm start with semantically meaningful inputs rather than random bytes.

For richer grammar-based fuzzing, boofuzz (Python) and radamsa support schema-driven mutation. For JavaScript/TypeScript MCP servers, jest-fuzz and custom fast-check fuzz integrations can be driven from Zod schemas.

CI integration and crash triage

Effective fuzzing pipelines run continuously, not as one-off manual exercises. The recommended CI model for MCP servers:

1. Fuzz harness code lives alongside unit tests in the repository.
2. A lightweight fuzzing job runs in CI on every PR — 5 minutes of AFL++ with the seed corpus, flagging any crashes or sanitizer reports.
3. A longer nightly or weekly job runs full corpus-growing fuzzing (24+ hours) and submits new crashing inputs to the corpus.
4. Crashes are deduplicated by stack hash and filed as security issues, not regular bugs — they get priority triage and a 90-day fix deadline.
5. The growing corpus is committed to the repository (or a separate corpus repo) so coverage accumulates across sessions.

Google's OSS-Fuzz and ClusterFuzz are free for open-source MCP server projects and provide continuous fuzzing infrastructure with automated crash reporting. For proprietary MCP servers, AWS Code Guru Security includes fuzzing capabilities, and CI providers (GitHub Actions, GitLab CI) can run AFL++ in standard containers.

Common fuzz-discovered bug classes in MCP servers

Based on our analysis of the MCP server ecosystem, the most common categories of bugs that fuzzing is well-positioned to find include: integer size assumptions in argument count validation (fuzzing with arrays of 1M elements), path traversal validation gaps (fuzzing URL and path arguments with ../ sequences, null bytes, URL encoding), regex catastrophic backtracking in validation patterns (fuzzing string arguments with crafted ReDoS payloads), and parser crashes in YAML or TOML configuration loading (fuzzing config file inputs).

SkillAudit's static analysis flags the structural patterns that indicate these bug classes are possible — missing size checks, unanchored regex patterns, dangerous string interpolation — but static analysis cannot confirm exploitability. Fuzzing confirms it.

← Property-based fuzzing post  ·  Behavioral anomaly detection for MCP servers →