Ghidra MCP setup and the port you just opened

When Hex-Rays announced its official IDA MCP server on 25 September 2026, it included a warning: because IDA "does not yet isolate its Python interpreter from the wider system," the agent "can evaluate scripts that reach beyond IDA's database." A Ghidra MCP server carries a quieter version of the same problem. Setup takes minutes; the endpoint it opens runs analysis code against deliberately hostile files.

This post covers both halves: how the Ghidra, IDA and Binary Ninja MCP servers are actually wired as of October 2026, what each one exposes, and why the honest answer at most companies is that this belongs in a disposable VM rather than on the laptop holding your source control credentials.

One disclosure first, because it changes how you should read the setup steps below. We have not run GhidraMCP, pyghidra-mcp, IDA MCP or the Binary Ninja MCP server. Everything procedural here is read from the projects' own READMEs, source and release notes, each linked on the claim. Where a vendor states a default we could not independently confirm, we say so rather than dressing it up as experience.

What Ghidra MCP is, and what it puts on your machine

Ghidra has no first-party MCP server. The one most people mean is LaurieWired's GhidraMCP, Apache-2.0 licensed, at release 2.0 published on 10 October 2026, with over 11,400 GitHub stars. It is two pieces, not one: a Java extension that runs an HTTP backend inside Ghidra, and a separate Python MCP server that your agent launches and that calls that backend over HTTP.

The split matters for the threat model, because it means something is listening. The extension's source binds InetAddress.getLoopbackAddress() and the plugin registers a default port of 8080. There is no authentication option anywhere in the server's command-line interface — no token, no shared secret. Anything that can reach 127.0.0.1:8080 on that machine can drive Ghidra.

The README's installation path, which we have not executed, is five steps:

1. Install Ghidra 12.1.4 and uv.
2. Download the release zip, then in Ghidra choose File → Install Extensions and add the ghidra_12.1.4_PUBLIC_<date>_GhidraMCP.zip file.
3. Restart Ghidra and enable GhidraMCPPlugin under File → Configure → Developer.
4. Optionally change the port under Edit → Tool Options → GhidraMCP HTTP Server.
5. Register the MCP server with your agent. For Claude Code the README gives claude mcp add ghidra -- uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/.

For clients that want a URL rather than a command, the README has you run the MCP server yourself with --transport streamable-http and point the client at http://127.0.0.1:8081/mcp. That is now two listening ports for one decompiler.

GhidraMCP can also run with no Ghidra GUI at all, importing and analysing a binary itself through PyGhidra. The README states this needs Python 3.10–3.13 and GHIDRA_INSTALL_DIR pointed at a Ghidra 12.1.4 install, and notes that on macOS you must first build Ghidra's decompiler natives with support/gradle/gradlew buildNatives. Headless is the mode worth caring about, because it is the one you can put inside a container.

pyghidra-mcp vs GhidraMCP: per-binary bridge or project-wide server

The second option is pyghidra-mcp, by clearbluejar, Apache-2.0, at version 0.2.7 on PyPI uploaded 25 September 2026 and declaring Python 3.10 or newer. Its own README frames the difference as headless-first and project-wide: it enables "concurrent reverse engineering of all binaries in a Ghidra project," where GhidraMCP's GUI mode bridges the program in front of you.

Its recommended transport is streamable HTTP, and the documented server address is http://127.0.0.1:8000/mcp. The tool surface is deliberately narrow but not read-only: alongside decompile_function, list_xrefs, gen_callgraph and a semantic search_code backed by ChromaDB vector embeddings, it exposes rename, set-type, set-prototype and set-comment mutations, plus project import and delete. A --gui flag launches Ghidra through pyghidra-mcp; the README is explicit that it "does not attach to an already-running external Ghidra instance." There is a published Docker image, which is the single most useful fact in that README for anyone thinking about containment. We found no authentication mechanism documented for that HTTP endpoint either.

Which decompilers have an official MCP server now

The reason to write this in October 2026 rather than six months ago is that two vendors moved in September. Reverse-engineering MCP stopped being a community plugin story.

Decompiler	MCP server status	What it exposes
Ghidra 12.1.4	Community only (GhidraMCP 2.0, pyghidra-mcp 0.2.7)	Decompile, xrefs, callgraph, rename and retype; HTTP on loopback, no auth documented
IDA 9.4+	Official, Hex-Rays, 25 Sep 2026, free and open source	Database open/close/list/save, API-doc search, and arbitrary IDAPython evaluation
Binary Ninja 6.0	Official, first-party, 3 Sep 2026	GUI server over HTTP in all editions including Free; headless stdio binary on Commercial and Ultimate

Binary Ninja 6.0, codenamed Krypton, shipped two variants. The GUI MCP server runs inside Binary Ninja, communicates over HTTP and is included in every edition including Free. The headless variant is a standalone binaryninja_mcp binary speaking stdio, included with Commercial and Ultimate on macOS and Linux only; the release notes say native Windows packages do not ship it yet, because a running MCP server can corrupt or block an installation under Windows file system locking. You enable the GUI server by setting ui.mcp.enabled and restarting, or via Plugins > MCP > Start Server. With default settings it listens at http://127.0.0.1:24642/mcp, and setting ui.mcp.token requires clients to send a matching bearer token. Read that sentence the other way round: the token is opt-in, so the default is an unauthenticated local endpoint.

Hex-Rays took the opposite design decision on tool surface. Its IDA MCP server is MIT-licensed and offers four groups of tools: database open, close, list and save; API documentation and example search; and IDAPython, described as "read/write/update the database and evaluate logic using Python." Instead of a hundred narrow tools it hands the model an interpreter — the "code mode" pattern — and Hex-Rays reports roughly 20% lower token consumption than popular alternatives on an internal malware-analysis benchmark. The README states a requirement of IDA 9.4 or higher with idalib and Python 3.11 or newer, and the announcement says it works with IDA Pro, Home, Classroom and OEM. Installation is uvx ida-hcli mcp install.

The community server that got there first has conceded the ground. mrexodia's ida-pro-mcp README now opens by recommending the official Hex-Rays server instead, and separately says its in-IDA MCP plugin "is no longer recommended and will eventually be deprecated," pointing users at idalib-mcp, which defaults to 127.0.0.1 on port 8745. If you standardised a team on the community plugin earlier this year, that is a migration you now own.

An endpoint that runs code against files chosen by an attacker

Here is the part the listicles skip. A decompiler MCP server is not a read-only data source. In the Ghidra servers it can rename symbols, set types and delete programs from a project. In IDA MCP it evaluates Python you did not write, generated by a model, in a process that Hex-Rays itself says is not isolated from the wider system. The input is a binary that somebody built specifically to resist and mislead analysis.

Two distinct risks stack here, and they are worth separating before you argue about either. The first is the endpoint: an unauthenticated HTTP listener on a developer workstation, reachable by any local process and by anything that can trick a browser into issuing requests to it. The second is prompt injection through the sample. Strings, comments, resource sections and decompiled pseudo-C all become model context, and a model that will run IDAPython on request is a model that can be asked to run IDAPython by the thing it is reading. The protocol's own direction of travel assumes hostile input is normal — our note on the MCP specification breaking changes covers how much of that surface moved in a single revision.

Hex-Rays gives the correct mitigation plainly: "we recommend running the harness and IDA MCP in a sandboxed environment when dealing with untrusted data," and elsewhere, "we recommend using a VM or other sandboxed environment." That is the vendor's own guidance, not ours, and it applies equally to the Ghidra servers, which ship no such warning.

Binding to localhost is not isolation, and a token is not a sandbox

Loopback binding stops a machine on the same network from connecting. It does nothing about other processes on the host, including the agent harness itself, every VS Code extension, and anything a malicious sample manages to execute. Treat 127.0.0.1 as a convenience, not a boundary.

A bearer token, as Binary Ninja offers through ui.mcp.token, is still worth setting. It stops casual cross-origin and drive-by requests from a browser tab reaching the endpoint. It does not constrain what the authorised agent can do once connected, and it is not available at all on either Ghidra server as far as their documentation goes. The pattern is familiar from any MCP deployment where the transport, not the tool, is doing the access control — we wrote about the shape of that problem in stateless MCP and sticky sessions, and about local tooling endpoints in Safari MCP for web developers.

If you are doing this at work, the controls that actually change the risk are boring: a disposable VM or container with no network egress beyond the model API, no SSH keys, no cloud credentials, no password manager, no mounted source tree, and a snapshot you roll back after each sample. Headless mode and the published pyghidra-mcp Docker image exist precisely so you can do that. The procurement question to put in writing is simple: whose machine runs this, what credentials live on it, and who approved sending decompiled customer or vendor code to a model endpoint.

When you should not do this

Do not wire a decompiler to an agent if you cannot give it a throwaway machine. A workstation with production credentials on it is the wrong host, and "I will be careful with which samples I open" is not a control.

Do not do it if the binaries are not yours to analyse. This tooling is for malware triage, firmware you own, your own release artefacts and third-party code you are contractually or legally permitted to examine. That constraint is not a formality; it is the first question any incident review will ask.

Do not do it if your organisation has not settled where decompiled code may be sent. Hex-Rays' own framing is that IDA MCP "communicates with external AI systems, their use may not be compatible with every organization's security or air-gapped deployment policies," which is why installation is opt-in. If your answer to "can this binary's contents leave the building" is unknown, resolve that before the setup, not after.

And do not expect it to replace the analyst. The published demonstration is a crafted challenge with a known answer, not an unknown sample under time pressure. The honest claim for these servers is that they compress the mechanical parts of triage, which is valuable and is also a smaller claim than the launch posts make.

What we would decide first

Our own work here is agent plumbing rather than malware analysis — the same questions about tool surface, credentials and blast radius come up in every AI engineering engagement where an agent gets a tool that can write somewhere. The decision that comes before any of the setup steps above is which machine you are willing to lose. Pick that first, build it disposable, and the choice between the Ghidra, IDA and Binary Ninja servers becomes a question about tool surface instead of a question about exposure.