obsidian-rest-api

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:02 AM UTC
• Version: 1.0.1

Overview

The skill matches its Obsidian automation purpose, but its setup exposes a powerful notes API and stores the API key in unsafe ways.

Review before installing. Use a protected secret store or environment variable instead of TOOLS.md, avoid curl -k by trusting or pinning the API certificate, bind the Obsidian REST API only to the needed local interface, restrict firewall access to the WSL source, and require explicit confirmation before delete or command-execution operations.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:12
• Finding: Obsidian API Bearer Key Stored in Plaintext Workspace Documentation## Vulnerability Details **File Location**: `SKILL.md`, lines 12-24 **Vulnerability Type**: Plaintext storage of a privileged API credential **Risk Level**: High ### Vulnerable Code ```markdown 1. Check TOOLS.md for existing `OBSIDIAN_API_URL` and `OBSIDIAN_API_KEY` 2. If not found: - Get Windows host IP: `cat /etc/resolv.conf | grep nameserver | awk '{print $2}'` - Ask user for API Key - Save to TOOLS.md: ```markdown ### Obsidian REST API (WSL → Windows) **API 端点**: https://<detected-ip>:27124 **API Key**: <user-provided-key> ``` 3. Test connection with saved config ``` The credential is subsequently extracted directly from the plaintext file at `SKILL.md`, lines 36-39: ```bash # Get URL and KEY from TOOLS.md URL=$(grep 'API 端点' ~/.openclaw/workspace/TOOLS.md | awk -F': ' '{print $2}') KEY=$(grep 'API Key' ~/.openclaw/workspace/TOOLS.md | awk -F': ' '{print $2}') ``` ### Technical Analysis The Skill explicitly directs the agent to persist a user-provided bearer key in `~/.openclaw/workspace/TOOLS.md`. This is a general workspace Markdown file rather than a credential manager or access-controlled secret store. The key authorizes operations against the Obsidian Local REST API. According to the bundled API documentation, authenticated clients can read, create, overwrite, append to, partially modify, and delete vault files. They can also interact with the active file and invoke exposed Obsidian commands. Any process, agent, extension, backup service, synchronization mechanism, or user that can read the workspace file can recover the credential. Because it is a bearer token, possession is sufficient for authentication without an additional proof of identity. ### Attack Path 1. The user supplies an Obsidian Local REST API key. 2. The Skill writes the key into `~/.openclaw/workspace/TOOLS.md` as plaintext. 3. An attacker or untrusted local component ob ...[truncated 1130 chars]
• Remediation: ## Remediation Suggestions 1. Do not store bearer keys in `TOOLS.md`, other workspace documentation, source files, or shell history. 2. Store the key in an operating-system credential manager or a dedicated secret-management facility. 3. If file-based storage is unavoidable, use a separate secret file outside the shared workspace, restrict it to the owning user with mode `0600`, and ensure that it is excluded from synchronization, version control, backups, and diagnostic bundles. 4. Load the key through a protected environment variable or secret-injection mechanism without printing it. 5. Redact Authorization headers and credential values from logs, tool output, and error reports. 6. Rotate any key that has already been written to a broadly accessible workspace file. 7. Use a dedicated key with the narrowest permissions supported by the plugin and establish a regular rotation procedure.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:38
• Finding: TLS Certificate Verification Disabled for Authenticated API Requests## Vulnerability Details **File Location**: `SKILL.md`, lines 38-47 **Additional Locations**: `SKILL.md`, lines 52-95 and 117; `references/api.md`, lines 12-16 and subsequent request examples **Vulnerability Type**: Improper TLS certificate validation **Risk Level**: High ### Vulnerable Code ```bash KEY=$(grep 'API Key' ~/.openclaw/workspace/TOOLS.md | awk -F': ' '{print $2}') # Test connection curl -k -H "Authorization: Bearer $KEY" "$URL/" # List vault files curl -k -H "Authorization: Bearer $KEY" "$URL/vault/" # Create note curl -k -X PUT -H "Authorization: Bearer $KEY" -H "Content-Type: text/markdown" \ -d "# Title\nContent" "$URL/vault/note.md" ``` The API reference explicitly defines the insecure option: ```markdown All requests require: ```bash -H "Authorization: Bearer <api-key>" -k # Skip SSL verification (self-signed cert) ``` ``` ### Technical Analysis The `curl -k` option, equivalent to `--insecure`, disables verification of the server certificate and hostname. Although the connection remains encrypted, the client does not authenticate the server. The requests transmit a reusable bearer credential in the `Authorization` header. An attacker able to intercept, redirect, or proxy traffic can present an arbitrary certificate, which `curl -k` will accept. The attacker can then capture the API key, inspect sensitive responses, alter request bodies or responses, and reuse the credential directly against the legitimate service. A self-signed certificate does not require disabling verification. The expected certificate or issuing certificate can instead be explicitly trusted or pinned. ### Attack Path 1. The Skill discovers or loads the Windows-host API URL and bearer key. 2. It sends an authenticated request using `curl -k`. 3. An attacker with a suitable network position performs ARP spoofing, DNS manipulation, route manipulation, gateway compromise, or another traffic-red ...[truncated 1110 chars]
• Remediation: ## Remediation Suggestions 1. Remove `-k` and `--insecure` from every request example and operational instruction. 2. Retrieve the Local REST API plugin certificate through a trusted local setup process and store it in an access-controlled location. 3. Configure requests with explicit certificate validation, for example: ```bash curl --cacert "$OBSIDIAN_CA_CERT" \ -H "Authorization: Bearer $KEY" \ "$URL/" ``` 4. Verify that the hostname or IP address used in the URL is covered by the certificate's Subject Alternative Name. Issue a suitable certificate if necessary. 5. Where certificate lifecycle management is impractical, use public-key pinning with `--pinnedpubkey` and maintain a secure rotation process. 6. Prefer a mutually authenticated tunnel, VPN, SSH forwarding arrangement, or loopback-only connection for cross-host access. 7. Rotate the API key after migrating to verified TLS if it was previously transmitted over an untrusted network with verification disabled.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:110
• Finding: Privileged Obsidian REST API Exposed on All Network Interfaces## Vulnerability Details **File Location**: `SKILL.md`, lines 110-130 **Vulnerability Type**: Excessive network exposure and failure to enforce least privilege **Risk Level**: Medium ### Vulnerable Code ```markdown **Connection refused**: Windows firewall blocking port. ```powershell # PowerShell (admin) New-NetFirewallRule -DisplayName "Obsidian REST API" -Direction Inbound -LocalPort 27124 -Protocol TCP -Action Allow ``` **SSL error**: Use `-k` flag (self-signed cert). **Vault not found**: Ensure vault is open in Obsidian. ## Windows Setup 1. Install `Local REST API` plugin in Obsidian 2. Enable "Bind to all interfaces" in plugin settings 3. Allow port in Windows firewall 4. Generate API key ``` ### Technical Analysis The Skill directs users to bind the Obsidian REST API service to all interfaces and creates a Windows Firewall rule that allows inbound TCP traffic to port `27124` without restricting remote addresses, interface types, or network profiles. This configuration exposes a privileged local-management API to any host that can route to the Windows system and is permitted by surrounding network controls. It exceeds the access needed for a WSL-to-Windows workflow, which generally requires access only from the local WSL environment or a narrowly defined virtual subnet. The API supports sensitive and destructive operations. Although bearer authentication is required, broad service exposure increases the consequences of key disclosure and expands the attack surface of the REST API plugin itself. ### Attack Path 1. The user enables “Bind to all interfaces.” 2. The unrestricted inbound firewall rule opens TCP port `27124`. 3. A host on a reachable local, corporate, virtual, or other connected network scans the Windows host and identifies the exposed service. 4. The attacker obtains the bearer key through plaintext workspace access, TLS interception, accidental disclosure, or another compromise. ...[truncated 874 chars]
• Remediation: ## Remediation Suggestions 1. Do not bind the REST API to all interfaces unless there is a documented and reviewed requirement. 2. Bind to loopback or the specific interface required for communication from WSL. 3. Restrict the Windows Firewall rule to the required WSL source address or virtual subnet and appropriate network profile. 4. Specify the local address and remote address explicitly. A hardened rule should follow this pattern, with environment-specific values: ```powershell New-NetFirewallRule ` -DisplayName "Obsidian REST API from WSL only" ` -Direction Inbound ` -Protocol TCP ` -LocalPort 27124 ` -LocalAddress <required-interface-address> ` -RemoteAddress <trusted-WSL-address-or-subnet> ` -Profile Private ` -Action Allow ``` 5. Use an authenticated SSH tunnel, VPN, or another protected transport when genuine remote access is necessary. 6. Block access from public and untrusted network profiles. 7. Regularly review listening interfaces and firewall rules, and remove the rule when the integration is not in use. 8. Combine network restrictions with verified TLS, protected secret storage, and API-key rotation; network filtering must not replace authentication.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (21)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

KEY=$(grep 'API Key' ~/.openclaw/workspace/TOOLS.md | awk -F': ' '{print $2}')

# Test connection
curl -k -H "Authorization: Bearer $KEY" "$URL/"

# List vault files
curl -k -H "Authorization: Bearer $KEY" "$URL/vault/"

• Confidence: 88% confidence
• Finding: The skill constructs `curl` invocations from values scraped out of `TOOLS.md` and uses them directly as URL and bearer-token parameters, creating a broad execution primitive around an external network tool. If `TOOLS.md` is modified maliciously or unexpectedly, the agent could be induced to send credentials to an attacker-controlled endpoint or perform unintended authenticated requests, especially combined with disabled TLS verification.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example - Create file:**
```bash
curl -k -X PUT \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: text/markdown" \
  -d "# Title\nContent" \

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example:**
```bash
curl -k -H "Authorization: Bearer $KEY" "$URL/vault/"
curl -k -H "Authorization: Bearer $KEY" "$URL/vault/daily/"
```

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example - Get active file:**
```bash
curl -k -H "Authorization: Bearer $KEY" "$URL/active/"
```

---

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example - Get active file:**
```bash
curl -k -H "Authorization: Bearer $KEY" "$URL/active/"
```

---

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example - Get active file:**
```bash
curl -k -H "Authorization: Bearer $KEY" "$URL/active/"
```

---

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example - Get today's daily note:**
```bash
curl -k -H "Authorization: Bearer $KEY" "$URL/periodic/daily/"
```

**Example - Get specific date:**

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Simple search example:**
```bash
curl -k -X POST -H "Authorization: Bearer $KEY" \
  "$URL/search/simple/?query=meeting"
```

• Confidence: 60% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**Example - List commands:**
```bash
curl -k -H "Authorization: Bearer $KEY" "$URL/commands/"
```

**Example - Execute command:**

• Confidence: 86% confidence
• Finding: The commands endpoint allows listing and executing Obsidian command IDs, including UI and file-affecting actions, without any warning that exposing arbitrary command execution to an agent can significantly expand its authority. In this skill context, remote operation of a local desktop application makes unrestricted command invocation more dangerous because a consuming agent could trigger unintended actions beyond note editing.

Context-Inappropriate Capability

Medium

• Confidence: 92% confidence
• Finding: The skill directs the agent to discover the Windows host IP by reading WSL resolver configuration, which expands behavior beyond simple note operations into host environment reconnaissance. While limited in scope, it normalizes collecting network topology details and could expose infrastructure information or be repurposed in contexts where host discovery is not necessary or expected.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The skill instructs storing the Obsidian API key in plaintext in `TOOLS.md`, a general workspace file that may be readable by other tools, agents, logs, backups, or version control. This creates a straightforward credential exposure path that would let anyone with access to that file authenticate to the Obsidian REST API and access or modify vault contents.

External Transmission

Medium

• Category: Data Exfiltration

Content

KEY=$(grep 'API Key' ~/.openclaw/workspace/TOOLS.md | awk -F': ' '{print $2}')

# Test connection
curl -k -H "Authorization: Bearer $KEY" "$URL/"

# List vault files
curl -k -H "Authorization: Bearer $KEY" "$URL/vault/"

• Confidence: 94% confidence
• Finding: The skill sends an authorization bearer token and vault operations over HTTPS while explicitly disabling certificate validation with `curl -k`. This makes the connection vulnerable to man-in-the-middle interception on the local or surrounding network, allowing theft of the API key and tampering with note data or command responses.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: The documented `/commands/` capability allows invoking arbitrary Obsidian commands, which is materially broader than the skill description of reading, writing, and searching notes. Depending on installed plugins and command bindings, this can trigger unexpected actions, data modification, plugin behavior, or further automation beyond the user's intended scope.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The documentation instructs users to use curl with -k, which disables TLS certificate verification and permits man-in-the-middle interception or impersonation of the Obsidian API endpoint. Because the same examples also use bearer-token authentication, an attacker on the network could capture the token and read or modify notes through the API.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This markdown reference documents `DELETE /vault/{filename}` as a normal operation but does not include any warning that it permanently removes user note data. Under the markdown-specific SQP-2 criteria, destructive behaviors that affect user data should be accompanied by a warning about impact or irreversibility.

External Transmission

Medium

• Category: Data Exfiltration

Content

**Example - Create file:**
```bash
curl -k -X PUT \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: text/markdown" \
  -d "# Title\nContent" \

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The reference includes `DELETE /active/` for deleting the currently open file, but the surrounding markdown does not warn that this can remove user data from the active note. The omission is material because the action affects live user content and may be irreversible from the API user's perspective.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The Periodic Notes section documents DELETE endpoints for current and dated notes without any disclosure that these operations can delete existing journal or schedule content. Markdown skill documentation should warn users when documented behavior may impact stored data or system integrity.

External Transmission

Medium

• Category: Data Exfiltration

Content

**Simple search example:**
```bash
curl -k -X POST -H "Authorization: Bearer $KEY" \
  "$URL/search/simple/?query=meeting"
```

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Natural-Language Policy Violations

Low

• Confidence: 82% confidence
• Finding: The documented configuration format uses the label 'API 端点' while the rest of the skill is in English, effectively imposing a locale-specific term on users. There is no opt-in, alternative English format, or explanation that this locale choice is required.

Missing User Warnings

Low

• Confidence: 87% confidence
• Finding: The markdown provides direct examples for creating, updating, and appending to notes, which modify user data. It lacks a clear user-facing warning that these actions change vault contents and may overwrite or append to existing notes.

Static analysis

No suspicious patterns detected.