If you've ever tried to connect Burp Suite MCP from WSL to Windows and got slapped with mysterious 403 Forbidden errors, this one's for you. Grab your coffee. I'm about to save you hours of frustration.

It Started With a Simple Goal

I run my development environment on WSL2, but Burp Suite Professional lives on my Windows host. When I discovered Burp Suite's MCP (Model Context Protocol) integration for AI-assisted security testing, I was hyped.

The setup looked straightforward. I had this working config for Windows:

{
    "burp": {
        "command": "java.exe",
        "args": [
            "-jar",
            "C:\\Users\\You\\AppData\\Roaming\\BurpSuite\\mcp-proxy\\mcp-proxy-all.jar",
            "--sse-url",
            "http://127.0.0.1:9876"
        ]
    }
}

"Easy," I thought. "Just change the IP to my Windows host and run it from WSL." I was so wrong.

The Error That Haunted Me

Failed to connect to SSE server at http://192.168.0.101:9876: 
Expected status code 200 but was 403

#403 Forbidden. From my own machine. To my own Burp Suite.
What?

The Rabbit Hole Begins

Attempt #1: Finding the Right IP

# The WSL adapter IP
ping 172.21.96.1  # 100% packet loss
# The resolv.conf nameserver
cat /etc/resolv.conf | grep nameserver
ping 10.255.255.254  # Works! But still 403...
# My Ethernet IP
curl http://192.168.0.101:9876  # 403 Forbidden

Attempt #2: Windows Firewall

"Must be the firewall," I told myself.

New-NetFirewallRule -DisplayName "Burp Suite REST API from WSL" -Direction Inbound -LocalPort 9876 -Protocol TCP -Action Allow

Rule created. but Still 403.

The "Aha!" Moment

After an hour of frustration, I decided to compare the responses:

From Windows (localhost):

curl http://127.0.0.1:9876
# HTTP/1.1 404 Not Found ← Expected, no root endpoint

From WSL (external IP):

curl http://192.168.0.101:9876
# HTTP/1.1 403 Forbidden ← REJECTED

Then it hit me: Burp Suite's REST API only accepts localhost connections. It's a security feature and it's working exactly as intended. The 403 wasn't a bug. It was Burp telling me: "Nice try, but I don't trust you."

The Solution (It's Embarrassingly Simple)

Instead of fighting Burp's security model, I worked with it. The trick? Run Windows Java from WSL using the cmd.exe wrapper

{
    "burp2": {
        "command": "cmd.exe",
        "args": [
            "/c",
            "D:\\path\\to\\burpsuitepro\\jre\\bin\\java.exe",
            "-jar",
            "C:\\Users\\You\\AppData\\Roaming\\BurpSuite\\mcp-proxy\\mcp-proxy-all.jar",
            "--sse-url",
            "http://127.0.0.1:9876"
        ]
    }
}

Why this works:

1. cmd.exe runs in Windows context, not WSL
2. Java executes as a Windows process
3. The connection to 127.0.0.1:9876 originates from Windows localhost
4. Burp Suite sees it as a legitimate local connection

That's it. No firewall changes. No Burp reconfiguration. Just tell WSL to delegate to Windows.

Lessons Learned

1. 403 doesn't always mean "permission denied": sometimes it means "wrong network context."
2. WSL interop is powerful: you can run Windows executables directly from Linux
3. Don't fight security features: work with them
4. When networking fails, check the source IP, not just the destination

TL;DR

Burp Suite MCP only accepts localhost connections. When running from WSL, use cmd.exe as a wrapper to execute the Java process in Windows context. Problem solved.

Tags: #BurpSuite #WSL #SecurityResearch #Pentesting #Debugging #Windows #Linux