Thursday, 29 October 2026
4 agent hacks today▼ 2 vs yesterday (6)

PDF reader MCP server ignored its own API key setting

An advisory published on 29 October 2026 says @sylphx/pdf-reader-mcp read the MCP_API_KEY variable but never checked it, leaving its HTTP endpoint open.

By The Agentic Times ·

A guard stands at a gate holding an unread badge while strangers walk freely through the open doorway into a glowing chamber.
A guard stands at a gate holding an unread badge while strangers walk freely through the open doorway into a glowing chamber. · Illustration: The Agentic Times

A popular Model Context Protocol server for reading PDF files accepted unauthenticated requests on its HTTP transport, even when operators had configured an API key, according to a GitHub security advisory published on 29 October 2026.

The flaw, tracked as CVE-2026-62264, affects the npm package @sylphx/pdf-reader-mcp from sylphx. MCP servers expose tools to AI agents, so a flaw in one gives anyone who can reach it the same powers the agent would have.

According to the advisory, when the package was run as an HTTP server using MCP_TRANSPORT=http, it read the MCP_API_KEY environment variable and printed the message "API key authentication enabled (X-API-Key header)" at startup. It then never validated the X-API-Key header on incoming requests. The key was stored in a variable and never enforced on the request path.

The result was that the server's /mcp endpoint accepted requests from anyone. The advisory notes this was made worse by the default bind address of 0.0.0.0, meaning the server listened on all network 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.

The tools also accept URL-based sources, which the advisory says enables limited server-side request forgery, where an attacker makes the server fetch URLs on their behalf. Private and loopback addresses are blocked by default unless the --allow-private-ips flag is set.

The advisory highlights the startup log as the central problem. Because the server reported that authentication was enabled, the exposure was silent. An operator who set MCP_API_KEY reasonably believed the server was protected when it was not.

Only the opt-in HTTP transport is affected. The default stdio transport, in which the server communicates over standard input and output with a local process rather than over a network, is unaffected.

The issue is fixed in version 3.0.1. According to the advisory, the fix enforces the X-API-Key header using a constant-time comparison, a technique that avoids leaking information through response timing, and rejects missing or mismatched keys with an HTTP 401 response. The default bind host has been changed to the loopback address 127.0.0.1, and the server now emits a startup warning when it binds to a non-loopback host without an API key set.

For deployments that cannot upgrade immediately, the advisory suggests binding to loopback only by setting MCP_HTTP_HOST=127.0.0.1, placing a reverse proxy in front that enforces authentication, or switching back to the default stdio transport. It also recommends restricting how much of the filesystem the server can reach using the --allow-dir flag or the MCP_PDF_ALLOWED_DIRS variable.

The advisory says the issue was reported privately through responsible disclosure by a researcher using the handle novice-22. The advisory does not state whether any deployments were exploited.

Sources

  1. github.comhttps://github.com/advisories/GHSA-q344-5v34-gm84