Obsidian-tc let refused actions run, advisory says

A security advisory published on 23 October 2026 says the npm package obsidian-tc allowed destructive operations on a user's note vault to go ahead even after a human had explicitly refused them. The flaw is tracked as CVE-2026-115477 and was fixed in version 1.31.4.

According to the advisory, the problem affected deployments served over Streamable HTTP with auth.jwtSecret configured, where the connecting client declared support for the form-based confirmation prompts introduced in the 2026-07-28 revision of the protocol. In that setup, a tool marked as destructive could be offered an inputRequired confirmation, and the call could still complete after the human declined or cancelled, or when the response was missing or malformed.

The cause was how the server treated a piece of data called requestState. The advisory says the server accepted an authentic, call-bound state as proof that the human had approved the action. But the state is created before the confirmation question is even asked, so it only proves that a resubmitted request belongs to the same original call. A client that echoed back that state after a refusal would get the action executed anyway.

The maintainers say they reproduced the issue directly. A tool call flagged destructive: true was offered a confirmation, answered with a decline, and still wrote to the vault. The advisory describes the affected operations as including deletion, moving notes across folders, replacing frontmatter and rewriting links. The behaviour had been present since the 2026-07-28 round trip shipped in version 1.13.0.

The scope was limited to what the advisory calls dispatch-gated tools. Sixteen other tools gated on the handler side, including overwriting with write_note and move_note, did not read the confirmation state on the modern wire at all, so neither a decline nor an approval passed through them.

Exploiting the flaw requires a client that behaves incorrectly or one under an attacker's control, the advisory says. The server did not enforce the human's refusal on its own.

The fix in 1.31.4 adds a second check. The server now requires the confirmation leg's own response to be an explicit acceptance with an approval flag set, before it will trust the echoed state. A declined, cancelled or unapproved round now returns the ordinary elicit_required error, and the same declined confirmation is never offered a second round. The same release also adds server-initiated in-band confirmation over stdio, so agents running on that transport no longer need to mint their own elicit_token.

One gap remains open. The advisory states plainly that a malicious or non-compliant client can still answer its own confirmation prompt with an approval regardless of what the human actually said. The server cannot verify that the client ever rendered the form or that a person saw it. The maintainers describe this as inherent to the client-driven half of the 2026-07-28 protocol, and say the residual risk is documented in the project's SECURITY.md. The older shim, where the server sends and owns the confirmation leg, does not share the gap.

For anyone unable to upgrade, the advisory suggests two workarounds: run affected deployments over stdio, or leave auth.jwtSecret unset so that the state codec, and therefore the inputRequired prompt, is never offered. Both fall back to the command-line elicit_token path.

The issue was reported in the project's issue tracker and closed by a subsequent pull request, according to the advisory.