What is GHSA-62GX-5Q78-WRVX?

GHSA-62GX-5Q78-WRVX is a high-severity path traversal vulnerability in obsidian-local-rest-api (npm), affecting versions < 4.1.3. No fixed version is listed yet. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.

How severe is GHSA-62GX-5Q78-WRVX?

GHSA-62GX-5Q78-WRVX has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.

Which versions of obsidian-local-rest-api are affected by GHSA-62GX-5Q78-WRVX?

obsidian-local-rest-api (npm) versions < 4.1.3 is affected.

Is there a fix for GHSA-62GX-5Q78-WRVX?

No fixed version is listed for GHSA-62GX-5Q78-WRVX yet. Monitor the advisory for updates and apply mitigations in the interim.

Is GHSA-62GX-5Q78-WRVX exploitable, and should I be worried?

Whether GHSA-62GX-5Q78-WRVX 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.

What actually determines whether GHSA-62GX-5Q78-WRVX 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.

GHSA-62GX-5Q78-WRVX in obsidian-local-rest-api

Q: How severe is GHSA-62GX-5Q78-WRVX?

GHSA-62GX-5Q78-WRVX has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.

Q: Which versions of obsidian-local-rest-api are affected by GHSA-62GX-5Q78-WRVX?

obsidian-local-rest-api (npm) versions < 4.1.3 is affected.

Q: Is there a fix for GHSA-62GX-5Q78-WRVX?

No fixed version is listed for GHSA-62GX-5Q78-WRVX yet. Monitor the advisory for updates and apply mitigations in the interim.

Q: Is GHSA-62GX-5Q78-WRVX exploitable, and should I be worried?

Whether GHSA-62GX-5Q78-WRVX 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.

Q: What actually determines whether GHSA-62GX-5Q78-WRVX 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.

Q: How do I fix GHSA-62GX-5Q78-WRVX?

No fixed version is listed yet. In the interim: Resolve the canonical path after applying any user-supplied input, and verify it remains within the intended directory before accessing it.

Summary

obsidian-local-rest-api: Authenticated path traversal via URL-encoded %2F in /vault/{path}, arbitrary host file read/write/delete

The Local REST API's /vault/{path} endpoints (GET/PUT/PATCH/POST/DELETE) percent-decode the request path inside the handler, after Express has already routed and normalized it, then hand it to the Obsidian vault adapter with no confinement check. A literal ../ is resolved/rejected at the routing layer (→ 404), but %2F is not a separator there, so ..%2F..%2F survives routing and is only turned into a real / by the handler's decodeURIComponent, reconstituting a ../ traversal that walks out of the vault. An authenticated client can read, write, or delete arbitrary files on the host with the Obsidian process's privileges.

Details

Framework: Express (import express from "express"; routes registered via this.api.route("/vault/*")…).

The vulnerable line, in src/requestHandler.ts, every vault handler (vaultGet, vaultPut, vaultPatch, vaultPost, vaultDelete) derives the path like this:

const rawPath = decodeURIComponent(
  req.path.slice(req.path.indexOf("/", 1) + 1),
);

The path is decodeURIComponent'd after Express routing. A literal ../ is collapsed/rejected at the routing layer, but %2F isn't a separator there, so ..%2F..%2F reaches the handler intact and this decodeURIComponent turns it into a real ../../. The string routing saw (…%2F…) is not the string the handler uses (…/…), and %2e%2e behaves the same way.

No confinement on the decoded path. The handlers pass rawPath straight to the vault adapter, e.g. this.app.vault.adapter.readBinary(filePath) / this.app.vault.getAbstractFileByPath(filePath), with no path.resolve + vault-root prefix check, so the reconstituted ../../ escapes.

The fix already exists in your code, for MOVE only. vaultMove confines correctly:

const syntheticRoot = "/vault";
const resolved = posix.resolve(syntheticRoot, normalized);
if (resolved !== syntheticRoot && !resolved.startsWith(syntheticRoot + "/")) {
  this.returnCannedResponse(res, { errorCode: ErrorCode.PathTraversalNotAllowed });
  return;
}

GET/PUT/PATCH/POST/DELETE lack this guard. Apply the same posix.resolve(syntheticRoot, …) + startsWith check to the decoded path in every vault handler, and reject any segment that decodes to ...

PoC

Prereq: a running Obsidian with the Local REST API plugin enabled and its configured API key ($API_KEY). Targets below are Unix; adjust per OS (e.g. ..%2F..%2FWindows%2Fwin.ini on Windows).

# READ outside the vault (returns 200 + the target file's real bytes):
curl --path-as-is -k -H "Authorization: Bearer $API_KEY" \
  "https://127.0.0.1:27124/vault/..%2F..%2F..%2F..%2Fetc%2Fpasswd"

# WRITE outside the vault (creates a file on disk outside the vault root):
curl --path-as-is -k -X PUT -H "Authorization: Bearer $API_KEY" --data "pwned" \
  "https://127.0.0.1:27124/vault/..%2F..%2F..%2Ftmp%2Fcanary.txt"

--path-as-is stops curl from collapsing .. client-side. A plain ../ (unencoded) request returns 404, only the %2F/%2e%2e encoded form bypasses, confirming the decode-after-routing gap.

Impact

Authenticated arbitrary file read / write / delete outside the Obsidian vault, with the OS privileges of the Obsidian process, typically the user's home directory (SSH keys, browser profiles, dotfiles, credentials). Amplified in MCP/LLM-agent deployments: this API is widely used as an MCP server, so a prompt-injection in vault content (or a malicious MCP client) can make an agent emit a %2F path, turning "the agent can edit my notes" into "the agent can read/write any file on the host," with no user intent to grant filesystem access beyond the vault.

This vulnerability was reported by Caleb Brisbin through responsible disclosure.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

GHSA-62GX-5Q78-WRVX has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Affected versions

obsidian-local-rest-api (< 4.1.3)

Security releases

Not available

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 environment New to Kodem? Get a demo →

Remediation advice

No fixed version is listed for GHSA-62GX-5Q78-WRVX yet.

In the interim: Resolve the canonical path after applying any user-supplied input, and verify it remains within the intended directory before accessing it.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

What is GHSA-62GX-5Q78-WRVX? GHSA-62GX-5Q78-WRVX is a high-severity path traversal vulnerability in obsidian-local-rest-api (npm), affecting versions < 4.1.3. No fixed version is listed yet. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
How severe is GHSA-62GX-5Q78-WRVX? GHSA-62GX-5Q78-WRVX has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
Which versions of obsidian-local-rest-api are affected by GHSA-62GX-5Q78-WRVX? obsidian-local-rest-api (npm) versions < 4.1.3 is affected.
Is there a fix for GHSA-62GX-5Q78-WRVX? No fixed version is listed for GHSA-62GX-5Q78-WRVX yet. Monitor the advisory for updates and apply mitigations in the interim.
Is GHSA-62GX-5Q78-WRVX exploitable, and should I be worried? Whether GHSA-62GX-5Q78-WRVX 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 GHSA-62GX-5Q78-WRVX 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 GHSA-62GX-5Q78-WRVX? No fixed version is listed yet. In the interim: Resolve the canonical path after applying any user-supplied input, and verify it remains within the intended directory before accessing it.