Obsidian plugin was abused to deploy a remote access trojan(cyber.netsecops.io) |
Obsidian plugin was abused to deploy a remote access trojan(cyber.netsecops.io) |
E.g. this is how they criticise obsidian - suggesting that a default location backup is somehow worse than default cloud sync is just very strange to me.
Obsidian stores your data as a folder of plaintext files on your local computer. You are thus responsible for securing this folder and making it available on your other devices. This is particularly difficult on mobile platforms that lack access to a robust file system.
The issue is that this could happen to anyone who just searches the malicious plugin's name and installs it. Worse if it's a popular one that gets compromised.
It takes 5 minutes in their Discord channel to see the founders are D&D nerds, not competent engineers. It was never meant for serious work.
I know absolutely nothing about Obsidian but I'd expect quite a few competent engineers to also be D&D nerds no!?
Are you saying the two are mutually exclusive?
The two are not mutually exclusive. What would you trust more than a nerd? A jock? A spod? An MBA?
Any evidence of other examples if bad engineering you can point to, or are your thoughts on the pluggin system and throwing shade at random groups of people all you've got?
[FYI: I know little of obsidian other than planning to look into it at some point as people I know use and like it. I stepped into this set of comments in case there was something useful I should be passing on to those people]
Anyway, What I like about obsidian is that it can handle a truly huge amount of notes without slowing down, and the notes are just markdown files on disk, so there's no lock in. I have used evernote, ms one note and zoho notebook before, and had issues with all of them.
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.
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'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".
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.
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
There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.
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 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:
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?
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.
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.
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.
I have to imagine the Obsidian team is going to respond seriously to this and I look forward to seeing what they do. They have my full confidence. I'm surprised the system was initially designed as it is without those better permissions and sandboxing, though.
"Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT”
It’s novel (new), an abuse of Obsidian, specifically targeting a group of people.. and the RAT is embedded in the vault.
Personally it feels similar to being mad at Windows if you were to install an exe someone emailed you and it turned out to be a virus.
You can install bad chrome plugins, bad wow addons, basically anything that's purpose is to run user code can be used to run bad code.
Personally I'm glad the _note taking app_ prioritized allowing for custom plugins over pushing back features so they could spend an extra year locking down user plugins. They can put some additional effort in but running unknown code will always be a risk.
The fact that creating a good plugin system is difficult does not give them a free pass to not implement a good one, it is a for profit company that has a considerable revenue.
Maybe I just also have a higher personal risk appetite, but even as a dev and knowing these risks I would have enabled the community plugin option. Again, hope I'm just the minority here and not most user behaviour.
Also I can't tell how to prevent plugin updates. As long as you rely on a known safe version I guess there is never any real risk.
(I actually use LogSeq, but same idea applies).
A bad update to one of the popular plugins could compromise lot of systems.
Same way I run any other application that could potentially execute untrusted code.
> It enables malicious versions of legitimate Obsidian plugins ('Shell Commands' and 'Hider') that are present in the shared vault.
1. Plugins are stored inside your vault.
2. If you open a vault from an untrusted source, it could contain custom/malicious plugins that will run things on your computer.
3. Then end.
To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there.
Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could confirm or explain otherwise.
https://docs.github.com/en/actions/how-tos/secure-your-work/...
So would a user have to do some kind of `gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY ...`? (assuming the plugin dev provides an sbom?)
What I want from Obsidian is something that "just works". Adding third-party plugin would break this immediately since the plugins can either be straight up buggy, create conflicts with each other or simply become incompatible with new Obsidian releases.
And what I've seen from the community, with people having dozens of plugins installed, is giving me nightmares.
I can see why some would feel the appeal of plugins, and adding two or three can be fine, as long as you do your due diligence. Otherwise it's straight shooting you in the foot.
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 (that can hurt you too ofc).
@kepano: you would greatly help me if you could force plugin authors to list the urls they want to access inside the manifest, then let the user per url decide if they want to enable it. I still see some stupid plugin authors download their assets from a CDN or a vague website, from deeply buried in their code. Making url depencies explicit helps firewall automation at a first step. Maybe you could revoke direct network access from plugins, but i am not too knowledgeable about Electron.
> 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.
> 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?
You have a point though that non-technical people are screwed, but they have always been. Their whole lives and biometrics rest on Google and Apple servers anayways, while a good part of their identity is being traded by non-scrupulous commercial predators under the veil of advertising purposes. They are so beyond f*cked that I did not include their concerns wrt Obsidian plugins.
I say shiny horse statue.
It's so a distracting and unfocused
It’s sandboxed; can’t make network connections and can only read the directory you select. I’m surprised Apple haven’t added OS level functionality to block network connections / folder access for non sandboxed apps, similar to running an un-notarised binary.
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.
>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 internet.
Community plugins can install additional programs.
This was only a matter of time, and honestly I think it's inexcusably negligent that they shipped a plugin system like this at all since about 2010 (or arguably much earlier).
I agree with the claim of negligence. I think they were more than happy to reap the benefits of a thriving community plugin ecosystem, and were hoping this page would provide enough CYA when security breaches inevitably occurred.
> TIP: If you're working with sensitive data and wish to install a community plugin, we recommend that you perform an independent security audit on the plugin before using it.
I wonder just how many plugins received a security audit.
That's what make obsidian plugins useful. It it's just for having themes , there is no need for them
I think the value of this disclosure is more in spreading awareness about plugins, and demonstrating the vector. Where less sophisticated users may think, "Oh, this is just a collection of markdown files. I don't need to be too worried about malicious code."
The other problem is that security is hard, and just giving generic access and adding some basic guards is simple.
Much easier to just skip that part.
So yes, it’s too much work (in the sense that you need to have a security-focused leadership that understands that this is a lot of work but the right thing to do).
What functionality are you thinking of? I just looked and I've never enabled community plugins.
My Obsidian complaint is the opposite. I think its bloated well beyond the initial premise of a markdown editor over a directory of files. I think it was just about perfect right before the introduction of the Canvas feature.
Can I ask, what basic functionality is Obsidian missing in 2026? (I work on the app)
Here are some feature I wish existed in Obsidian without any plugins:
* Dataview [1] (this is now solved with Bases, so I really appreciate that)
* Folder Note [2] (I, and I assume many others come from Notion, and I wish this were a thing)
* Recent files [3]
* A built in calendar [4]
* Link embeds [5] (or something to store previews for pasted links)
* Waypoint [6], or something to create a table of contents
These are just things I wish existed, but whether or not these are 'basic' can be debated. Ultimately I do wish there were a robust permission system for plugins so that personal functionality gaps can be plugged, but without compromising safety.
References: [1] https://blacksmithgu.github.io/obsidian-dataview/ [2] https://github.com/xpgo/obsidian-folder-note-plugin [3] https://github.com/tgrosinger/recent-files-obsidian [4] https://github.com/liamcain/obsidian-calendar-plugin [5] https://github.com/Seraphli/obsidian-link-embed [6] https://github.com/IdreesInc/Waypoint
1) Basic functional search
Search should handle different order of words, misspellings (fuzziness), offer indexing and searching in a larger scope than just titles and aliases (e.g. headers or content), as well as allowing users to customize search priorities. Basically - just include Omnisearch as a core plugin.
2) Basic image preview
Displaying an image on full screen, with panning and zoom, when clicked upon.
3) Full "folder notes" support
Out-of-the-box support for a vault structure where each note has its own dedicated folder where all its attachments are placed. While the basic functionality is present, an external plugin is required to declutter the vault file hierarchy and actually make this approach feasible. Folder notes approach is in my opinion the only way to keep a large vault organized.
4) Basic formatting.
Text coloring. Text alignment and justification. Basic image positioning. Proper text flow wrapping around images. Table formatting (at least a setting minimum column width).
5) Markdown parsing within HTML tags
Basics Markdown features like [[linking]] don't work within a section of text enclosed by HTML tags. And using HTML/CSS is currently required to achieve basic formatting like centered or colored text.
6) Option to use the first h1 tag as the note title
I'm talking about actual support for this and integration with core functionality like search and linking. Useful (sometimes long) titles are an essential part of note-taking and knowledge databases. Meanwhile, filenames are simply semi-unique file system identifiers. Forcing users to use filenames as titles compromises the usefulness of titles and leads to issues with filename / filepath length. In HTML and Markdown, the h1 tag was always intended for the title.
7) Consistent formatting between reading view and editing view
Rendering of content, especially vertical spacing between elements differs between those views for no credible reason. The code syntax highlighter is also deficient in editing mode, despite it being the mode in which Obsidian users spend 99% of their time while writing, editing and reviewing notes.
It's not an exhaustive list, but these are the biggest pain points right now. And let me repeat - you shouldn't continue to rely on community plugins for these features. Even though community plugins are great, they are a security concern, their development could cease at any point, and new users don't know about them.
* Android's permissions model where the user must approve specific potentially undesirable classes of actions (separate from the 24H delay, etc controversy)
* Optional sandboxing
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.
I have a "system" base that I put on the ribbon. it defaults to "recently created", but I have a bunch of different views for hunting down anomalies too.
I know many people swore / swear by the datatables plugin, but now that Bases in core, you can get pretty far without it, no?
There's countless articles and videos about various community plugins and even curated selections of them depending on your use case for Obsidian.
IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.
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.
Yes it would be good to make it less easy to shoot yourself in the foot. However, I believe users should be in control. People should be able to do powerful things if they choose to. But that will always come with the risk of misuse or social engineering.
They're trying to get all the benefits while pushing the extremely-obvious-to-them downsides into subpages. Not hidden, but not shown along-side the feature. It's intentionally misleading for non-technical users.
I don't think they meant it this way, but I honestly consider unsafe official plugin systems to be negligent to the point of being actively malicious. By releasing one, if you ever become successful you have explicitly chosen to screw over an unknown number of your users to save yourself a relatively small amount of work in the short term. It might be single digit users, or it might be septuple digit users - is it really worth it?
(Unsafe unofficial plugins, like most games? Mildly unfortunate but I think that's fine. Though a healthy modding community around your stuff should be a VERY STRONG sign that you should introduce a safe version to protect your users, if it won't cause you to implode (it definitely can)).
And before you say it's useless and should be stopped too, well, that's a fine opinion! But then you lose plugins providing git integration, automated backups, document conversion using pandoc, etc. Many users might value that greatly.
A permission system for their plugins might be the only solution, annoying permission request popups and all.
0) scripts and plugins should only be able to operate on the text in the vault. Just like how I expect a snippet of JavaScript running in my browser to only have access to the website and not to my entire disk.
1) Any commands that run outside of this sandbox need to be approved first. Obviously this could get annoying, but there's tricks you could use here to help.
Obviously this is a high level approach and I'm not on their team, so this is basically armchair programming. But since you asked, it's okay. ;)
At some point we need to acknowledge the problem is cultural, and address accordingly. I realize that the business objective for many is to make computing as brainless as possible but we need to be pushing back on that.
Instead we have forums full of really smart people demanding a nanny state. Yuck -- what a sad and pathetic state of affairs.
Nothing happened, it never worked, and the more people got exposed to the internet, the more obvious it was, your personal RAT history notwithstanding. Post your own hygiene list in some security-related public forum and get some comments on how easy it is to circumvent it and/or how impossible it would be to comply with
> tons of successful plugin systems
The requirement here is secure, not generically successful. Tons of bad insecure systems get popular
> problem is cultural, and address accordingly
That's exactly what all those sandbox and permissions do - address the cultural problem of the impossibility of following a set of very stringent rules without a fault at an individual level when there are more than a few individuals
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.
Would love to enable this for all apps, and add exceptions for the ones that need more access.
I installed Lulu and BlockBlock recently, and want to do more to harden my Mac.
When an app tries to access something outside of its sandbox, you get a notification asking to approve or deny. Full Disk Access I think needs to be explicitly given on System Settings (Privacy & Security -> Full Disk Access).
I have no idea how to do that in Windows though.
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.
Because in general, "usable" means "people use it". Which they do for Obsidian without community plugins without issues.
Obsidian Plugins are still incredibly vulnerable. A compromised plugin will essentially take over your machine. There's no sandboxing of any kind. It's even more insecure than browser extensions (that could steal your auth tokens, but at least don't have unfettered access to your filesystem).
This is really unfortunate. I love Obsidian and am a paid subscriber for many years, but the community plugins needs a security overhaul asap, before someone gets hurt.
All I want is a top-notch Markdown editor with a mobile app and trustworthy sync, and that's what Obsidian gives me. And if ever Obsidian goes away or is enshittified, I'll still have a perfectly good folder of Markdown documents that I can take elsewhere.
I really don't want my notes on other people's servers so the official sync will never be an option unless they enable that to be self hosted as an option.
Seriously though, I agree with your sentiment that community plugin security can and needs to be improved, but how does someone saying they use it every day "disregard software usability as a formal discipline, along with decades of UX research and standards"
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?
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.
This combination of software relying on third parties without security seems to be untenable. Personally I've gotten rid of just about as many extensions as I can anywhere and switched to batteries included software.
If you install a dozen mini-apps from random developers you never heard about, you can't complain if one is malware.
Krita also has a plugin system based on Python. Any "plugin" has the same level of access as running a python script.
Personally I blame operating systems for not providing a way to isolate how programs interact with user files.
There are of course complications, costs, and downsides associated with doing that. It might not be worth it currently, or performance costs might be too high, or the community might be overwhelmingly using abandoned plugins that won't be updated, etc. It's still a decision to remain complacent until forced by attacks though, it's well beyond common knowledge that these things happen so you can't really call it ignorance.
WoW's whole UI is built in the same Lua environment as add-ons, and Blizzard has implemented some interesting restrictions (like the taint system[0]) to prevent add-ons from completely automating gameplay.
0. https://wowpedia.fandom.com/wiki/Secure_Execution_and_Tainti...
If I side-load a camera app, it still has to ask for camera privileges the same way any Play store app does.
Is there something in your message I missed about how it relates to this article or is this just being uninformed about side-loading?
You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
In fact, there are many reasons why you might want a plugin to have full filesystem and internet access, such as batch processing or simply adding things directly from webpages. Sandboxing this will just make plugins less useful.
In the end it's a problem of trust. You're installing software from untrustworthy developers because you trust the name of the application those plugins are associated with.
You could fix the problem in Obsidian, but the same problem will happen in other software. Some of which simply can't justify bothering with sandboxing plugins. This is just the way plugins are.
I'm not saying that I think they should, or that I expect them to. I'm saying that it's one particular implementation of sandboxing that has a bunch of interesting properties, and that makes it worth studying.
0. https://warcraft.wiki.gg/wiki/Secure_Execution_and_Tainting
1. https://wowpedia.fandom.com/wiki/Wowpedia:About_the_wiki#Bac...
I'm somewhat convinced that taint-influenced capabilities is a good future model to pursue. Computers are fast, I'm fairly confident that it chould be done at whole-computer scale and still be reasonable... though probably not with a million electron apps. Which is likely a good thing in aggregate (I say as a fan of web tech and the very compelling features such things offer. Great for minor or PoC, not for major pieces of software).
- Home folder read/write access
- System folder media
- System folder mnt
- Microphone access and audio playback
- And more...
The Obsidian snap [1] is installed with the --classic flag, which also grants access to the whole home directory, but at least you have to consciously specify the --classic flag to grant this permission.
If you're running GNU/Linux, chances are you'll have hundreds, if not thousands, of pieces of software that run totally unsandboxed.
Yes, a very small minority of applications are unfortunately primarily distributed via flatpak or snap, and the distributors don't care about the user experience, so it's error-ridden and problem-ridden, but chances are you can get a "normal computer program" version of it unencumbered by such grossness.
flatpacks have access to all my files, they would be useless without. And they are the only sensitive files in my computers
The parent comment says that Obsidian is not usable without plugins and it's simply nonsense. It would be very charitable to call this a "dispute."
Could Obsidian handle plugin permission better? I guess so. But that doesn't mean the users have to use plugins. It's ultimately the user's choice. Blender has zero security guards over the addons besides the OS's and the ecosystem thrives. So does Minecraft. These communities are essentially "arbitrary Python/Java code goes brrrr."
The discussion about the plugin-system, and the people who need it to which degree.
> The parent comment says that Obsidian is not usable without plugins and it's simply nonsense.
Sure, fair. But the comment happened in the context of talking about the plugin-system, and parent comment seems on the side that for them obsidian is worthless without plugins. Saying that other people have no need for them is pointless, because they are not in the picture. Phrasing could indeed be better, but talking about people who are not concerned by the problem is not really adding anything to the discussion.
The disagreement was because the actual claim made was far broader, and in that far broader context, opposite to reality. We can assume good faith and an honest mistake in wording, but we can also forgive respondents for reasonably taking the words at face value.
Flatpak could of course be significantly better... but it's still a massive step in a better direction.
Besides. They said "all software on your machine". That is trivially false, to a significant degree.
Sandboxing, at least in the sense of easily configurable access with default deny on most even somewhat sensitive things: agreed, sandboxing is fairly uncommon in general, definitely not a majority on most systems. When ignoring the elephant in the room: mobile OSes.
A majority run as me, a minority run with root privileges.
> I think that's fairly safe to say, given that new system installs often have hundreds of processes already running.
Precisely! Those hundreds of pre installed processes are running without sandboxing, or any access control beyond what Obsidian has.
For example, did you know you can just `ls` a directory, or `cat` a file, and both of those applications will run with full, unsandboxed, unrestricted access as you? And there are countless preinstalled applications just like those.