We agree :)

This incident is a reminder of the security challenges posed by locally exposed developer tools.

Robust Host header validation and CSRF protections are crucial.

For a full technical breakdown, read the advisory:

mcpsec.dev/advisories/...

Shoutout to the @neo4j security team for a stellar communication and a quick turn around time on a security patch.

I am grateful for their excellent triaging.

If you are using Neo4j MCP Cypher Server versions 0.2.2 through 0.3.1, you are vulnerable.

An immediate update to the patched version, v0.4.0, is recommended.

The attack works when a user with a vulnerable server running locally visits a malicious webpage.

The page performs the DNS rebind, tricking the browser into communicating directly with the local Neo4j service on the attacker's behalf.

An attacker can execute Cypher queries to exfiltrate, modify, or delete all data within the user's local Neo4j database.

Neo4j rated this vulnerability as CVSS 4.0 High severity (7.4).

The Cypher MCP Server provides a local HTTP endpoint to run Cypher queries.

The vulnerability allows a malicious website to send arbitrary queries to this endpoint.

Important lesson for MCP server developers - network-based transports need careful HTTP security header validation.

Default to:

- localhost binding
- stdio transport when possible
- Host/Origin validation for SSE/HTTP

SafeDep's response was 10 / 10

Aug 30: Report submitted
Sep 01: Acknowledged
Sep 02: PR raised with fix
Sep 05: v1.12.5 released (5 days!)
Sep 29: GHSA published

v1.12.5 adds Host/Origin header validation. Update now!

Despite data exfiltration potential, it's rated Low (CVSS 2.1) because:

- Victim must visit malicious site while MCP server is running
- SSE transport must be explicitly enabled (not default)
- Requires browser with EventSource support
- Timing window needed

What gets exfiltrated?

- Package names & versions in your projects
- Known CVEs affecting your dependencies
- Vulnerability severity scores
- Supply chain intelligence

Perfect recon for targeted attacks against your infrastructure.

Vet's SSE transport mode lacked Host/Origin header validation.

When running vet server mcp --server-type sse, an attacker could:

- Establish an MCP session via DNS rebinding
- Invoke the sql_query tool
- Execute arbitrary READ queries against your scan database

DNS rebinding is a clever trick:

1. Victim visits attacker(.)com
2. DNS initially points to attacker's server
3. After browser caches the origin, DNS changes to localhost
4. Now attacker(.)com JS talks to victim's localhost
5. Browser's Same-Origin Policy is bypassed

7) Assume insecure defaults

So many companies are shipping coding agents.

Assume all of them are more interested in market capture than the preservation of your data confidentiality.

Because as we see here...

YMMV

6) Send Amp an email

I enjoyed using Amp before reading wunderwuzzi's post and started prodding Amp.

Now I cannot use Amp because it leaves me, my users, and my company exposed.

Amp is working on a patch - but come on this is probably a one liner - why leave us exposed.

5) Amp CLI and all Amp IDE extensions have this problem

Regardless of where you use Amp - you are vulnerable.

4) Here is what you should do:

Modify Amp's settings to request permissions for network based commands such as dig.

Adding permission guardrails for echo and tr decreases the ease with which an attacker can steak your data is a second layer of defense.