Summary
PDF Reader MCP's opt-in HTTP transport reports that API-key authentication is enabled but does not validate the X-API-Key header, allowing unauthenticated clients to access the /mcp endpoint. A reachable HTTP listener may therefore let attackers invoke PDF tools, read accessible documents, and potentially make limited server-side requests through URL-based sources.
PDF Reader MCP's opt-in HTTP transport reports that API-key authentication is enabled but does not validate the X-API-Key header, allowing unauthenticated clients to access the /mcp endpoint. A reachable HTTP listener may therefore let attackers invoke PDF tools, read accessible documents, and potentially make limited server-side requests through URL-based sources.
Affected context
The issue occurs in PDF Reader MCP deployments using the opt-in HTTP transport, specifically when MCP_TRANSPORT=http is enabled. The default stdio transport is not affected. Risk is greatest when the service binds to a reachable interface, such as the default 0.0.0.0 address, and the server process can open sensitive PDF files. URL-based sources may also create limited SSRF exposure, with private and loopback destinations blocked by default unless that protection is explicitly relaxed.
The issue occurs in PDF Reader MCP deployments using the opt-in HTTP transport, specifically when MCP_TRANSPORT=http is enabled. The default stdio transport is not affected. Risk is greatest when the service binds to a reachable interface, such as the default 0.0.0.0 address, and the server process can open sensitive PDF files. URL-based sources may also create limited SSRF exposure, with private and loopback destinations blocked by default unless that protection is explicitly relaxed.
Exploit preconditions
- Attack surface: The HTTP
/mcpendpoint exposed by the MCP server - Required access: Network reachability to the configured HTTP listener; no valid API key is required
- Trigger point: An incoming request to the HTTP MCP endpoint
- Why exploitation is possible: The server reads and logs the configured API key but does not enforce the
X-API-Keyheader before dispatching requests - Additional condition: The server process must have access to documents or resources an attacker attempts to use
- Attack surface: The HTTP
/mcpendpoint exposed by the MCP server - Required access: Network reachability to the configured HTTP listener; no valid API key is required
- Trigger point: An incoming request to the HTTP MCP endpoint
- Why exploitation is possible: The server reads and logs the configured API key but does not enforce the
X-API-Keyheader before dispatching requests - Additional condition: The server process must have access to documents or resources an attacker attempts to use
Why this happens
The underlying defect is a missing authentication enforcement step in the HTTP request-handling path. Configuration and startup logging create the appearance that API-key authentication is active, but requests proceed without comparing a supplied credential against the configured secret. This maps primarily to CWE-306, Missing Authentication for Critical Function, and is also related to CWE-287, Improper Authentication, and CWE-200, Exposure of Sensitive Information.
The underlying defect is a missing authentication enforcement step in the HTTP request-handling path. Configuration and startup logging create the appearance that API-key authentication is active, but requests proceed without comparing a supplied credential against the configured secret. This maps primarily to CWE-306, Missing Authentication for Critical Function, and is also related to CWE-287, Improper Authentication, and CWE-200, Exposure of Sensitive Information.
Potential impact
- Unauthenticated users may invoke available PDF-reading tools
- Attackers could read PDF documents accessible to the server process
- Sensitive document contents may be disclosed
- URL-based tools may enable limited server-side request forgery
- Attackers could consume server resources or abuse exposed tool functionality
- Unauthenticated users may invoke available PDF-reading tools
- Attackers could read PDF documents accessible to the server process
- Sensitive document contents may be disclosed
- URL-based tools may enable limited server-side request forgery
- Attackers could consume server resources or abuse exposed tool functionality
General mitigation guidance
Mitigation generally focuses on enforcing authentication at the HTTP boundary rather than relying on configuration messages or client behavior. Secure-by-default deployments should keep the stdio transport or disable the HTTP transport unless remote access is required. When HTTP is necessary, every request should undergo consistent credential validation before tool dispatch, with secrets stored and compared using appropriate protected mechanisms. Network exposure should be reduced through binding, firewall, proxy, and access-control policies; URL fetching should retain private-network protections and use explicit allowlists where appropriate. The service should run with least-privilege filesystem and network permissions so exposed tools cannot access more data or destinations than necessary.
Mitigation generally focuses on enforcing authentication at the HTTP boundary rather than relying on configuration messages or client behavior. Secure-by-default deployments should keep the stdio transport or disable the HTTP transport unless remote access is required. When HTTP is necessary, every request should undergo consistent credential validation before tool dispatch, with secrets stored and compared using appropriate protected mechanisms. Network exposure should be reduced through binding, firewall, proxy, and access-control policies; URL fetching should retain private-network protections and use explicit allowlists where appropriate. The service should run with least-privilege filesystem and network permissions so exposed tools cannot access more data or destinations than necessary.
How teams detect issues like this
Detection can include static analysis and code review checks that trace authentication configuration through the request handler to an enforced authorization decision. Reviewers should flag startup logs claiming authentication is enabled without a corresponding rejection path for missing or invalid credentials, as well as HTTP listeners bound broadly without network controls. Runtime monitoring can identify unauthenticated requests, unusual tool invocation, unexpected document access, and outbound requests from the MCP process. CI policy checks and automated code-review tools can help detect missing middleware, unprotected routes, and unsafe URL-fetching configuration.
Detection can include static analysis and code review checks that trace authentication configuration through the request handler to an enforced authorization decision. Reviewers should flag startup logs claiming authentication is enabled without a corresponding rejection path for missing or invalid credentials, as well as HTTP listeners bound broadly without network controls. Runtime monitoring can identify unauthenticated requests, unusual tool invocation, unexpected document access, and outbound requests from the MCP process. CI policy checks and automated code-review tools can help detect missing middleware, unprotected routes, and unsafe URL-fetching configuration.
