Summary
obsidian-tc: Memory-lifecycle tools overwrite unowned notes or partially commit lifecycle changes
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.
Details
create_entityandlink_entitiesinserted the SQL row or relation before materialization.rename_entityseeded 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_entitiesremoved 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).
Workarounds
None that preserve the tools. Disabling the write:memory scope for callers prevents the write path entirely.
Credit
Found by the maintainer while building obsidian-tc memory import (PR #978); the vulnerability class was independently confirmed by a cross-vendor adversarial review.
References
- PR #978 (fix and test), CHANGELOG
## [1.31.4] ### Security packages/server/src/memory/materialize.ts,packages/server/src/tools/m5/memory-lifecycle-tools.ts
Impact
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.
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-115478? CVE-2026-115478 is a high-severity incorrect authorization vulnerability in obsidian-tc (npm), affecting versions >= 1.0.1, <= 1.31.3. It is fixed in 1.31.4. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
- Which versions of obsidian-tc are affected by CVE-2026-115478? obsidian-tc (npm) versions >= 1.0.1, <= 1.31.3 is affected.
- Is there a fix for CVE-2026-115478? Yes. CVE-2026-115478 is fixed in 1.31.4. Upgrade to this version or later.
- Is CVE-2026-115478 exploitable, and should I be worried? Whether CVE-2026-115478 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-115478 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-115478? Upgrade
obsidian-tcto 1.31.4 or later.