Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

141–150 of 241 posts

Re: Obsidian plugin was abused to deploy a remote access trojan

#141
post #94

Earlier quoted context omitted.

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…

Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.

Maybe it isn't built-in, but most Windows user I've worked with, including myself, have been using Sandboxie for probably two decades at this point, probably hard to find any Windows software that is more ubiquitous than Sandboxie in developer circles.

Re: Obsidian plugin was abused to deploy a remote access trojan

#142

Why the hell doesn't the article say WHICH plugins were affected so users can know if they were likely affected?

The specific plugins don't matter for this attack. The attack relies on the user accepting a shared vault and trusting the shared plugins. A shared vault can contain plugins that don't come from the official directory.

Re: Obsidian plugin was abused to deploy a remote access trojan

#143
post #49

Earlier quoted context omitted.

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]

"Oh, please, say you want to keep it closed source because you're afraid you'll lose money and control."

That's not good enough for open source zealots. That's when you end up being the headliner in an endless flood of blog posts and detailing comments telling everyone you're a 'proprietary evil man'. It's open source or nothing. And how dare you make money.

Re: Obsidian plugin was abused to deploy a remote access trojan

#144

A long time ago I figured that "nasty Obsidian plugins" were not a matter of if, but when . So I did the (imho) only sensible thing, and run Obsidian in a sandbox (bwrap). By doing so, I also made sure it runs in a separate networking namespace. For now, I disallow any internet access. The amount of rage I see here is a bit strange, the whole attraction of Obsidian is that you can turn it into a Swiss army knife (tha…

> So I did the (imho) only sensible thing, and run Obsidian in a sandbox (bwrap). By doing so, I also made sure it runs in a separate networking namespace. For now, I disallow any internet access.

> The amount of rage I see here is a bit strange

Serious question: do you think it is actually obvious and technically accessable to everyday people to have the thought "I should run this in a sandbox" and do it?

Like no this is not some super elite haxxr tool, it's a text editor pretty explicitly advertised as being non-technical-person-friendly.

Re: Obsidian plugin was abused to deploy a remote access trojan

#145
post #43

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 ha…

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?

Re: Obsidian plugin was abused to deploy a remote access trojan

#146
post #49

Earlier quoted context omitted.

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]

This is pearl clutching. This feels like a massive overreaction. If you don't want to use it because it's not open source, that's fine, but you're spreading a lot of snarky FUD about the creators.

They are not making excuses, they stated clearly why open sourcing it is tangential to this problem at best, and they're not the only user to call out the hijacking of the thread. They have been quite clear about why they keep it closed source, so I don't know why you're making it sound like they are lying to their users.

Your rant about audits has little to do with the article too. Telling everyone we're going to get rug pulled is exactly the kind of performative FUD that is meant to get a reaction more than anything.

Speaking for myself, I'm going to keep using it, because nothing has come close to the convenience and performance. Would love an open source alternative to prove me wrong, but I haven't seen it.

Re: Obsidian plugin was abused to deploy a remote access trojan

#147

Earlier quoted context omitted.

I've never tried to do this or similar in Windows (obviously easy in unix-like environments) but I'm going to bet it's far more trouble than it's worth for 99% of users

On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.

Does that help in this case though? I think the worry is that a rogue Obsidian plugin does bad stuff with your Obsidian vault, not just do stuff to the rest of the computer. But that vault/those notes live in the same sandbox as the (rogue) 3rd party plugin, which doesn't help with that, they really need to be isolated away from the notes themselves.

Re: Obsidian plugin was abused to deploy a remote access trojan

#148
post #44
post #43

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 ha…

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.

Re: Obsidian plugin was abused to deploy a remote access trojan

#149
post #94

Earlier quoted context omitted.

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…

Yes you can sandbox Obsidian on the OS. The point they're making is nearly every third party program ships Without sandboxing. There's nothing special about Obsidian here.

Re: Obsidian plugin was abused to deploy a remote access trojan

#150
post #9

Earlier quoted context omitted.

That's horse hockey. Obsidian is not a usable system without community plugins. Folks will reply "but I use it every day without plugins". That position disregards software usability as a formal discipline, along with decades of UX research and standards.

> Obsidian is not a usable system without community plugins. It's horse hockey. Plenty users use the vanilla Obsidian. > Folks will reply "but I use it every day without plugins". Because they do. You're saying that they should lie about their usage to fit your narrative?

> Plenty users use the vanilla Obsidian.

They are irrelevant for this dispute, because these problems do not concern them. And the amount of people using plugins because of some real demand is not low.

Post reply on HN