p PatchFirst

PatchFirst · Latest vulnerabilities

obsidian-tc vulnerabilities

Vulnerabilities published for obsidian-tc in the last 30 days: 7. Listed in the KEV catalogue: 0.

RSS ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 7

  1. CVE-2026-115478

    High · CVSS 7.1EPSS 0.45%Fix available

    obsidian-tc: Memory-lifecycle tools overwrite unowned notes or partially commit lifecycle changes

    obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. From 1.0.1 until 1.31.4, `create_entity`, `link_entities`, `rename_entity`, `unlink_entities` and `delete_entity` regenerate memory notes from SQLite at the computed `memory/<type>/<name>.md` path without reliably preserving note ownership or the consistency of a failed lifecycle operation. During shared materialization, a hand-authored note or an orphan left by a different entity whose name sanitized to the same path could have its entire body overwritten on the next write naming that type and name, with non-owned frontmatter preserved. `rename_entity`

    • Update to 1.31.4
    Published Updated
  2. CVE-2026-115477

    High · CVSS 7.1EPSS 0.5%Fix available

    obsidian-tc: Declined human-in-the-loop confirmations can permit destructive calls over HTTP

    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

    • Update to 1.31.4
    Published Updated
  3. CVE-2026-77361

    Medium · CVSS 4.7EPSS 0.11%Fix available

    obsidian-tc symlink path mismatch bypasses read ACL restrictions

    obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, read access-control list (ACL) checks use a lexical vault-relative path while containment checks use the resolved path. An in-vault symlink under an allowed glob that resolves into a denied folder can therefore bypass the read ACL and expose files in the denied folder. Exploitation requires an out-of-band-planted symlink and does not permit an escape from the vault root. Version 1.3.1 fixes the vulnerability by applying ACL checks to the resolved vault-relative path.

    • Update to 1.3.1
    Published Updated
  4. CVE-2026-77362

    Medium · CVSS 4.3EPSS 0.2%Fix available

    obsidian-tc bridge tools expose data outside the read ACL

    obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, bridge tools do not consistently apply the read access-control list (ACL) to every returned field. The tasks_filter tool exposes group counts derived from denied notes, makemd_query passes unfiltered sibling result fields through, and list_templates exposes template paths and parsed user-function bodies without a read-whitelist check. An authenticated caller can consequently infer or read data from notes outside the caller's read ACL. Version 1.3.1 fixes the vulnerability by filtering path-attributable fields and applying the read whiteli

    • Update to 1.3.1
    Published Updated
  5. CVE-2026-77366

    Critical · CVSS 9.9EPSS 0.31%Fix available

    obsidian-tc tokens can access arbitrary configured vaults

    obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, tool dispatch does not compare the caller-controlled input.vault value with the vault bound to the caller, the JSON Web Token (JWT) has no vault claim, and the folder access-control list is shared globally. Any valid token can therefore select another configured vault and read, write, or delete its contents through affected tools. Version 1.3.1 fixes the vulnerability by binding tokens and request context to a vault and rejecting mismatched input.vault values before scope checks.

    • Update to 1.3.1
    Published Updated
  6. CVE-2026-77364

    Medium · CVSS 6.5EPSS 0.24%Fix available

    obsidian-tc fail-open default ACL exposes Obsidian control-directory secrets

    obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, undefined readPaths and writePaths settings allow all paths, strictReadDefault does not protect direct requests, and the .obsidian, .git, and .trash control directories are excluded only during enumeration. An authenticated caller can directly read sensitive files such as .obsidian/plugins/*/data.json, potentially exposing plugin API keys, Obsidian Sync passwords, and other in-vault data. Version 1.3.1 fixes the vulnerability by denying the control directories by default and enforcing strictReadDefault on direct request paths.

    • Update to 1.3.1
    Published Updated
  7. CVE-2026-77363

    High · CVSS 8.8EPSS 0.16%Fix available

    obsidian-tc Streamable HTTP transport permits cross-origin loopback vault access

    obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, the Streamable HTTP transport does not validate the Host or Origin header or enable DNS-rebinding protection. When the documented loopback configuration uses auth.mode set to none, a malicious web page can send requests to the local MCP endpoint and receive unrestricted vault access through the http-local caller. Version 1.3.1 fixes the vulnerability by enabling host, origin, and DNS-rebinding validation.

    • Update to 1.3.1
    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →