CVE-2026-115477: obsidian-tc MCP server could run destructive vault actions after you declined them

What it is

Dispatch-gated tools (marked destructive, or in a scope with a human-in-the-loop floor) ask for confirmation through an MCP elicitation form. The server minted the call-bound requestState before asking, then accepted any resubmission that echoed it, whatever the human answered.

The maintainer reproduced a destructive call answered with decline that still wrote. Reachable actions include deleting notes, cross-folder moves, frontmatter replacement and link rewrites. The client has to echo the state after a decline, so it needs a buggy or attacker-controlled client.

CVE-2026-115478 (1.0.1 through 1.31.3): create_entity, link_entities, rename_entity, unlink_entities and delete_entity could overwrite the body of a hand-written or orphaned note at the same memory path, and could leave the memory database half-changed when a note write was refused.

How to check

1. Affected: obsidian-tc (npm) 1.13.0 through 1.31.3 for the confirmation bypass, and 1.0.1 through 1.31.3 for the memory note overwrite.
2. The confirmation bypass only applies to Streamable HTTP deployments with auth.jwtSecret configured and a client that declares elicitation.form support. The overwrite affects any agent given the write:memory scope.

How to fix

1. Upgrade obsidian-tc to 1.31.4 or later. The server now requires the confirmation response itself to be an accept with approve: true.
2. Until you can upgrade, run the server over stdio or leave auth.jwtSecret unset as the advisory suggests, and remove the write:memory scope from agents that don't need it.
3. The advisory notes a limit no server can fix: a malicious client can still approve its own confirmation forms, so only connect clients you trust.

npm ls obsidian-tc

Sources

• obsidian-tc advisory GHSA-737x-cwfr-5vvc ↗
• obsidian-tc advisory GHSA-r3g7-r4hr-m258 (CVE-2026-115478) ↗
• NVD: CVE-2026-115477 ↗
• obsidian-tc v1.31.4 release ↗