MCPHub EUVD-2026-114925

Exploitation requires that MCPHub's passthroughHeaders (or openapi.passthroughHeaders) feature be used and that a server entry be configured to forward sensitive headers such as Authorization, Cookie, x-api-key, x-auth-token, proxy-authorization, or the configured bearer header. In vulnerable versions (<=1.0.45/1.1.7) this configuration was not restricted to admins, so a non-admin server owner could set up a forwarding server. The leak is triggered only when a victim user actually invokes a tool on the maliciously-configured server (UI:P/UI:R), at which point their credentials are passed to the attacker-controlled upstream. Limiting factors: the attack needs the ability to create/configure a server entry in the hub, needs victim invocation, affects only deployments that use header passthrough, and discloses a single credential header per invocation (confidentiality-only, no integrity or availability impact). The fix (1.1.8) both filters sensitive headers and restricts header-forwarding configuration to admins; upgrading is the vendor-recommended remediation.

This is a genuine but moderate-priority information-disclosure issue, not a high-urgency emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:L) rates it 5.3 (medium): network-reachable and low-complexity, but with only low confidentiality impact and a required user interaction (UI:P), and no integrity or availability impact. The source diff confirms the mechanism - MCPHub's passthroughHeaders feature forwarded caller-supplied headers to upstream servers without excluding sensitive ones (authorization, cookie, x-api-key, x-auth-token, proxy-authorization, and the configured bearer header), and server/header configuration was not restricted to admins - so a server owner could cause an invoking user's platform credentials to be forwarded to an attacker-controlled upstream. Decision signals are muted: vuln.today priority is 'this_month' (not act_now/emergency), there is no CISA KEV listing and no EPSS score in the input, so there is no evidence of active or widespread exploitation. A public PoC reference exists (0xGenesi write-up) but it is not verified as working exploit code. One signal conflict to verify: the input vector states PR:N, but the fix gates passthrough-header configuration behind admin privileges and the realistic attack requires an authenticated server-creation capability, so the practical privilege requirement is likely higher than PR:N implies - treat the 'unauthenticated' framing with caution.

A non-admin MCPHub user creates or imports an HTTP/OpenAPI server entry configured to pass through sensitive caller headers (e.g. Authorization or Cookie) to an endpoint they control. When another user invokes a tool on that server through the hub, MCPHub forwards their platform credentials to the attacker's upstream, where they are harvested. A public PoC reference describing OpenAPI passthroughHeaders credential exfiltration exists but is not verified as working exploit code; exploitation depends on the victim actually invoking the malicious server (UI:P).