Requests send a bare "node" User-Agent, making this traffic impossible for firewalls/security plugins to identify

[alisadiq90]

Summary

The client never sets an explicit User-Agent header when calling the WordPress REST API. I ran the published package against a local test listener to see what actually goes out on the wire, and the request arrives with:

user-agent: node

That's Node's own built-in fetch (undici) default when nothing overrides it, not something specific to this package. It carries no identifying information at all, and "node" is common enough that it's effectively indistinguishable from a huge range of unrelated scripts and tools.

Why this matters

I've run into WordPress security/firewall plugins blocking this traffic because their bot-protection systems classify requests partly by User-Agent, and a bare node string looks indistinguishable from bot/scraper traffic. Since MCP clients run on the end user's own machine with no fixed IP, User-Agent is really the only practical signal a security plugin has to work with here, and right now it doesn't carry one.

This would affect any WordPress security plugin that does UA-based classification, and any project built on this bridge, not just a single use case.

Where this happens

src/lib/wordpress-api.ts, in the headers object construction (around lines 391-396):

const headers: Record<string, string> = {
  'Content-Type': 'application/json',
  Accept: 'application/json, text/event-stream',
  'MCP-Protocol-Version': '2025-06-18',
  ...customHeaders,
};

No User-Agent key is set here, which matches what actually goes out on the wire: Node's built-in fetch default.

Suggested fix

Add an explicit, version-stamped User-Agent at the same spot, something like:

const headers: Record<string, string> = {
  'Content-Type': 'application/json',
  Accept: 'application/json, text/event-stream',
  'MCP-Protocol-Version': '2025-06-18',
  'User-Agent': `mcp-wordpress-remote/${VERSION}`,
  ...customHeaders,
};

(keeping it before ...customHeaders so a caller can still override it via CUSTOM_HEADERS if they need to)

This is a small change but it's the difference between security plugins being able to build a real allowlist rule for this traffic versus not being able to identify it at all. Happy to open a PR for this if that's useful, just wanted to raise it first in case there's a reason it's currently left unset that I'm not seeing.

[zwiesman31]

Tagging @galatanovidiu @lancewillett for review here. Thanks!

[lancewillett]

Thanks for the issue, @alisadiq90

My quick read:

• This looks more like an identification or observability enhancement, not a security fix. We should not encourage user agent only allowlisting as it is trivially spoofed. The header helps classification and troubleshooting, not authentication
• The suggested change is too narrow. Adding the header in wordpress-api.ts misses OAuth discovery, registration, and token requests. A default likely belongs in proxyFetch to cover every outbound WordPress/OAuth request
• We'd use mcp-wordpress-remote/${MCP_WORDPRESS_REMOTE_VERSION} to follow the standard product/version syntax. HTTP recommends sending a concise identifying User-Agent for interoperability and diagnostics, seeRFC 9110

I'll assign this to @galatanovidiu for further comment as I'm less familiar with this codebase.

[alisadiq90]

Thank you all so much for looking into this, @zwiesman31 for looping in the right people, and @lancewillett for the detailed review and assigning it to @galatanovidiu. Really appreciate it.

You're absolutely right on the security framing, and I'm sorry that wasn't clearer in the original writeup. This should only be an identification/observability signal, not a trust boundary, UA is trivially spoofed. The real security boundary is the WordPress Application Password already being sent. I agree security plugins should key off request path plus valid auth for anything block/allow related, and use User-Agent only for classification and troubleshooting.

On scope, you're right, and I wanted to check rather than assume. proxyFetch in fetch-utils.ts looks like the shared chokepoint, used by wordpress-api.ts plus 6 more call sites across mcp-oauth-provider.ts and mcp-oauth-utils.ts (metadata discovery, registration, token exchange). None of them set a User-Agent, and proxyFetch doesn't inject any default headers itself. So my original suggestion only covered 1 of 7 call sites, sorry about that. A default inside proxyFetch, applied only if the caller hasn't already set one, would be a possible way to cover all of them from one place:

export async function proxyFetch(url: string, init?: RequestInit): Promise<Response> {
  const headers = new Headers(init?.headers);
  if (!headers.has('User-Agent')) {
    headers.set('User-Agent', `mcp-wordpress-remote/${MCP_WORDPRESS_REMOTE_VERSION}`);
  }
  const requestInit = { ...init, headers };
  // existing proxy/agent logic below, using requestInit instead of init
  ...
}

MCP_WORDPRESS_REMOTE_VERSION is already exported from config.ts, so no new constant needed, and this lines up with RFC 9110.

Also noticed CUSTOM_HEADERS already works at every call site via getCustomHeaders(), so we're going to start setting our own UA through that today as an immediate step on our end. That said, a default in the codebase would still help everyone else on this bridge who won't think to configure that themselves, so I still think it's worth doing here too.