May 2026
Your Notes App Is a Code Execution Environment
You were invited to a shared Obsidian vault. You opened it. You enabled community plugins, because the vault would not work otherwise. A remote access trojan was now running on your machine, taking instructions from an Ethereum smart contract.
That is the chain that ran against finance and cryptocurrency professionals through April 2026. Threat actors posed as venture capitalists on a professional networking site, moved the conversation to a private Telegram group, then invited targets to a shared Obsidian vault. The vault needed two community plugins to work properly: Shell Commands and Hider. Once enabled, both delivered the PHANTOMPULSE remote access trojan, tracked by researchers as REF6598. PHANTOMPULSE captures keystrokes and screen activity, exfiltrates files, and runs arbitrary commands on the host.
What makes it clever is the command-and-control channel. The wallet address is baked into the binary, but the current C2 server is not. Its IP lives inside the most recent transaction history of that wallet on Ethereum. Rotating infrastructure is a single transaction. The malware itself never changes.
The reflex is to file this under "Obsidian vulnerability." It is not.
This is not an Obsidian bug
The Obsidian plugin system is working exactly as designed. Plugins are Node.js code with filesystem and network access. That is the feature. You cannot patch a plugin system into not running plugins.
Every report calling this an "Obsidian flaw" misses the point. There is no software fix coming. The only control that matters is the human decision to enable the plugin, and PHANTOMPULSE was engineered around making that decision feel normal.
The delivery chain is the interesting bit
LinkedIn → Telegram → shared vault is a three-step legitimacy laundering process. Each step feels like a reasonable escalation of trust.
By the time the target reaches the shared vault, the attacker has already been a LinkedIn connection, then a Telegram contact, then a collaborator with shared materials. "Enable community plugins so you can see my research properly" feels like the small ask at that point. It is not. It is a software installation decision dressed as a note-taking decision.
This is the same pattern as North Korea's Contagious Interview campaign. Variants of it have used trojanised video-call apps planted via fake recruiters to deliver the BeaverTail and InvisibleFerret remote access trojans, and malicious coding challenges that targets opened in VS Code. It is the same pattern as the axios supply chain compromise, where attackers built a fake company to befriend a single maintainer before delivering through the toolchain that maintainer already trusted. The relationship is the payload delivery infrastructure.
It isn't just Obsidian
This is the core point. A short, uncomfortable list of trust surfaces that work the same way.
- VS Code extensions. Same model, same trust gap. Open a workspace, get a "this workspace recommends installing X" prompt, click yes, done.
- Chrome extensions. "Read and change all your data on all websites" is the default permission ask. 900,000 installs of a single malicious AI-assistant Chrome extension earlier this year.
- Notion integrations and Slack apps. OAuth scopes to everything you have access to, granted with one click during a "set up your workspace" wizard.
- Raycast, Alfred, and other launcher extensions. Arbitrary code at user privilege, no sandbox, no review.
- Microsoft Office add-ins. Read your documents, make outbound calls, persist quietly.
Two of those examples are linked above. PHANTOMPULSE is the latest entry. The pattern is the category, not the accident.
Why productivity tools make great delivery vehicles
Four reasons your notes app, your launcher, and your shared workspace are better delivery surfaces than your inbox.
- They feel like documents, not software. Users have a completely different threat model for "opening a note" than for "running an executable." Plugin installation lives somewhere between the two, and the user instinct is to treat it like the first one.
- They come with network and filesystem access by default. Plugin code does not need to escape a sandbox. The host application already grants what the attacker needs.
- The EDR sees the host application, not the plugin. Plugin activity looks like host-application activity on the wire. The malicious behaviour is wearing legitimate clothes.
- They encourage sharing. Shared vaults, shared workspaces, shared extension recommendations. Each share is an implicit trust request the user is unlikely to scrutinise.
The attacker does not need a zero-day in Obsidian. They need you to believe that clicking "Enable" on a plugin in a vault from a nice person you met on LinkedIn is a note-taking decision.
What the basics still say
The defensive answer is not novel. It is the same five things the basics have always said about anything that runs code.
Know what is installed. You cannot defend what you cannot name. Inventory plugins across every productivity tool your staff use. Most organisations cannot do this today. That is the first finding.
Approve before installing. Not heavy. A named person, a short check, a shared list. The absence of this process is the gap that PHANTOMPULSE walked through.
Default to restricted. Obsidian has a Restricted Mode that disables community plugins. Use it. Chrome has Enhanced Safe Browsing. Use it. VS Code has workspace trust. Use it. They cost nothing and they break very little.
Treat shared workspaces as untrusted input. A shared Obsidian vault from a contact is code from a stranger, wrapped in something that looks like a document. The wrapper is the social engineering.
Separate work and personal profiles. The browser extension your kid installed on the family laptop should not be a credential exfiltration vector for your client data.
Name the trust boundary
The specific insight to leave with:
Every productivity tool that supports extensions is a code execution environment. Treat it like one.
Your IDE is obvious. Your browser is obvious if you think about it. Your notes app, your chat client, and your launcher are less obvious, but they are the same thing. The attacker understands this. Most of your staff do not.
What this looks like Monday morning
Five concrete steps. None of them require budget. All of them require somebody deciding that this is a category that needs a policy.
- Run the inventory. VS Code extensions, browser extensions, Obsidian plugins, Notion integrations, Slack apps. Write them down. Where they touch business data, flag them.
- Delete what nobody remembers installing. Most of it will not be missed.
- Pick one person to approve new installs. The bar is: "is this from the publisher I think it is, and does anyone else on the team use it?"
- Enable restricted modes by default. Obsidian Restricted Mode. Chrome Enhanced Safe Browsing. VS Code workspace trust.
- For executives, finance staff, and legal, go further than the above. Disable community Obsidian plugins entirely. Separate browser profiles for work and personal. Separate vaults for shared materials and personal notes.
Obsidian is a great notes app. Chrome is a great browser. VS Code is a great editor. That is precisely why they make such good delivery vehicles for things that are not notes, browsing, or editing.
The trust boundary is not at the door of the tool. It is at the plugin.
ThreatControl helps organisations understand their attack surface, harden their developer and productivity tooling, and build resilience they can actually achieve. If you do not know what plugins are running across your organisation, our Fractional CTO service is built for exactly that audit. Our free Flash Briefing is the five-minute starting point on external exposure. Get in touch.