Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

121–130 of 241 posts

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

#121
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…

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

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

#122
post #9

Earlier quoted context omitted.

It does give full access but Obsidian does tell you that. Community plugins are not enabled by default, you have to enable them manually. Same happens with a shared vault: once you get it you still have to manually enable plugins. So far no one managed to sneak in a plugin completely unnoticed.

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?

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

#123
post #49

Earlier quoted context omitted.

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]

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

#124
post #60

What are the reasons behind the fact that almost all of these plugin systems are so poorly engineered? Is it too much work (ie, there are no good plugin development frameworks that already enable proper isolation/permission capabilities) or "simply" a widespread lack of knowledge of what is needed, so devs learn only after their own system has been abused? Both? Something else?

Web stack plus lack of resources to architect the proper interfaces is my guess. These are software written in high level js frameworks, thus using poor dataflow patterns by default, mostly just following what is actually possible instead of employing intentional design, which would require going down some levels of abstraction and maintaining a custom fork of said frameworks. So they probably just architect plug-ins…

"Worse is better" remains relevant as ever.

https://www.jwz.org/doc/worse-is-better.html

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

#125
post #81

Earlier quoted context omitted.

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.

[flagged]

Whoa there, am I missing something, why so aggressive and immediately with the ad homs?

I think by that logic dangerously-skip-permissions and openclaw should've never been a thing. I agree that people use them too liberally, but I think at some point you have to find a balance between systemic safety risks and individual freedom.

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

#126

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.

For real security, operation should only be allowed after 24h of cooldown.

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

#127

Yet another reason to not install anything third-party made. Favor batteries, built-in functionality and reject “Unix philosophy” or whatever bullshit people use to ship incomplete software under guise of.

I'd ideally want Obsidian to be a distro package, including any good plugins. No plugins from the "store".

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

#128
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.

AppContainer (e.g. used in uwp or msix)

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

#129
Love Obsidian but I've previously commented about the security model for plugins here: https://news.ycombinator.com/item?id=45308131. TLDR: your entire vault (and possibly filesystem) is exposed to every single plugin you install.

I really do think Obsidian needs 2 things to have any reasonable security:

1. It needs to be a lot more batteries-included. A user shouldn't need a plugin for basic functionality.

2. It needs a granular permission system, where each plugin should have to declare and prompt you to allow or reject specific permissions, just like on iOS and Android. The system should enforce that a plugin cannot bypass this.

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

#130
post #4

> The victim is prompted to enable the "Installed community plugins" synchronization feature. Obsidian has the proper protections in place to prevent this type of attack, and the victims are being convinced to ignore them. This is just a successful social engineering event. I hate to see Obsidian dragged down by this headline, since this attack is not exploiting a vulnerability in it or its plugin system.

Ehm. No? https://obsidian.md/help/plugin-security#Plugin+capabilities > Due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels. This means that plugins will inherit Obsidian's access levels. As a result, consider the following examples of what community plugins can do: Community plugins can access files on your computer. Community plugins can connect to intern…

> Community plugins can access files on your computer. Community plugins can connect to internet. Community plugins can install additional programs.

That's what make obsidian plugins useful. It it's just for having themes , there is no need for them

Post reply on HN