Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
createentity, linkentities, renameentity, unlinkentities and deleteentity 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 - createentity and linkentities inserted the SQL row or relation before materialization. - renameentity 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. - unlinkentities…
Recommended action: Upgrade to 1.31.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Streamable HTTP transport was constructed without enableDnsRebindingProtection/allowedHosts/allowedOrigins and performed no Origin-header validation. With the documented auth.mode: "none" loopback default, a drive-by web page could POST http://127.0.0.1/mcp and receive caller http-local with scopes [""] — full vault read/write — via DNS rebinding / a forged Origin. Patches Fixed in 1.3.1. Upgrade to = 1.3.1. The transport now enables DNS-rebinding protection and allowed hosts/origins and returns HTTP 403 on an invalid Origin (per MCP 2025-11-25). Workarounds Do not expose the HTTP transport with auth.mode: "none"; require JWT auth, or bind to a non-loopback interface behind a proxy that validates Origin.
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Bridge tool results filtered only the items array against the read ACL and passed sibling fields through unfiltered: tasksfilter emitted groups whose counts reflected denied notes, makemdquery returned ...result siblings, and listtemplates enumerated Templater template paths and parsed user-function bodies with no read-whitelist gate. A caller could infer or read data from notes outside its read ACL. Patches Fixed in 1.3.1. Upgrade to = 1.3.1. All path-attributable fields are now scrubbed or fail-closed, and listtemplates is gated on the read whitelist. Workarounds Disable the affected bridge tools (tasksfilter, makemdquery, listtemplates) via tool visibility.
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On a Streamable HTTP deployment with auth.jwtSecret configured, serving a 2026-07-28-era client that declared elicitation.form support, a call to a dispatch-gated tool (destructive: true, or a scope with an HITL floor) that was offered an inputRequired confirmation could still complete after the human declined, 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; the state is minted before the elicitation leg is asked, so it proves only that the resubmission belongs to the same call. Details Reproduced directly: a destructive: true tool call, offered inputRequired, answered with {action: "decline"} on the elicitation/create leg, still wrote. Present since the 2026-07-28 round trip shipped in v1.13.0 (THE-583). Only dispatch-gated tools were reachable; the sixteen handler-side conditionally gated tools (writenote…
Recommended action: Upgrade to 1.31.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Tool dispatch did not check the caller-supplied input.vault against the caller's bound vault (ctx.vaultId); the folder ACL was a single global instance and the JWT carried no vault claim. As a result, any valid token could read, write, or delete any configured vault by passing input.vault, defeating multi-tenant isolation across ~90 tool sites. (resources/read was the only surface that already guarded this.) Patches Fixed in 1.3.1 (the fix was developed on the v1.3.0 tag, which never published to npm; 1.3.1 is the first published release with the fix). Upgrade to = 1.3.1. Workarounds Run a single vault per server process, or isolate each tenant on a separate process/credential. Fix A central input.vault === ctx.vaultId guard was added in dispatch before the scope check.
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact With a default configuration, an undefined readPaths/writePaths meant allow-all, the strictReadDefault flag was inert, and the .obsidian/.git/.trash control directories were denied only during enumeration — not on the direct request path. A caller could read .obsidian/plugins//data.json, exfiltrating plugin API keys and Obsidian Sync passwords (live-reproduced), as well as any other in-vault file by path. Patches Fixed in 1.3.1. Upgrade to = 1.3.1. The default now denies .obsidian/.git/.trash on read/write/delete and honors strictReadDefault on the request path. Workarounds Set an explicit readPaths/writePaths whitelist that excludes the control directories.
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact ACL checks ran on the lexical vault-relative path while containment used the realpath. An in-vault symlink placed under an allowed glob, whose realpath resolved into a denied folder, passed the read ACL — an intra-vault read-ACL-scope bypass. It requires an out-of-band-planted symlink (no MCP tool creates one) and is not a vault-root escape. Patches Fixed in 1.3.1. Upgrade to = 1.3.1. ACL enforcement now derives the realpath vault-relative path and feeds a single unified predicate at every site. Workarounds Do not permit untrusted symlinks inside the vault.
Recommended action: Upgrade to 1.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.