Live › vulnerability › CVE-2026-115477
Go to dashboardobsidian-tc (npm, versions 1.13.0 through 1.31.3) lets a client that declined a human-in-the-loop confirmation still run destructive vault tools such as delete and move, on Streamable HTTP deployments with auth.jwtSecret set. An attacker controlling the client, or a non-compliant client, can replay the echoed requestState to execute operations the human refused.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:11 UTC, 3h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| obsidian-tc | npm | >= 1.13.0, <= 1.31.3 | 1.31.4 |
npm ls obsidian-tc affected if between 1.13.0 and 1.31.3 inclusive1.31.4Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
On 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.
Reproduced 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.
A 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.
Fixed 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.
A 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.
Run 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.
Reported in GH #967; found and closed under THE-1106 (PR #969); the residual is documented in SECURITY.md.
## [1.31.4] ### Securitypackages/server/src/mcp/server.ts (tools/call handler), packages/server/src/vault/hitl.tsThis page as .md · .json · in your agent: get_signal("CVE-2026-115477")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.