obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. From 1.13.0 until 1.31.4, on a Streamable HTTP deployment with `auth.jwtSecret` configured and a 2026-07-28-era client declaring `elicitation.form` support, a dispatch-gated tool call offered an `inputRequired` confirmation could still complete after the human declined or cancelled, or the elicitation response was omitted or malformed, provided the client echoed the validly bound `requestState` on resubmission. The server trusted an authentic, call-bound state as proof of approval even though that state was minted before the `elicitation/create` leg was asked and proved only that the resubmission belonged to the same call. A client behaving incorrectly or under an attacker's control could therefore execute dispatch-gated destructive vault operations without the human's approval, while still requiring the caller's ordinary tool permissions. Only tools marked `destructive: true` or requiring a scope with a human-in-the-loop floor were reachable through this bypass. The sixteen handler-side conditionally gated tools, including `write_note` overwrite and `move_note`, did not read elicitation state on the modern wire and let neither approval nor decline through that path. Affected deployments using stdio or leaving `auth.jwtSecret` unset instead used the CLI `elicit_token` fallback and did not offer this `requestState` round trip. The fix does not prevent a malicious client from reporting a fabricated approval, because the server cannot verify that the client displayed the form or that a human saw it. This issue is fixed in version 1.31.4.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. From 1.13.0
    until 1.31.4, on a Streamable HTTP deployment with `auth.jwtSecret` configured and a 2026-07-28-era client
    declaring `elicitation.form` support, a dispatch-gated tool call offered an `inputRequired` confirmation
    could still complete after the human declined or cancelled, or the elicitation response was omitted or
    malformed, provided the client echoed the validly bound `requestState` on resubmission. The server trusted
    an authentic, call-bound state as proof of approval even though that state was minted before the
    `elicitation/create` leg was asked and proved only that the resubmission belonged to the same call. A
    client behaving incorrectly or under an attacker's control could therefore execute dispatch-gated
    destructive vault operations without the human's approval, while still requiring the caller's ordinary
    tool permissions. Only tools marked `destructive: true` or requiring a scope with a human-in-the-loop
    floor were reachable through this bypass. The sixteen handler-side conditionally gated tools, including
    `write_note` overwrite and `move_note`, did not read elicitation state on the modern wire and let neither
    approval nor decline through that path. Affected deployments using stdio or leaving `auth.jwtSecret` unset
    instead used the CLI `elicit_token` fallback and did not offer this `requestState` round trip. The fix
    does not prevent a malicious client from reporting a fabricated approval, because the server cannot verify
    that the client displayed the form or that a human saw it. This issue is fixed in version 1.31.4.
    (CVE-2026-115477)

ID	Name	Product	Family	Type	Severity
477171	SCA: security update for obsidian-tc (GHSA-737x-cwfr-5vvc)	Tenable Cloud Security	SCA Checks	Local	high
477171	SCA: security update for obsidian-tc (GHSA-737x-cwfr-5vvc)	Tenable Self-Hosted Container Security	SCA Checks	Local	high

Detections

Analytics

CVE-2026-115477

high

Tenable Plugins

high

high