Live › vulnerability › CVE-2026-115478
Go to dashboardThe obsidian-tc MCP memory tools (create, link, rename, unlink and delete entity) regenerate a note's body from SQLite at a computed path, overwriting any existing note there that the entity does not own, such as a hand-authored note. They can also commit SQLite changes before a refused note write, leaving the memory graph inconsistent with the files on disk.
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.0.1, <= 1.31.3 | 1.31.4 |
Run npm ls obsidian-tc in the project that runs the MCP server and check whether the version is between 1.0.1 and 1.31.3 inclusive.
1.31.4 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
create_entity, link_entities, rename_entity, unlink_entities and delete_entity regenerate a memory note's body from SQLite at the computed memory/<type>/<name>.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.
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's rematerialization would be refused.delete_entity's cascade could delete the target and its relations before a neighbour's note was found to be foreign.The overwrite exists in every released version since materializeEntity shipped (git show v1.0.1:packages/server/src/memory/materialize.ts).
An authorized caller with memory-write scope (any agent using the M5 memory tools) can, without intending to, destroy the body of a vault note outside the entity it is writing, and can leave the memory graph inconsistent with the notes on disk. Snapshots-before-write (restore_note) mitigate the overwrite only where snapshots are enabled and the note had been written through obsidian-tc before.
Fixed in 1.31.4 at the shared primitive: materializeEntity refuses to write over a note whose obsidian_tc_id is missing or belongs to another entity; a new assertNoteOwnership pre-check runs before any SQLite mutation in the three lifecycle tools, so a refusal is a no-op; create_entity and link_entities roll back the row they had inserted. Verified by test/m5-memory-ownership.test.ts, which covers all five call sites and the rollback.
None that preserve the tools. Disabling the write:memory scope for callers prevents the write path entirely.
Found by the maintainer while building obsidian-tc memory import (PR #978); the vulnerability class was independently confirmed by a cross-vendor adversarial review.
## [1.31.4] ### Securitypackages/server/src/memory/materialize.ts, packages/server/src/tools/m5/memory-lifecycle-tools.tsThis page as .md · .json · in your agent: get_signal("CVE-2026-115478")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.