Is Your .cursor/mcp.json Exposed? The Obvious Check Lies (2026)

Run this against Vercel's own website right now:

$ curl -s -o /dev/null -w "%{http_code}\n" https://vercel.com/.cursor/mcp.json
200

Vercel is not leaking its Cursor config. That 200 is 2.5 MB of marketing HTML, served by a catch-all route that answers every unmatched path the same way. We checked it on 2026-08-26 and got the same result twice.

That's the problem with the advice going around. Scanners really did add AI assistant config paths to their wordlists, the check people reach for really is a one-line curl, and that one-line curl gives a false positive on a large share of the apps this audience ships.

What was actually observed

On 2026-07-13, SANS Internet Storm Center handler Manuel Humberto Santander Peláez published a diary built from 14 days of Apache and ModSecurity logs on one small web host. The host ran no AI infrastructure at all. In his words: "None of the AI-agent infrastructure the scanners were looking for existed on this host. That is the point."

The requested paths:

The genuinely interesting part isn't the path list, it's the method. The scanners send correctly formed JSON-RPC 2.0 handshakes with protocol version 2025-03-26, not blind GETs. The diary puts it plainly: "The scanner is not blindly requesting a URL. It is speaking the protocol." Credential files got HEAD requests rather than GET, which the author reads as checking existence before spending bandwidth, a sign of "a mature, wide campaign rather than a one-off curiosity probe."

Why your file is probably not reachable

Two independent things have to fail before a repo-root .cursor/mcp.json answers over HTTP. Most people only know about the first.

Layer one: only the output directory is served. Both major hosts document this in almost identical language.

Vercel, in Configuring a Build: "Only the contents of this Output Directory will be served statically by Vercel."

Netlify, in Build configuration overview: "Only files in the publish directory are deployed. Files and assets located outside of the publish directory won't be included in site deploys."

A file being in your git repository has nothing to do with whether it's on the web. What matters is which directory the host serves. With Next.js, Astro, Vite or Nuxt on a standard preset, that's a build output folder, and .cursor/ at the repo root isn't in it.

Layer two: dotfiles get special treatment. Next.js serves public/ through the send library without enabling its dotfiles option, so dotfiles return 404 (open discussion since December 2020). Netlify staff have confirmed on their forum that files and directories beginning with a period are stripped, saying "I do not believe we are planning any changes here."

Where it genuinely can be reachable

Vercel documents the first case itself. For projects with no build step: "Choose 'Other' as the Framework Preset. This sets the output directory as public if it exists or . (root directory of the project) otherwise."

Output directory equals repository root is exactly the shape where this stops being theoretical. The other shapes:

• vercel.json with "outputDirectory": "." set by hand
• An nginx or Apache root pointed straight at a git checkout
• A Dockerfile that does COPY . . and then serves its working directory
• python -m http.server in a project folder, or a Vite dev server left exposed (vite, not vite preview), both of which serve from the project root

There's a real sighting of the general failure on Vercel's own forum: a thread where README.md and requirements.txt were served as public static assets on an "Other" preset project, because filesystem precedence beat the catch-all rewrite. Those aren't dotfiles, which is consistent with the two layers above behaving independently.

The check that actually works

Status code alone is useless. Look at what came back.

curl -sS -L --max-time 20 -o /tmp/body -w 'status=%{http_code} type=%{content_type}\n' \
  https://YOURSITE.com/.cursor/mcp.json

head -c 400 /tmp/body

You are only exposed if all three are true:

Run it against the other paths too: /.claude/mcp.json, /.vscode/mcp.json, /.claude/.credentials.json, /.env, /.git/config. Same three tests each time.

One thing that's true for everyone

Whatever your hosting does, put these in .gitignore:

.cursor/
.claude/
.vscode/
.mcp/

This costs nothing and doesn't depend on a vendor's undocumented dotfile behaviour staying the way it is. If those directories are already committed, taking them out means no deployment shape you migrate to later can serve them.

The part that worries us more

Buried in the same diary is a finding that doesn't depend on an unusual deploy shape at all. If you wired an AI agent with a tool that fetches arbitrary URLs, you built an SSRF primitive. The diary's phrasing: "An MCP server or an agent tool that fetches arbitrary URLs is a ready-made SSRF primitive." The scanners rotate parameter names (url, uri, path, dest) and aim at cloud metadata endpoints.

That one is live for anyone whose agent can fetch a link, no misconfiguration required. If your app has a "summarise this URL" feature, it's the thing to look at first.

The author's summary of why an exposed MCP server is worse than a leaked config file, from the body of the diary: it is "a remote, machine-readable menu of everything an agent can touch, offered to anyone who completes the handshake."