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 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."
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.
>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.
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]
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?
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.
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)).
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.
* Android's permissions model where the user must approve specific potentially undesirable classes of actions (separate from the 24H delay, etc controversy)
* Optional sandboxing
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.
A bad update to one of the popular plugins could compromise lot of systems.
Because in general, "usable" means "people use it". Which they do for Obsidian without community plugins without issues.
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"
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.
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.
Same way I run any other application that could potentially execute untrusted code.
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.
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.
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).
https://docs.github.com/en/actions/how-tos/secure-your-work/...
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.
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.
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?
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.
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...
(I actually use LogSeq, but same idea applies).
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.
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.
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).
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.
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.
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.
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?)
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.
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.
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:
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.
Besides. They said "all software on your machine". That is trivially false, to a significant degree.
There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.
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.
I've been using open source alternatives for different purposes for some time.
Obsidian would've been a great choice as open source note taking software. As it is now, it's just one sale, one exploit or one corporate rug pull away from being turned into something else.
Third party audits are meaningless. They were done for one specific version of the code at one point in time. There's literally nothing preventing a malicious version of the software from being shipped. The same goes for plausible deniability on security vulnerabilities in the context of plugins (even with these alleged prompts that the user has to skip on purpose).
IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.
I have no idea how to do that in Windows though.
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).
Security researchers have identified a highly targeted social engineering campaign (REF6598) that weaponizes the Obsidian note-taking application to deliver a previously undocumented Remote Access Trojan (RAT) named PHANTOMPULSE. The campaign targets individuals in the financial and cryptocurrency sectors on both Windows and macOS. Attackers use platforms like LinkedIn and Telegram to build trust before luring victims into a malicious shared Obsidian vault. The attack chain relies on tricking the user into enabling a community plugin, which then executes code to deploy the RAT. PHANTOMPULSE demonstrates advanced capabilities, including using the Ethereum blockchain to dynamically resolve its command-and-control (C2) server address, making it highly resilient to takedowns.
The attack, designated REF6598, is a multi-stage social engineering effort. Threat actors pose as venture capitalists and engage with targets on professional networking sites before moving the conversation to a private Telegram group. The primary lure is an invitation to collaborate via a shared, cloud-hosted Obsidian vault.
Once the victim opens the shared vault, the infection is triggered by social engineering. The victim is prompted to enable the "Installed community plugins" synchronization feature. This seemingly innocuous action, which requires manual user approval, is the key to the compromise. It enables malicious versions of legitimate Obsidian plugins ('Shell Commands' and 'Hider') that are present in the shared vault.
The attack chain differs slightly between Windows and macOS but follows the same general principle:
T1566.002): The attacker uses social engineering on LinkedIn/Telegram to convince the target to open a malicious shared Obsidian vault.T1204.002): The user is manipulated into enabling community plugins within Obsidian. This action executes a malicious script via the compromised 'Shell Commands' plugin.T1055).T1102.002): PHANTOMPULSE uses a novel C2 mechanism. It queries the Ethereum blockchain for the latest transaction from a hard-coded wallet address. The C2 server's IP address is embedded within this transaction data, providing a decentralized and censorship-resistant way for the malware to receive instructions.Once active, PHANTOMPULSE can capture keystrokes, take screenshots, exfiltrate files, and execute arbitrary commands.
A successful compromise gives the attacker full access to the victim's machine. For professionals in finance and crypto, this could lead to the theft of sensitive corporate data, intellectual property, trading strategies, and, most critically, cryptocurrency wallet keys and exchange credentials. The cross-platform nature of the attack broadens its potential victim pool. The use of a blockchain-based C2 demonstrates a high level of sophistication, making the threat infrastructure difficult to disrupt.
Type
process_name
Value
Obsidian.exe
Description
Monitor for Obsidian spawning child processes like powershell.exe, cmd.exe, or osascript.
Type
command_line_pattern
Value
powershell -ExecutionPolicy Bypass
Description
Suspicious PowerShell execution, especially when initiated by a non-standard application like Obsidian.
Type
network_traffic_pattern
Value
Outbound connections to Ethereum blockchain nodes or gateways from unexpected processes.
Description
Could indicate PHANTOMPULSE attempting to resolve its C2 address.
Type
file_path
Value
[Vault]/.obsidian/plugins/
Description
Monitor for the creation or modification of files within the Obsidian plugins directory, especially outside of the official plugin marketplace.
powershell.exe, cmd.exe, bash, osascript). This is highly anomalous behavior.