BoundBench

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

Minimal

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.

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

Minimal 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

Minimal 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

Minimal 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

Minimal 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

Minimal 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

Moderate 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

Minimal 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

Minimal 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

Minimal 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.