Comment by kepano
3 days ago
Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it.
That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I haven't seen any reports of users being affected by this attack.
lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little too late.
The insecurity is part of the benefit. Obsidian being so open, allowing easy customizing is what makes it great. They should add some more bells, whistles and guards to prevent sneaky social attacks, but they can't close Obsidian all together, or it would kill the app.
There's open, and then there's "full disk access, even outside the vault" open.
2 replies →
You better delete all third-party applications for they are having full disk access.
Hello, 2010s called.
In 2026, applications, third or even first party, don't need to have full-disk access, and are not given either. They see a jailroot environment. I give full disk access to the terminal app, and a handful of others. 90% of them, nope.
At least that's the case in macOS, I'm pretty sure Windows can do that too. Linux of course has had such capability since forever, but I guess most distros you need to manually take care of it.
22 replies →
These types of problems usually only get fixed when it’s too late.
"Sorry we got caught" reactiveness.
1 reply →
Lol it's a social engineering attack. What are you talking about. Don't run programs you don't trust, especially when being asked to do so by strangers on the line.
[dead]
Obsidian is great. And glad to see how you’re looking at plugin security. But one more thing you should consider is: How do you reduce the need for plugins for basic product behavior. E.g., I use a plugin to be able to open a file in new tab instead of replacing current tab. That should be a setting, not a plugin I’m forced to use.
I agree. https://news.ycombinator.com/item?id=48097206
I don't understand the hate here. Obsidian is a well working product that scratches many inches. Plugins allow to scratch some more itches, but are not mandatory.
I am using several plugins and would prefer not to, but they allow me to bring the (mobile) app closer to what I want (notably templater and homepage as I want to get a new daily note sorted in monthly folders, which obsidian doesn't seem to allow natively).
Maybe an alternative would also be to more explicitly allow users to create their own scripts - but maybe that's possible and I just don't know.
Overall I think the key challenge with obsidian use is that it offers too much, and there's a lot to fiddle with. While it will bother the power users probably best would be to just move on many ways to "default" behaviours and e.g. make many of the "core plugins" just settings to make the list lsss overwhelming.
I don't know how hard it would be but IMHO adding some kind of permissions dialog(?) akin to Android would go a long way. 99% of Obsidian plugins don't need full disk access, or internet access for that matter.
That'd require some sort of sandbox, which they already seem to not want to have, for whatever reason. If you don't want that, and you want to use JS, building any sort of permission system on top of that that you cannot easily work around, gets really tricky if not impossible.
Obsidian stands beside the terminal and Firefox as one of the pieces of software I use the most every single day. Thank you for all you're doing.
-
I've read the article describing the attack, and my very first thought was utter surprise that the entire attack chain started with someone accepting a shared vault from a stranger via social media (linked in and similar). That seems really, really strange to me.
I've never shared a vault - but if I did, I'd probably do so as a git repo of markdown files.
It would be interesting to see a blog post from Obsidian about "good hygiene for sharing vaults".
An update:
https://obsidian.md/blog/future-of-plugins/
Your product rules. Thanks.
Will that new security interfere with plugin functionality though? I can't really do without some of them, in particular selfhosted-livesync. It's not even that I don't want to pay you for hosting my notes, it's that I don't want them on somebody else's server even end to end encrypted. If I could pay and run my own official sync server I probably would.
Will there finally be an option to move the .obsidian-folder outside the vault and ignore them inside vaults by default even if plugins are activated?
> actively reject multiple safety warnings
Is this like a popup? which most people actively accept without blinking
I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.
It's not one pop-up. To fully replicate the concept you have to agree on three separate screens (and these are not in quick succession):
1. exit restricted mode to allow third-party plugins
2. trust the author of the vault that's being shared with you
3. trust the plugins being shared with you via sync
The pop-ups and "social engineering" in question are things that any users in HN likely already accepted, which is to enable community plugins. These community plugins are the backbone of Obsidian and where a lot of the meat is behind its fame come from.
There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.
I'm gonna push back against the "backbone of Obsidian" part. I'll argue that vanilla Obsidian is plenty powerful enough.
I know many people swore / swear by the datatables plugin, but now that Bases in core, you can get pretty far without it, no?
2 replies →
As someone who doesn't use shared vaults - would the warning popup, 'to enable the "Installed community plugins" synchronization feature', not be on a per shared vault basis? Is trusting a single shared vault for plugin sync going to mean I sync my plugins for every shared vault?
IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.
This. Make it like a vim mode, input “I know what I’m doing” or even require some basic fizz buzz.
I've been using obsidian for years as a paying customer. Will continue to pay as price point is good and it just works. However, unless plugin security massively improves I will never install any plugins.
Obsidian is only seven people but we are working on this from all three angles:
1. Make community plugins less necessary over time as basic features become part of core
2. Improve the security of community plugins
3. Make it easy to create your own plugins that you can fully trust, e.g. with the recent release of Obsidian CLI
If you can build in one thing, I'd pick something equivalent to Omnisearch. That makes it much easier to find things. I always struggle with the default search.
1 reply →
Releasing the source code to the clients would also address many of our concerns.
How would that make a difference for plugin security? Almost all plugins are already open source.
If you mean for the security of the app without plugins you can currently inspect the app's code in app.js and review third-party audits:
https://obsidian.md/security
[flagged]
7 replies →
you’re basically hijacking this post. this is almost entirely irrelevant. CERTAINLY highly tangential.
LMAO. That won't happen in a million years. They are bending over backwards not to give proper file access on iOS so they can sell subscriptions. Do you think they would do such a crazy thing? I bet you my life savings it won't happen.
They are being roasted in the comments because they give file access to the plugins, now they are bad because they don't give file access. There is no winning lmao
1 reply →
> multiple safety warnings in Obsidian
Idk, I've always thought it was odd that the "community plugins" settings pane seemed more concerned with assuring the user that community plugins were fine than actually explaining the risk.
There is literally a single sentence about the fact that plugins "may cause data integrity and security issues", and it is hedged with the mealy-mouthed modifier "like any other software you install". The absolute majority of it - maybe 80% of the text by window height - is about the measures Obsidian does to vet and secure plugins. All of it appears to be written with the intent to placate any concerns.
Is this the safety warning? The screen that says that community plugins could cause issues "like any other software", but they're actually super safe and vetted and totally fine? Is it surprising that a person, faced with a screen like this, would be susceptible to a social engineering attack?
To replicate this attack you have to also reject two more safety warnings. The user has to accept a shared vault (you have to click "trust author of this vault"), and you have to activate syncing remote plugins.
The first safety warning assures the user that "plugin security is important to [Obsidian]". That Obsidian plugins undergo initial code review by Obsidian themselves. That "many" plugins are open source and that Obsidian has a "large community of developers who watch out for each other". (At this point I'm not sure how this screen even qualifies as a safety warning. Seems more like a billboard for enabling plugins?)
Given that vaults are just Markdown documents, and plugins are so safe (or so Obsidian seems to claim), why should a person feel at all concerned clicking yes to these prompts? Is it still a social engineering attack when the app appears to encourage you along the way? Are these even safety warnings, or just (vaguely encouraging) confirmation dialogs?
I don't see how Obsidian should come off as completely blameless here. They've always tacitly encouraged this wild west plugin ecosystem, because it's an obvious generator of value. They don't get to absolve themselves of any responsibility by pointing at safety warnings, when those "safety warnings" spend (far!) more time explaining why the user might want to click "yes" than "no".
To be clear, I like and use (and pay for!) Obsidian. But the design of Obsidian plugins was clearly broken from the beginning, and the official messaging around them has always been more encouraging than wary. This sort of event is an absolutely inevitable consequence of those decisions.
1 reply →
Get real, kepano. You’re overestimating the consciousness of most casual users. Having godmode, RCE-capable plug-ins behind few safety warnings that most people will happily ignore to get shit done is not good engineering. I understand the constraints. In your shoes I would at minimum make a different version of the app in which you could allow these plug-ins and not put them under trivial banners within the canonical version of the app. You say you have banners, but these sit in the natural flow of the user journey, the options are clearly available and these banners are merely to exempt you from any liability, not to protect the users.
Chrome gutted extension capabilities for safety and now it is so useless, politically unwanted extensions have "lite" versions and every big project and their dog ship their own chromium browser.
I use Obsidian because it does not treat me like a child. They can add more nags and banners for normies, but the capabilities should remain.
I have to agree. You can keep pulling that logic back another step (and that seems to have been happening for many steps now) to the point that you no longer have the ability to use the computer.
This can't be dismissed as "slippery slope" logic either. Should elderly people with a bank account be allowed to use a computer? They might read something online and give their savings to a scammer. Frankly, that's a far more convincing argument than the one given here. There's only one solution if your objective function is exclusively to minimize the possibility of a security incident.
[flagged]
2 replies →
Since we have your attention here, let me go on an unrelated note and ask whether you could look into Noteplan's workflow and see if you can add some of the required functionalities to enable replication of its workflow (https://help.noteplan.co/article/160-weekly-planning)?
Plugins like Tasks do offer a Query functionality that allows me to list e.g. weekly tasks on my daily template, replicating most of Noteplan's workflow, except Noteplan relies on being able to easily link those tasks into daily template by drag and dropping them, which internally assigns a unique but hidden by default ID in ^129abz notation (https://help.noteplan.co/article/138-synced-blocks). The latter is already supported by Obsidian, it's just not as "clean" and, AFAIK, impossible to get done when drag and dropping.