Skip to content
HighVulnerability

GHSA-q344-5v34-gm84: @sylphx/pdf-reader-mcp: HTTP transport accepts unauthenticated requests despite a configured MCP_API_KEY

Published
Record updated
View JSON
Affected
  • @sylphx/pdf-reader-mcp >= 2.2.0, < 3.0.1
Fixed in
3.0.1
Known exploitation
Not listed in the CISA Known Exploited Vulnerabilities catalog at the last check.

Summary

When @sylphx/pdf-reader-mcp runs as an HTTP server (MCP_TRANSPORT=http), it reads MCP_API_KEY and logs that X-API-Key authentication is enabled, but never validates the header, so the /mcp endpoint accepts unauthenticated requests. With the default bind address of 0.0.0.0, any client that can reach the port can invoke every PDF tool and read any PDF the server process can open on the host, and URL-based sources allow limited SSRF unless --allow-private-ips is set. Only the opt-in HTTP transport is affected; the default stdio transport is not.

Mitigation

Fixed in @sylphx/pdf-reader-mcp@3.0.1, which enforces the X-API-Key header with a constant-time comparison (rejecting missing or mismatched keys with HTTP 401), changes the default bind host to 127.0.0.1, and emits a startup warning when binding a non-loopback host without an API key. Workarounds for deployments that cannot upgrade immediately: set MCP_HTTP_HOST=127.0.0.1; place a reverse proxy in front that enforces authentication; use the default stdio transport instead of HTTP; or restrict filesystem reach with --allow-dir / MCP_PDF_ALLOWED_DIRS.