https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 25 Oct 2026 20:41:43 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-115478 <p>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/&lt;type&gt;/&lt;name&gt;.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`&#39;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…</p> <p>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/&lt;type&gt;/&lt;name&gt;.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`&#39;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…</p> https://db.gcve.eu/vuln/fkie_cve-2026-115478 https://db.gcve.eu/vuln/ghsa-r3g7-r4hr-m258 <p><strong>Affected:</strong> npm: obsidian-tc</p> <p>### Summary `create_entity`, `link_entities`, `rename_entity`, `unlink_entities` and `delete_entity` regenerate a memory note&#39;s body from SQLite at the computed `memory/&lt;type&gt;/&lt;name&gt;.md` path. When a note already existed at that path and was not owned by the entity being written (a hand-authored note, or an orphan left by a different entity whose name sanitized to the same path), its entire body was overwritten on the next write naming that `(type, name)`, keeping only its frontmatter. Separately, several of these tools inserted or removed their SQLite row before the fallible filesystem step, so a refused note write could leave a relation gone, a retired status committed, or the wrong entity deleted.</p> <p>### Details - `create_entity` and `link_entities` inserted the SQL row or relation before materialization. - `rename_entity` seeded the destination path with a direct atomic write that bypassed the ownership check, and for a status-only rename could commit a retired status with the note write refused. - `unlink_entities` removed the relation row before discovering the source note&#39;s rematerialization would be refused. - `delete_entity`&#39;s cascade could delete the target and its relations before a neighbour&#39;s note was found to be foreign.</p> <p>The overwrite exists in every released version since `materializeEntity` shipped (`git show v1.0.1:packages/server/src/memory/materialize.ts`).</p> <p>### Impact An authorized caller with memory-write scope (any agent using the M5 memory tools) can, w…</p> <p><strong>Affected:</strong> npm: obsidian-tc</p> <p>### Summary `create_entity`, `link_entities`, `rename_entity`, `unlink_entities` and `delete_entity` regenerate a memory note&#39;s body from SQLite at the computed `memory/&lt;type&gt;/&lt;name&gt;.md` path. When a note already existed at that path and was not owned by the entity being written (a hand-authored note, or an orphan left by a different entity whose name sanitized to the same path), its entire body was overwritten on the next write naming that `(type, name)`, keeping only its frontmatter. Separately, several of these tools inserted or removed their SQLite row before the fallible filesystem step, so a refused note write could leave a relation gone, a retired status committed, or the wrong entity deleted.</p> <p>### Details - `create_entity` and `link_entities` inserted the SQL row or relation before materialization. - `rename_entity` seeded the destination path with a direct atomic write that bypassed the ownership check, and for a status-only rename could commit a retired status with the note write refused. - `unlink_entities` removed the relation row before discovering the source note&#39;s rematerialization would be refused. - `delete_entity`&#39;s cascade could delete the target and its relations before a neighbour&#39;s note was found to be foreign.</p> <p>The overwrite exists in every released version since `materializeEntity` shipped (`git show v1.0.1:packages/server/src/memory/materialize.ts`).</p> <p>### Impact An authorized caller with memory-write scope (any agent using the M5 memory tools) can, w…</p> https://db.gcve.eu/vuln/ghsa-r3g7-r4hr-m258