Obsidian may create folders outside of the Vault when using relative path mode and ../

Bug reports
,
1

Steps to reproduce

  1. Create a Vault, for example, at C:/Work/MyVault/
  2. Create a note, give it any name, and in the contents of this file, enter the following link (note at this link should not exist, and the folders in the path C:/Work/MyPrivateInfo/MyFolder/ do NOT currently exist):
    [[../MyPrivateInfo/MyFolder/Homepage|Homepage]]
  3. Then click this link.

Did you follow the troubleshooting guide? [Y/N]

Yes, the bug also occurs in sandbox mode. As a result, folders are created and remain in C:\Users\username\AppData\Roaming\obsidian, even though they SHOULD NOT have been created there, much less persist after sandbox mode.

Expected result

Obsidian must indicate that the link leads outside the current Vault and prohibit the user from performing any actions within Obsidian outside the current Vault.
Obsidian MUST NOT create any folders or files outside the current Vault.

Actual result

The MyPrivateInfo folder is created OUTSIDE the current Vault (outside MyVault) - on path С:/Work/MyPrivateInfo/ - and other folders are created inside it (for example, MyFolder, as in the example - on path С:/Work/MyPrivateInfo/MyFolder/) if they are referenced. However, the .md file is not created in these folders.
Furthermore, I get the error “Cannot read properties of null (reading ‘getParentPrefix’)”, apparently because Obsidian couldn’t create the file outside the current Vault, but was able to create FOLDERS.
This is NOT expected behavior.

Environment

SYSTEM INFO:
Obsidian version: v1.11.5
Installer version: v1.8.7
Operating system: Windows 10 Pro 10.0.19045
Login status: not logged in
Language: ru
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none

Additional information

The most Obsidian should do in this case is ask whether the file should be created outside the Vault, since the link leads outside the current Vault.

2

Why this is critical for security:
If a malicious plugin exploits this vulnerability, it could discover which folders exist in the system (by monitoring notifications), affect folders across the entire system, or create its own folders, thereby disrupting system operation in certain ways.

This is also dangerous for server-based solutions, where Obsidian users should not have access outside of designated Vaults.

3

I agree that we may validate better this case.

However, I am going to disappoint you. The plugins don’t need to do that to discover which files are in the system. They can do it directly as they have the same level of access as Obsidian itself.

Continue here for plugin security: