# Path Traversal - llama_index ObsidianReader Hardlink Staging

- **Severity:** High
- **Signature ID:** `7f3c2a94-1d6e-4b58-9a27-0c8d5e41b3f2`
- **OWASP:** LLM02 (Sensitive Information Disclosure)

## Summary

An application that uses the llama_index ObsidianReader to pull notes from an Obsidian vault into an AI's context can be tricked into reading files outside the vault. An attacker plants a hardlink or symlink inside the vault that actually points to a sensitive file like /etc/passwd or an SSH key, and the reader dereferences it, feeding the secret's contents into the LLM.

## How the attack works

First, the attacker creates a hardlink or symlink (using ln, link, cp -l, or os.link()) inside the Obsidian vault that names a sensitive file such as /etc/passwd, an SSH key, AWS credentials, or a Kubernetes config as its target. Second, the ObsidianReader's load_data() function is invoked to scan the vault, and because it does not check whether a note is a real file or a link, it follows the link and reads the linked file's contents. The command line invoking the reader may also show directory-traversal sequences or a sensitive absolute path passed as an argument. The actual leaked content then appears in the AI's context, which is a separate, later step not covered here.

## Why it matters

Credentials, SSH keys, cloud secrets, or other sensitive system files can end up inside an AI application's context window, where they may be exposed in responses, logs, or downstream processing.

## What you can do

- Run vault-reading agents with a restricted filesystem view (chroot, container, or dedicated low-privilege user) so linked files outside the vault cannot resolve to sensitive paths.
- Before ingesting vault content, check for and reject symlinks and hardlinks, or resolve real paths and confirm they stay inside the vault directory.
- Audit existing vaults for links pointing to system credential paths (/etc/passwd, ~/.ssh, ~/.aws, ~/.kube, .netrc, .git-credentials).
- Treat legitimate uses of dotfile managers or backup scripts that link real config files into vaults as expected activity, but verify the link targets are not credential files before allowing ingestion.

## Known benign look-alikes

- Dotfile managers (GNU Stow, chezmoi, yadm) or personal sync scripts that link a real configuration file such as ~/.env or ~/.ssh/config into a markdown notes vault so it can be documented in place.
- Backup, migration or system-inventory scripts that hardlink /etc configuration snapshots into a documentation directory that happens to contain .md files.
- Security research, CTF and CVE regression harnesses that intentionally reproduce the ObsidianReader hardlink traversal against a scratch vault - these are true detections of the technique and require analyst context to dismiss.
- Developer shells searching documentation that mentions both /etc/passwd and a .md file in the same command line (suppressed by filter_doc_search).
- Reading `ln`/`cp` help or manual output while writing such a script (suppressed by filter_help and filter_manpage).

## References

- https://cwe.mitre.org/data/definitions/59.html
- https://cwe.mitre.org/data/definitions/22.html
- https://owasp.org/Top10/A01_2021-Broken_Access_Control/

---
Source: https://www.netzilo.com/threats/obsidian-reader-hardlink-traversal