obsidian-tc CVE-2026-115478

Requires an authorized caller holding memory-write scope (write:memory) using the M5 memory lifecycle tools create_entity, link_entities, rename_entity, unlink_entities or delete_entity. The overwrite triggers only when a note already exists at the computed memory/<type>/<name>.md path that is 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 - in which case the next write naming that (type, name) regenerates the body from SQLite and overwrites it, keeping only frontmatter; rename_entity can also overwrite a foreign note at the destination because its seeding atomic write bypassed the ownership check. The half-committed-state variant triggers when the SQLite mutation succeeds but the subsequent filesystem materialization is refused. Limiting factors: exploitation needs the memory-write permission (PR:L, not unauthenticated); delete_entity additionally requires its own deletion permission and destructive confirmation, which this flaw does not bypass; and restore_note snapshots mitigate the overwrite only where snapshots are enabled and the note had previously been written through obsidian-tc. The only workaround that fully prevents the write path is disabling write:memory for callers; otherwise updating to 1.31.4 is the fix.

This is a genuine but bounded integrity/data-loss issue rather than a high-CVSS, low-real-risk inflation - yet also not an emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L) scores 7.1: network-reachable, but gated behind PR:L (the caller must already hold memory-write/write:memory scope via the M5 memory tools), with high integrity impact (VI:H), low availability impact (VA:L, from a graph left inconsistent with disk), and no confidentiality impact (VC:N). The CWE pairing (CWE-459 incomplete cleanup plus the advisory's CWE-863 improper authorization) matches the mechanism: a missing ownership check lets a legitimate operation clobber a note it does not own, and SQLite-before-filesystem ordering leaves half-committed lifecycle state. Crucially, the GHSA frames the actor as an authorized caller acting 'without intending to' - this is closer to an agent-safety/data-corruption defect than an adversary-driven RCE. Decision label is this_week, consistent with a prompt-but-not-critical fix. No CISA KEV listing, no EPSS score supplied, and no public exploit or PoC reference is present (the GitHub links are the advisory, fix PR #978, fix commit, changelog, and release - not exploit code). Signals are therefore internally consistent: no evidence of active or widespread exploitation, and the practical trigger (a colliding pre-existing note, or a refused filesystem write) depends on environment state as much as attacker intent.

An agent or client already holding memory-write scope calls create_entity, link_entities, rename_entity or unlink_entities for a (type, name) whose sanitized path, memory/<type>/<name>.md, collides with a hand-authored note or an orphan left by a different entity; materialization regenerates the body from SQLite and overwrites the foreign note's entire body, keeping only its frontmatter. A filesystem write refused after the SQLite row/relation was already mutated additionally leaves the memory graph inconsistent with the notes on disk. No public exploit code or PoC reference is identified at time of analysis; exploitation requires the AV:N/PR:L memory-write permission.