SafetyCard Request a review

Burp Suite MCP Server

Burp Suite extension exposing Burp to AI clients via MCP

github.com/PortSwigger/mcp-server · 2026-10-03 · 642e6fa

Defense-in-depth score

3.8 / 10

The server has no client authentication of its own and relies on loopback binding, Host/Origin checks and two Swing approval dialogs. Sending HTTP requests and reading proxy history, WebSocket history and Organizer items require a per-call human decision by default, and the dialog shows the exact request. Several other state-changing tools (intercept toggle, task engine state, editor contents, Repeater and Intruder tabs) are ungated, outputs carry no provenance, and there are no timeouts or rate limits. Controls are meaningful for a local single-user tool but thin on validation, logging and limits.

Safest setup

Burp MCP Server listens only on this machine by default, asks before it sends an HTTP request or reads project history, keeps its code-capable config tools off and filters credentials from config exports. It has no client authentication, several tools that change Burp's state run without a prompt, and nothing limits request volume, so the safest setup keeps those defaults on and adds containment around Burp yourself.

SetupHowWhat it gives you
A single-user machine or VMRun the MCP-connected Burp on a machine or VM where you are the only user and no untrusted local software runsThe endpoint, which has no client authentication of its own, is reachable only by software you chose to run C1
A dedicated Burp projectUse a Burp project that holds only the current engagement's trafficHistory the model can read carries only that engagement's data and session material C8
Loopback bindingKeep the default host 127.0.0.1The MCP endpoint is reachable only from this machine C1
HTTP request approvalKeep Require approval for HTTP requests tickedA person sees the target and the exact request before anything is sent C2
Project data approvalKeep Require approval for project data access ticked, with the Always allow boxes under it clearEach read of proxy, WebSocket or Organizer history waits for your decision C2
Config-editing tools offKeep Enable tools that can edit your config untickedThe one tool path that can execute code or change Burp settings stays unavailable C4
Credential filteringKeep Filter config credentials tickedPasswords and keys stay masked in config exports C8
Egress to in-scope hostsLimit the outbound network of Burp's machine or VM to the hosts in scope for the engagementRequests the model sends land only on systems you are testing C3

Approving with confidence

  • Read each prompt and approve requests one at a time; an Always Allow choice persists for that target with no expiry.
  • Intercept, task-engine, editor and Repeater or Intruder tools run without a prompt, so check Burp's state after a session.

Handling data

  • History the model reads is returned unredacted, session tokens included; treat the model client's transcripts like the proxy history.
  • Burp's extension output records HTTP sends, approval decisions and history access as free text; intercept, task-engine, editor and tab tools leave no record.

Key gaps (1)

  1. The MCP HTTP endpoint has no authentication or per-client identity; any local process that passes the Host/Origin/User-Agent checks can invoke every tool. C1 · Identity & least privilege

Criteria

C1 Identity & least privilege

0.30 / 1.00

The extension runs inside Burp and holds no credentials of its own, but its MCP endpoint has no authentication or per-client identity. Protection is loopback binding by default plus Host, Origin, Referer and User-Agent filtering aimed at DNS rebinding and browsers. Authority is that of the whole Burp instance, narrowed only by approval prompts for HTTP sends and history reads; most other tools are ungated. Failure of those prompts exposes Burp's traffic data and its ability to send requests as the user.

C2 Approval gates

0.45 / 1.00

As a tool server it enforces approval itself: sending an HTTP request opens a Swing dialog showing the target and the exact request, and proxy, WebSocket and Organizer reads each need approval, both on by default. There are separate read and write tools but no readOnlyHint or destructiveHint annotations. Intercept toggling, task-engine state, editor writes and Repeater/Intruder tab creation never pass a gate, and the approvals offer persistent allow rules and can be switched off with a checkbox without a warning. HTTP sends are irreversible and have no rate limit.

C3 Tool & action scoping

0.17 / 1.00

Tools are typed Kotlin data classes decoded from JSON, so malformed shapes are rejected, but no tool argument is checked against an allowlist or bound. Hostnames and ports for HTTP sends are arbitrary (including internal addresses; approval is the only barrier), regexes are compiled directly, pagination counts have no ceiling, and configuration import takes arbitrary JSON when enabled. All tools are registered by default except config editing, which is runtime-disabled.

C4 Code-execution isolation

0.10 / 1.00

The extension has no shell, script or process-execution path of its own. The one route to code execution is the configuration-import pair, whose own UI label says it can execute code; it is off by default and refuses unless the operator ticks the box. No isolation primitive contains it when enabled, and the process holds the full Burp and OS-user authority. Because the default configuration has no execution path, the low score reflects absence of any sandbox on that opt-in path rather than a default-on hazard.

C5 Untrusted input blast radius

0.17 / 1.00

Everything the model reads from Burp (proxied responses, history, scanner issues, Collaborator interactions) is attacker-influenced, and it is returned as plain text or JSON without an untrusted marker or source labelling. Tool descriptions contain usage guidance but no injected directives. The server offers no read-only or no-egress mode, so the structural limit on a hijack is the approval prompts: sending to a new host and reading history need a human, while intercept, task-engine and editor changes do not. Once a host is set to always-allow, requests to it are unattended.

C6 Memory, context & configuration integrity

0.57 / 1.00

The server keeps no memory, retrieval store or conversation state and loads no instruction or workspace files. Its persisted state is the extension settings and an auto-approve target list in Burp extension data, which the model cannot write except through a human clicking Always Allow in a dialog. Configuration import tools, when enabled, can change Burp settings. Entries do not expire and the approval toggles share the same store.

C7 Third-party extensions

N/A · full credit 1.00 / 1.00

The server loads no third-party code at runtime: no plugin loader, remote tool fetching or model loading. It embeds a vendored proxy jar that Burp users install into their MCP client configuration; the jar is extracted from the extension's own resources and refreshed when its SHA-256 differs. That jar and the build dependencies are build supply-chain items, which are out of scope for this criterion.

C8 Secrets & sensitive-data protection

0.35 / 1.00

The extension stores no credentials and has no telemetry. Its one redaction control masks a short list of key names (password, certificate_password, hashed_key) in the two config-export tools, is on by default and fails closed on parse errors, but can be switched off with a checkbox. Proxy history, which can hold session material, is returned unredacted after approval, and the config-import logs write the full JSON to Burp's output. Nothing here is routinely sent to the model without a prompt in the default flow.

C9 Audit & traceability

0.30 / 1.00

Actions are recorded as free-text lines in Burp's own output log: HTTP sends (host and port only), approval denials, history-access grants and denials, Collaborator calls and config imports. Intercept, task-engine, editor and Repeater/Intruder tool calls leave no record, entries carry no request method, path, outcome or actor, and the server defines no structured or tamper-evident log. Actions proceed regardless of logging success.

C10 Limits & kill switch

0.33 / 1.00

The server's own bounds are thin. Each history item is truncated to 5,000 characters, and the pagination helper slices results, but the page size is chosen by the caller. There are no per-request timeouts, rate or concurrency limits in the extension's code, and no ceiling on HTTP requests once a target is approved. The operator can disable the server from the Burp UI, which calls a stop with a grace period.