Who is affected by CVE-2026-62264 and what is the fix?

Per the GitHub advisory GHSA-q344-5v34-gm84, @sylphx/pdf-reader-mcp versions from 2.2.0 up to but not including 3.0.1 are affected, and only when run with the opt-in HTTP transport (MCP_TRANSPORT=http). The default stdio transport is unaffected. Version 3.0.1 enforces the X-API-Key header with a constant-time comparison when MCP_API_KEY is set, defaults the bind host to 127.0.0.1 and warns when binding a non-loopback host without a key. Upgrading alone does not add authentication; a key must be set.

Is this being exploited?

No evidence of exploitation found as of October 29, 2026 in the CISA KEV JSON feed (released 2026-10-28T19:00Z, which predates the advisory, so it could not yet list this CVE), the GitHub advisory text (which describes a private report by a researcher credited as novice-22) or the NVD API (no record). That is an absence of evidence in sources that are partly too early to show anything, not proof. Exposed instances are discoverable by anyone who can reach the port, so our assessment is that exposure matters more than the score.

Who scored it and is there an NVD record?

The 7.5 (CVSS 3.1, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) is the GitHub-supplied score on the advisory; we could not confirm GitHub's CNA role because CVE.org has no record yet. When we queried the NVD API on October 29, 2026 it returned zero results for CVE-2026-62264, and the CVE.org API returned a record-does-not-exist error, so there is no NVD primary score yet. The NVD and CVE.org entries may simply not have propagated.

pdf-reader-mcp Said API Key Auth Was On…

GitHub published an advisory on October 29, 2026 for @sylphx/pdf-reader-mcp, an MCP server that exposes PDF-reading tools to AI agents. It is tracked as CVE-2026-62264 (GHSA-q344-5v34-gm84) and rated high, CVSS 3.1 7.5, by GitHub (the score shown on the advisory; there is no NVD score yet). The authentication a deployer thought they had turned on was not being enforced.

What the advisory says

When the server runs with MCP_TRANSPORT=http, it reads the MCP_API_KEY environment variable and logs API key authentication enabled (X-API-Key header) at startup. According to the advisory, it never validated the X-API-Key header on incoming requests. The key was read into a variable and not used on the request path.

The /mcp endpoint therefore accepted unauthenticated requests. The advisory adds that the default bind address was 0.0.0.0, so any client able to reach the port could call every PDF tool and read any PDF the server process could open on the host. URL-based sources also allow limited server-side request forgery; private and loopback addresses are blocked by default unless --allow-private-ips is set.

The advisory lists CWE-200, CWE-287 and CWE-306. It also makes the point that the startup message made the exposure silent: an operator who set a key had reason to believe the server was protected.

Who is affected

Affected versions are 2.2.0 up to but not including 3.0.1, and only for the HTTP transport. We did not check whether versions before 2.2.0 have an HTTP transport; we rely on the advisory’s range. The default stdio transport is unaffected. The finder is credited as novice-22 and reported it privately.

The fix predates the advisory

The patch is not new, and the fix lives in the SylphxAI/anymd repository, while the advisory’s source location is SylphxAI/pdf-reader-mcp (the project appears to have been renamed or moved). The GitHub release for v3.0.1 is dated June 25, 2026, and the npm registry shows 3.0.1 published the same day. The advisory appeared on October 29, about four months later. The upstream commit message describes the fix: when MCP_API_KEY is set, every /mcp request must present a matching X-API-Key header (SHA-256 plus timingSafeEqual) or receive a 401, while /mcp/health stays open. It also changes MCP_HTTP_HOST to default to 127.0.0.1 and prints a startup warning when a non-loopback host is bound with no key.

The npm package has since moved on. Its registry description says pdf-reader-mcp is now @sylphx/anymd, a compatibility alias, and the latest tag is 8.5.5 (published October 19). We did not test whether 8.x still ships the HTTP transport or this code path, or behaves differently; the advisory’s affected range ends at 3.0.1.

What to do

Upgrade to 3.0.1 or later and set MCP_API_KEY. Per the fix notes, the header is enforced only when a key is set; without one, 3.0.1 relies on the loopback default and a startup warning. Anyone running the HTTP transport on a version from 2.2.0 to 3.0.0 is in the affected range.
If you cannot upgrade, the advisory’s workarounds are to bind to loopback with MCP_HTTP_HOST=127.0.0.1, put an authenticating reverse proxy in front, use stdio, or restrict filesystem reach with --allow-dir or MCP_PDF_ALLOWED_DIRS.
Our advice, not the advisory’s: if the HTTP transport was ever reachable beyond localhost with the old default, treat the PDFs on that host as potentially read and review access logs where they exist. No evidence of abuse found as of October 29, 2026 in the KEV feed (released 2026-10-28T19:00Z), the advisory text or the NVD API (no record), but the startup log line that said authentication was enabled is not evidence of protection.

Why it matters

In this case, as the advisory describes it, configuration, log output and behavior disagreed. npm reported 2,792 downloads of the package for October 22 to 28. That covers all versions, probably mostly the newer alias releases, and includes mirrors and automated installs, so we do not read it as a count of exposed servers.

Sourcing

Sources opened: the GitHub advisory API record, the upstream v3.0.1 release and commit, the npm registry and download API, the NVD API, the CVE.org API and the CISA KEV feed. Not opened: any exploit code or scanning data, so we cannot say how many instances are exposed.

pdf-reader-mcp Said API Key Auth Was On but Never Checked It (CVE-2026-62264)