Validating Vulnerabilities with MCP SQLMap

Background

Recently, I wanted to integrate AI into my work to help operate vulnerability detection. I had previously written an mcp-request tool that uses the MCP protocol to let AI send requests and validate vulnerabilities, but it could only handle simple vulnerability scenarios.

For complex scenarios such as SQL injection, mcp-request can technically do the job, but it has some obvious problems:

Limitations of the Existing Approach

1. Heavy dependence on AI intelligence: The AI must be smart enough to know how to construct injection payloads. It becomes helpless when faced with complex scenarios such as blind injection
2. Extremely inefficient: The AI takes a long time to think before sending each request, making it very slow and completely unsuitable for batch detection
3. Huge context consumption: Complex injection tests generate a large amount of context, wasting tokens and affecting performance

Solution: Bring in the Heavy Artillery—SQLMap

After some thought, the simplest and most effective approach was to integrate SQLMap—the most mature SQL injection detection tool in the industry.

I wrote a small demo for testing: https://github.com/godzeo/mcp-sqlmap

Core advantages

1. Extremely high detection accuracy: If SQLMap produces results, you can be almost 100% certain that an injection vulnerability exists
2. Fast execution: Compared with having AI reason through payloads one by one, SQLMap’s rapid traversal mechanism is far more efficient—not every scenario is suitable for AI
3. Comprehensive functionality: It can not only detect vulnerabilities but also perform in-depth exploitation, such as enumerating database and table names

Technical implementation approach

1. Architecture design

Initially, I considered real-time communication over HTTP streaming, but actual testing showed that SQLMap takes a long time to run and frequently encounters timeout issues.

I had previously used SQLMap’s API mode for batch scanning, mainly to process GET requests, and that scenario was indeed relatively simple.

1. Core challenge

However, in real-world work scenarios, there is one key requirement: full support for both POST and GET requests.

Scans in corporate environments usually carry complex authentication headers:

• JWT tokens
• Session cookies
• Custom authentication headers
• CSRF tokens, etc.

When reproducing and validating vulnerabilities, this authentication information is essential.

Final solution: the -r parameter

After multiple experiments, the most stable and reliable method was to use SQLMap’s -r parameter to read a complete HTTP request file:

sqlmap -r request.txt –batch –flush-session

Advantages of this approach:

• Fully preserves all HTTP request header information
• Supports POST request bodies
• Is compatible with complex authentication mechanisms
• Prevents information loss during URL parsing

1. Key technical details

HTTP request formatting challenges

The greatest technical challenge was instructing the AI in the prompt to format HTTP requests correctly. Debugging this took a great deal of time because:

• Difficult format description: It is hard to describe the standard HTTP request format accurately in a prompt
• Header completeness: Critical headers such as Host must be included

The final solution was to describe the formatting requirements in detail within the MCP tool description:

@mcp.tool()
def submit_scan(
http_request: str = Field(description="""HTTP 请求报文原文。格式要求:
• 使用 \\n 表示换行符 (JSON转义格式)
• 必须包含完整的HTTP请求头，特别是Host头
• GET请求以 \\n\\n 结束
• POST请求在头部后用 \\n\\n 分隔，然后跟请求体
...
""")

1. Asynchronous task processing

To prevent timeouts caused by SQLMap’s long execution time, I implemented a complete asynchronous task-processing mechanism:

1. Result parsing

Input (the user’s prompt in Claude Code): Use the existing SQL injection MCP tool to help me check whether this HTTP traffic is vulnerable to injection:

GET /Less-1/?id=1 HTTP/1.1 Host: 127.0.0.1:8888 Accept-Encoding: gzip, deflate, br Accept: / User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Cache-Control: max-age=0

Future Optimization Directions

This is currently just a small demo. As more issues arise, there will still be many areas that need improvement.

Short-term optimizations

1. Add support for specifying more parameters

• Optimize SQLMap parameters such as level, risk, dbms, and technique
• Support detection of more injection types

2. Task management still needs improvement. Some scans currently take too long, and if the AI is not intelligent enough, default conversation timeouts can also cause failures. I still need to think further about how to orchestrate these tasks