Obsidian Web MCP EUVD-2026-82406

Requires only network reachability to a deployed Obsidian Web MCP server prior to version 0.2.0 - specifically an instance exposed through its recommended Cloudflare Tunnel (or any interface reachable to the attacker). No credentials, session, consent, or user interaction are needed because /oauth/authorize issues codes without any login check and /oauth/token returns the static VAULT_MCP_TOKEN without client authentication; optional PKCE does not stop an attacker-initiated flow, and /oauth/register additionally leaks VAULT_OAUTH_CLIENT_SECRET enabling a client_credentials path. LIMITING factors: the vulnerable server is only exploitable if actually reachable by the attacker - in the pre-fix default it may be tunnel-exposed, and post-0.2.0 it binds to 127.0.0.1 and demands VAULT_OAUTH_PASSWORD; instances never exposed beyond loopback are not remotely reachable.

This is a genuine high-priority issue, not an inflated CVSS. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L, 9.4) is consistent with the description: /oauth/authorize issues an authorization code with no login, consent, or session check, and /oauth/token exchanges it for the static VAULT_MCP_TOKEN without client authentication (CWE-306, Missing Authentication for a Critical Function). The confirming commit (e4924f0, PR#30, GHSA-hwhg-mrjc-8g43) validates the flaw and its fix by introducing a mandatory VAULT_OAUTH_PASSWORD login that fails closed. No EPSS score, CISA KEV listing, or public POC is provided in the input, so exploitation status is 'no public exploit identified at time of analysis' - the risk is driven by triviality of attack (unauthenticated, single-request path, no user interaction) rather than by observed in-the-wild activity. One important mitigating factor the raw CVSS does not capture: post-fix the server binds to 127.0.0.1 by default, so real-world exposure hinges on the recommended Cloudflare Tunnel deployment actually being reachable - the description itself scopes the threat to 'a caller who can reach the intended tunnel deployment.' The A:L rather than A:H is arguably conservative given vault_delete can destroy the entire vault.

An attacker who can reach a vulnerable Obsidian Web MCP instance (via its Cloudflare Tunnel URL) calls /oauth/authorize to obtain an authorization code with no login prompt, exchanges it at /oauth/token for the static VAULT_MCP_TOKEN, and then invokes /mcp tools to read, search, modify, move, or delete every note in the vault. No public exploit code is identified, but the attack is a handful of scriptable HTTP requests requiring no authentication or user interaction; PKCE and /oauth/register (which leaks VAULT_OAUTH_CLIENT_SECRET) provide no protection.