{"id":"CVE-2026-115477","aliases":["GHSA-737x-cwfr-5vvc"],"title":"obsidian-tc: Declined human-in-the-loop confirmations can permit destructive calls over HTTP","summary":"obsidian-tc: Declined human-in-the-loop confirmations can permit destructive calls over HTTP","severity":"high","cvss":7.1,"cwe":["CWE-285","CWE-863"],"vendor":"obsidian-tc","product":"obsidian-tc","ecosystem":"npm","affected":["obsidian-tc >= 1.13.0, <= 1.31.3"],"patched":["obsidian-tc 1.31.4"],"published":"2026-10-23","updated":"2026-10-23","sourceUpdated":"2026-10-23T17:30:11Z","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-737x-cwfr-5vvc","references":[{"url":"https://github.com/The-40-Thieves/obsidian-tc/security/advisories/GHSA-737x-cwfr-5vvc"},{"url":"https://github.com/The-40-Thieves/obsidian-tc/issues/967"},{"url":"https://github.com/The-40-Thieves/obsidian-tc/pull/969"},{"url":"https://github.com/The-40-Thieves/obsidian-tc/commit/101c91c656e2c2b88bcf3696a5da035f8c032c71"},{"url":"https://github.com/The-40-Thieves/obsidian-tc/blob/v1.31.4/CHANGELOG.md"},{"url":"https://github.com/The-40-Thieves/obsidian-tc/releases/tag/v1.31.4"},{"url":"https://nvd.nist.gov/vuln/detail/cve-2026-115477"},{"url":"https://github.com/advisories/GHSA-737x-cwfr-5vvc"}],"tags":["ghsa","npm","cve.org"],"cvssVector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N","cvssSource":"cna","ingestedAt":"2026-10-23T14:28:08.697Z","slug":"CVE-2026-115477","body":"## Overview\n\n### Summary\nOn a Streamable HTTP deployment with `auth.jwtSecret` configured, serving a 2026-07-28-era client that declared `elicitation.form` support, a call to a dispatch-gated tool (`destructive: true`, or a scope with an HITL floor) that was offered an `inputRequired` confirmation could still complete after the human declined, 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; the state is minted before the elicitation leg is asked, so it proves only that the resubmission belongs to the same call.\n\n### Details\nReproduced directly: a `destructive: true` tool call, offered `inputRequired`, answered with `{action: \"decline\"}` on the `elicitation/create` leg, still wrote. Present since the 2026-07-28 round trip shipped in v1.13.0 (THE-583). Only dispatch-gated tools were reachable; the sixteen handler-side conditionally gated tools (`write_note` overwrite, `move_note`, and others) did not read the elicitation state on the modern wire at all, so they neither let a decline nor an approval through.\n\n### Impact\nA client that echoes state after a decline can execute destructive vault operations (delete, cross-folder move, frontmatter replace, link rewrite) that the human explicitly refused. The precondition is a compliant client behaving incorrectly or a client under an attacker's control; the human's refusal is not enforced by the server.\n\n### Patches\nFixed in 1.31.4: the server now also requires the confirm leg's own response (`inputResponse`) to be `{action: \"accept\", content: {approve: true}}` before trusting the echoed state. A declined, cancelled or not-approved round renders the ordinary `elicit_required` error and is never offered a second round for the same declined confirmation. The same release adds server-initiated in-band confirmation on stdio (legacy era), so stdio agents no longer need to mint `elicit_token` themselves.\n\n### Not addressed\nA malicious or non-compliant client can still answer its own `elicitation/create` leg with an approval regardless of what the human said. The server cannot verify that the client rendered the form or that a human saw it; this is inherent to the client-driven half of the 2026-07-28 protocol. The legacy shim, where the server sends and owns the leg, does not share this gap.\n\n### Workarounds\nRun affected deployments over stdio, or leave `auth.jwtSecret` unset so the `requestState` codec (and therefore `inputRequired`) is never offered; both fall back to the CLI `elicit_token` path.\n\n### Credit\nReported in GH #967; found and closed under THE-1106 (PR #969); the residual is documented in SECURITY.md.\n\n### References\n- PR #969, GH #967, CHANGELOG `## [1.31.4] ### Security`\n- `packages/server/src/mcp/server.ts` (`tools/call` handler), `packages/server/src/vault/hitl.ts`\n\n## Affected packages\n\n- `obsidian-tc >= 1.13.0, <= 1.31.3`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `obsidian-tc 1.31.4`","depth":"twilight","depthScore":39,"depthScoreParts":{"impact":39.1,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}