github · obsidian-mcp-toolsb77d9cb2eff1

RemediationAI

The problem is that the fetch tool accepts arbitrary URLs from callers without checking if they are authorized to access those resources, enabling IDOR attacks. Implement a URL allowlist or authorization check by adding a function like `isUrlAuthorized(url: string, callerId: string): boolean` that validates the URL against a caller-specific policy before calling `fetch()`. This ensures only pre-approved URLs or URL patterns can be fetched on behalf of each caller. Verify the fix by testing that fetch rejects URLs not in the allowlist and logs the rejection attempt.

RemediationAI

The problem is that the tool is named 'fetch', which shadows the reserved HTTP/network tool namespace and creates ambiguity in tool registries. Rename the tool to include a server-specific prefix, such as 'obsidian_fetch' or 'vault_fetch', by changing the tool name in the `ToolRegistry.register()` call in `packages/mcp-server/src/fetch/index.ts`. This prevents namespace collisions and makes the tool's origin and purpose explicit. Verify by checking that `list_tools()` returns the new prefixed name and no other tools conflict with it.

RemediationAI

The problem is that the fetch tool uses a module-level DEFAULT_USER_AGENT constant and makes unauthenticated HTTP requests without consulting the caller's identity or credentials, allowing the server to impersonate all callers identically. Modify the fetch handler to accept an optional `credentials` or `auth` parameter and pass caller identity to the fetch function via a new parameter like `callerId: string`, then construct a per-caller User-Agent or auth header. This ensures each request is attributed to the correct caller and respects their authentication context. Verify by inspecting HTTP request headers in a test to confirm the User-Agent or Authorization header reflects the caller's identity.

RemediationAI

The problem is that untrusted external webpage content is returned verbatim with only a bare text prefix ('Contents of {url}:'), allowing indirect prompt injection if the fetched content contains LLM instructions. Wrap the fetched content in a structured delimiter and mark it as untrusted by changing the response format to use XML-style tags like `<untrusted_external_content url="{url}">...</untrusted_external_content>` or a JSON object with a `source` and `content_type` field. This provides the LLM with explicit provenance and signals that the content is not from a trusted source. Verify by fetching a URL containing prompt-injection payloads and confirming the LLM treats the content as data, not instructions.

RemediationAI

The problem is that @modelcontextprotocol/sdk version 1.0.4 contains 2 known HIGH-severity CVEs (GHSA-8r9q-7v3j-jr4g and GHSA-w48q-cv73-mx4w). Update the dependency in `packages/mcp-server/package.json` by changing `"@modelcontextprotocol/sdk": "1.0.4"` to a patched version (e.g., `"@modelcontextprotocol/sdk": "^1.1.0"` or the latest available), then run `bun install` to fetch the fixed version. This removes the vulnerable code paths that the CVEs exploit. Verify by running `bun list @modelcontextprotocol/sdk` and confirming the installed version is no longer 1.0.4, then check the package's security advisory page to confirm the CVEs are resolved in that version.

Evidence

});

	console.log("Watching for changes...");

	for await (const event of watcher) {

		console.log(`Detected ${event.eventType} in ${event.filename}`);

		await build();

	}

}

RemediationAI

The problem is that user-controlled values (event.eventType and event.filename) are printed directly to the terminal without ANSI escape sequence sanitization, allowing malicious input to inject cursor-control sequences that rewrite output or hide commands. Sanitize the output by importing a library like `strip-ansi` or manually removing ANSI escape sequences before logging, e.g., `console.log(`Detected ${sanitizeAnsi(event.eventType)} in ${sanitizeAnsi(event.filename)}`);`. This prevents terminal injection attacks. Verify by creating a test file with ANSI escape sequences in its name and confirming the logged output displays the raw filename without executing any control sequences.

Evidence

*

 * @example

 * ```ts

 * const html = await fetch("https://bcurio.us/resources/hdkb/gates/44");

 * const md = convertHtmlToMarkdown(await html.text(), "https://bcurio.us");

 * await Bun.write("playground/bcurious-gate-44.md", md);

 * ```

RemediationAI

The problem is that the fetch call in `convertHtmlToMarkdown()` and related network operations lack an explicit timeout, allowing a malicious or hung upstream to pin threads and exhaust connection pools. Add a timeout parameter to the fetch call by using `fetch(url, { timeout: 30000 })` (30 seconds) or wrapping the call in `Promise.race([fetch(...), timeout(30000)])`, and document the timeout in the function signature. This ensures the server remains responsive even if upstream is slow or unresponsive. Verify by testing with a URL that never responds and confirming the request fails after the timeout interval rather than hanging indefinitely.

Evidence

# MCP Server Installation Feature Requirements

## Overview

This feature enables users to install and manage the MCP server executable through the Obsidian plugin settings interface. The system handles the download of platform-specific binaries, Claude Desktop configuration, and provides clear user feedback throughout the process.

## Implementation Location

The installation feature is implemented in the Obsidian plugin package under `src/features/mcp-server-install`.

## Installation Flow

1.

RemediationAI

The problem is that the MCP manifest in `docs/features/mcp-server-install.md` declares tools but does not specify an authentication mechanism, making it unclear whether the server relies on network-layer auth, host-level auth, or no auth at all. Add an explicit `authentication` or `auth` field to the manifest documentation describing the actual mechanism (e.g., `"auth": "mtls"` or `"auth": "host-level-only"`), or update the README to clearly state the authentication model. This allows reviewers to audit the security model. Verify by reviewing the updated documentation and confirming that an auditor can determine exactly how the server authenticates callers.

Evidence

# MCP Tools for Obsidian - Server

A secure Model Context Protocol (MCP) server that provides authenticated access to Obsidian vaults. This server implements MCP endpoints for accessing notes, executing templates, and performing semantic search through Claude Desktop and other MCP clients.

## Features

### Resource Access

- Read and write vault files via `note://` URIs

- Access file metadata and frontmatter

- Semantic search through Smart Connections

- Template execution via Templater

### Sec

RemediationAI

The problem is that the MCP manifest in `packages/mcp-server/README.md` declares tools but lacks an explicit authentication field, leaving the security model ambiguous for reviewers. Add a dedicated 'Authentication' section to the README that explicitly documents the auth mechanism (e.g., 'This server uses host-level authentication via Obsidian plugin credentials' or 'Network-layer mTLS'), or add an `auth` field to any manifest JSON. This clarifies the security boundary. Verify by having a security reviewer read the updated documentation and confirm they can identify the authentication model without ambiguity.

Evidence

#!/usr/bin/env bun

import { logger } from "$/shared";

import { ObsidianMcpServer } from "./features/core";

import { getVersion } from "./features/version" with { type: "macro" };

RemediationAI

The problem is that ToolRegistry.list() returns tools without per-tool integrity fields (version, etag, digest, or sha256), so if list_changed is emitted, an attacker could swap tool definitions undetected. Add integrity fields to each tool in the ToolRegistry response by including a `sha256` or `etag` field computed from the tool's schema and implementation, e.g., `{ name: "fetch", description: "...", sha256: "abc123..." }`. This allows clients to detect unauthorized tool modifications. Verify by computing the hash of a tool's definition, emitting list_changed, and confirming that a client can detect if the tool's hash has changed.

Evidence

- uses: actions/checkout@v4

      - name: Setup Bun

        uses: oven-sh/setup-bun@v2

        with:

          bun-version: latest

RemediationAI

The problem is that `.github/workflows/release.yml` uses `actions/checkout@v4`, which is a mutable tag that can be rewritten by a compromised maintainer, allowing malicious code injection into the CI pipeline. Replace `uses: actions/checkout@v4` with `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.1.1` (pinned to a specific commit SHA with a version comment for readability). This ensures the exact version of the action is always used. Verify by running `git log --oneline .github/workflows/release.yml` and confirming the SHA is hardcoded and matches a known release tag.

Evidence

- name: Upload Release Artifacts

        env:

          GH_WORKFLOW_URL: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}

        uses: ncipollo/release-action@v1

        with:

          allowUpdates: true

          omitName: true

RemediationAI

The problem is that `.github/workflows/release.yml` uses `ncipollo/release-action@v1`, a mutable tag that can be rewritten to inject malicious code. Replace it with `uses: ncipollo/release-action@c65f4d75c732e9c206ef63d029ba5a1b2bcfb4ec # v1.14.0` (pinned to a specific commit SHA with version comment). This locks the action to a known, immutable version. Verify by checking the GitHub release page for ncipollo/release-action to confirm the SHA corresponds to v1.14.0 or your intended version.

Evidence

- name: Get existing release body

        id: get_release_body

        uses: actions/github-script@v7

        with:

          result-encoding: string # This tells the action to return a raw string

          script: |

RemediationAI

The problem is that `.github/workflows/release.yml` uses `actions/github-script@v7`, a mutable tag that could be compromised. Replace it with `uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7.0.1` (pinned to a specific commit SHA with version comment). This prevents tag rewriting attacks. Verify by confirming the SHA matches the intended version on the GitHub Actions marketplace or release page.

Evidence

- name: Create Release

        id: create_release

        uses: softprops/action-gh-release@v1

        with:

          generate_release_notes: true

          draft: false

RemediationAI

The problem is that `.github/workflows/release.yml` uses `softprops/action-gh-release@v1`, a mutable tag vulnerable to rewriting. Replace it with `uses: softprops/action-gh-release@de2c0eb89ae2a093876385947365aba7aa56d3c7 # v1.0.0` (pinned to a specific commit SHA with version comment). This ensures the exact release action code is used. Verify by checking the softprops/action-gh-release GitHub repository to confirm the SHA matches your intended version.

Evidence

id-token: write

      attestations: write

    steps:

      - uses: actions/checkout@v4

      - name: Setup Bun

        uses: oven-sh/setup-bun@v2

RemediationAI

The problem is that `.github/workflows/release.yml` uses `actions/checkout@v4` and `oven-sh/setup-bun@v2`, both mutable tags. Replace `actions/checkout@v4` with `actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.1.1` and `oven-sh/setup-bun@v2` with the corresponding commit SHA (e.g., `oven-sh/setup-bun@4c905cbb38844f188f1565602d3d12c7ec1adfea # v2.0.0`). This prevents both actions from being silently updated to malicious versions. Verify by inspecting the workflow file and confirming all `uses:` statements contain 40-character commit SHAs.

Evidence

run: bun run zip

      - name: Generate artifact attestation for MCP server binaries

        uses: actions/attest-build-provenance@v2

        with:

          subject-path: "packages/mcp-server/dist/*"

RemediationAI

The problem is that `.github/workflows/release.yml` uses `actions/attest-build-provenance@v2`, a mutable tag that could be compromised. Replace it with `uses: actions/attest-build-provenance@bdd51370e0416ac948727f861e03c2f05d31d993 # v2.1.0` (pinned to a specific commit SHA with version comment). This ensures the attestation action is not silently replaced. Verify by checking the GitHub Actions marketplace for the correct SHA corresponding to v2.1.0 or your intended version.

Evidence

import { logger, type ToolRegistry } from "$/shared";

import type { Server } from "@modelcontextprotocol/sdk/server/index.js";

import { ErrorCode, McpError } from "@modelcontextprotocol/sdk/types.js";

import { type } from "arktype";

import { DEFAULT_USER_AGENT } from "./constants";

import { convertHtmlToMarkdown } from "./services/markdown";

export function registerFetchTool(tools: ToolRegistry, server: Server) {

  tools.register(

    type({

      name: '"fetch"',

      arguments: {

        url

RemediationAI

The problem is that the fetch tool description or documentation contains imperative language directing the LLM to invoke other tools (e.g., 'invoke the write_file tool'), which is a cross-tool chaining injection that escalates privileges beyond what the user authorized. Rewrite the tool description in `packages/mcp-server/src/features/fetch/index.ts` to describe only what the tool does (e.g., 'Fetches and returns the content of a URL') without mentioning or directing the LLM to use other tools. If the tool requires composition, document the dependency in a separate human-readable guide, not in the tool description. Verify by reviewing the tool description and confirming it contains no imperative verbs like 'invoke', 'call', 'use', or 'also'.

Evidence

import { makeRequest, type ToolRegistry } from "$/shared";

import type { Server } from "@modelcontextprotocol/sdk/server/index.js";

import { type } from "arktype";

import { LocalRestAPI } from "shared";

export function registerLocalRestApiTools(tools: ToolRegistry, server: Server) {

  // GET Status

  tools.register(

    type({

      name: '"get_server_info"',

      arguments: "Record<string, unknown>",

    }).describe(

      "Returns basic details about the Obsidian Local REST API and authentic

RemediationAI

The problem is that `packages/mcp-server/src/features/local-rest-api/index.ts` registers tools that perform destructive operations (DELETE, PUT, PATCH, or file deletion) but emits no audit event, leaving no trail for investigators to determine who performed the action and when. Add an audit event emission after each destructive operation by calling a function like `auditLog.record({ action: 'DELETE', resource: url, callerId, timestamp, result })` or logging to a structured audit sink. This ensures all destructive actions are recorded. Verify by performing a destructive operation and confirming an audit log entry is created with the caller ID, action, resource, and timestamp.