---
id: "CVE-2026-62264"
kind: "vulnerability"
aliases: ["CVE-2026-62264", "GHSA-q344-5v34-gm84"]
title: "@sylphx/pdf-reader-mcp: HTTP transport accepts unauthenticated requests despite a configured MCP_API_KEY"
severity: "high"
cvss: 7.5
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "@sylphx/pdf-reader-mcp", "fixed": ["3.0.1"], "affected": ">= 2.2.0, < 3.0.1", "ecosystem": "npm"}]
ecosystems: ["npm"]
tags: ["ai-tooling", "cwe-200", "cwe-287", "cwe-306", "mcp", "node", "npm", "pdf", "self-hosted"]
not_affected_if: ["behind-auth-proxy", "loopback-bind", "stdio-transport"]
published_at: "2026-10-29T16:34:35+00:00"
first_seen_at: "2026-10-29T16:39:03+00:00"
updated_at: "2026-10-29T16:39:43+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-q344-5v34-gm84", "first_seen_at": "2026-10-29T16:39:03+00:00"}]
---

# @sylphx/pdf-reader-mcp: HTTP transport accepts unauthenticated requests despite a configured MCP_API_KEY

When run in HTTP mode, the MCP server logs that API key auth is enabled but never checks the X-API-Key header on the /mcp endpoint. Anyone who can reach the port can call every PDF tool and read any PDF the server process can open.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- npm:@sylphx/pdf-reader-mcp affected >= 2.2.0, < 3.0.1 fixed 3.0.1

## How to check

- Check the installed version with `npm ls @sylphx/pdf-reader-mcp` and see whether it is `>= 2.2.0` and `< 3.0.1`.
- Check whether the server runs with `MCP_TRANSPORT=http` and what `MCP_HTTP_HOST` is set to; the default bind is `0.0.0.0`.
- Confirm whether the port is reachable from other machines on the network.

## Fix

- `@sylphx/pdf-reader-mcp` fixed in `3.0.1`; affected range is `>= 2.2.0`, `< 3.0.1`.

## Timeline

- 2026-10-29T16:39:03+00:00 ghsa https://github.com/advisories/GHSA-q344-5v34-gm84

## Documents

- [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/SylphxAI/anymd/security-advisories/GHSA-q344-5v34-gm84
- [advisory] Maintainer's advisory: github.com https://github.com/SylphxAI/pdf-reader-mcp/security/advisories/GHSA-q344-5v34-gm84

## From the sources

### Impact

When `@sylphx/pdf-reader-mcp` is run as an HTTP server (`MCP_TRANSPORT=http`), it reads the `MCP_API_KEY` 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 `MCP_API_KEY` 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: `MCP_HTTP_HOST=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` / `MCP_PDF_ALLOWED_DIRS`.

Reported privately by **novice-22** via responsible disclosure.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_