GHSA-q344-5v34-gm84: @sylphx/pdf-reader-mcp: HTTP transport accepts unauthenticated requests despite a configured MCP_API_KEY
Impact
When @sylphx/pdf-reader-mcp is run as an HTTP server (MCPTRANSPORT=http), it reads the MCPAPIKEY environment variable and logs API key authentication enabled (X-API-Key header) at startup, but it never validated the X-API-Key header on incoming requests. The key was read into a variable and never enforced on the request path.
As a result, the /mcp endpoint accepted unauthenticated requests. Combined with the default bind address of 0.0.0.0 (all interfaces), any client able to reach the port could invoke every PDF tool and read the contents of any PDF the server process could open anywhere on the host. URL-based sources also enable limited SSRF (private/loopback addresses are blocked by default unless --allow-private-ips is set).
The misleading startup log made the exposure silent: an operator who set MCPAPIKEY reasonably believed the server was protected when it was not.
This affects only the opt-in HTTP transport; the default stdio transport is unaffected.
Patches
Fixed in @sylphx/pdf-reader-mcp@3.0.1. The fix enforces the X-API-Key header with a constant-time comparison (rejecting missing/mismatched keys with HTTP 401), changes the default bind host to 127.0.0.1 (loopback), and emits a startup warning when binding a non-loopback host without an API key.
Workarounds
For deployments that cannot upgrade immediately:
- Bind to loopback only: MCPHTTPHOST=127.0.0.1. - Place a reverse proxy in front that enforces authentication. - Use the default stdio transport instead of HTTP. - Restrict filesystem reach with --allow-dir / MCPPDFALLOWEDDIRS.
Reported privately by novice-22 via responsible disclosure.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@sylphx/pdf-reader-mcpto a version that resolves this vulnerability.Fixed in 3.0.1 - Upgrade
Upgrade
@sylphx/pdf-reader-mcpto a version that resolves this vulnerability.Fixed in 3.0.1 - Configuration
Bind the HTTP server to loopback only by setting MCP_HTTP_HOST=127.0.0.1.
@sylphx/pdf-reader-mcp HTTP transport MCP_HTTP_HOST = 127.0.0.1 - Configuration
Restrict filesystem access using --allow-dir or MCP_PDF_ALLOWED_DIRS.
@sylphx/pdf-reader-mcp --allow-dir / MCP_PDF_ALLOWED_DIRS = restricted filesystem paths - Configuration
Use the default stdio transport instead of HTTP.
@sylphx/pdf-reader-mcp MCP_TRANSPORT = stdio - Compensating control
Place a reverse proxy in front of the HTTP endpoint and enforce authentication there.
Event History
Frequently Asked Questions
Which deployments are exposed?
Only deployments using the opt-in HTTP transport (MCP_TRANSPORT=http) are affected. The default stdio transport is unaffected.
Who can exploit an affected server?
Any client that can reach the server's port can invoke the /mcp endpoint without providing an API key. This is especially significant because the default bind address is 0.0.0.0, which exposes the service on all interfaces.
What can an unauthenticated caller access?
An unauthenticated caller can invoke every PDF tool and read contents of any PDF that the server process can open anywhere on the host. URL-based sources also allow limited SSRF; private and loopback addresses remain blocked by default unless --allow-private-ips is configured.
Does the startup message indicating API-key authentication is enabled mean the endpoint is protected?
No. Affected versions read MCP_API_KEY and log that API-key authentication is enabled, but did not validate the X-API-Key header on requests.
What version fixes the issue?
The issue is fixed in @sylphx/pdf-reader-mcp version 3.0.1, which enforces the X-API-Key header and rejects missing or mismatched keys with HTTP 401.