Obsidian Tc
Approved changes feed: RSS · Atom
cpe:2.3:a:the-40-thieves:obsidian-tc:*:*:*:*:*:*:*:*part: a version: * update: *
| Vendor | The 40 Thieves (92211b5e-85f6-513b-bc66-7ed931a30a34) |
|---|---|
| Product | Obsidian Tc (2d379220-a0ff-526f-97c0-e710b21d1139) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
Notes
Imported from gcve-enriched-dumps CVE data
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-115477 |
vulnerable | 2026-11-03 10:15:37.762936 |
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 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.
Published: 2026-10-23T14:04:33.518Z
Updated: 2026-10-29T17:50:19.455Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-115478 |
vulnerable | 2026-11-03 10:15:37.497696 |
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` also seeded the destination path with a direct atomic write without validating ownership and could overwrite a foreign note there. Separately, several tools mutated SQLite before fallible filesystem work: `create_entity` and `link_entities` inserted the row or relation before materialization; `rename_entity` updated the entity, including a retired status, before updating its note; `unlink_entities` removed a relation before rematerializing the source note; and `delete_entity`'s cascade removed the target and its relations before rematerializing neighbouring notes. A later filesystem failure could therefore leave a row or relation changed and the memory graph inconsistent with the notes on disk even when the operation failed. An authorized caller with the required memory-tool permissions could, without intending to, destroy the body of a vault note outside the entity being written; `delete_entity` additionally requires its deletion permission and destructive confirmation, which this memory flaw does not bypass. Snapshots-before-write through `restore_note` mitigate the overwrite only where snapshots are enabled and the note had previously been written through obsidian-tc. This issue is fixed in version 1.31.4.
Published: 2026-10-23T14:06:28.128Z
Updated: 2026-10-30T17:46:48.838Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-77361 |
vulnerable | 2026-11-03 10:15:17.966970 |
obsidian-tc symlink path mismatch bypasses read ACL restrictions
MEDIUM (4.7)
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.
Published: 2026-10-13T14:00:39.982Z
Updated: 2026-10-16T21:58:14.281Z Reference links |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-77366 |
vulnerable | 2026-11-03 10:15:17.310274 |
obsidian-tc tokens can access arbitrary configured vaults
CRITICAL (9.9)
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.
Published: 2026-10-12T17:54:31.642Z
Updated: 2026-10-13T15:14:30.957Z Reference links |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.
Inspect record JSON
Open this panel to browse, search, copy or download the JSON record.