Your Note App's Plugins Are an Attack Surface

A plugin marketplace is an attack surface by construction. Every extension you can install is third-party code you have invited to run with your files' privileges. In April 2026, a campaign that Elastic Security Labs tracks as REF6598 proved the point: it turned two ordinary community plugins into a remote-access trojan.¹

The campaign — the security researchers named the implant PHANTOMPULSE — did not exploit a bug. There was no CVE, no zero-day, no patch to wait for. It abused features working exactly as designed. That is the uncomfortable part, and it is why this is an essay about architecture rather than a single incident. The more a tool can do for you, the more it can do to you.

What actually happened

REF6598 abused a real product's plugin system, but the mechanism is generic. Elastic's researchers describe it plainly: "The threat actors abuse Obsidian's legitimate community plugin ecosystem, specifically the Shell Commands and Hider plugins, to silently execute code when a victim opens a shared cloud vault."¹ Two well-known plugins, composed into a weapon.

The campaign "targets individuals in the financial and cryptocurrency sectors through elaborate social engineering on LinkedIn and Telegram."¹ This was not a worm sweeping the internet. It was a hand-built lure aimed at people with crypto wallets. The victim had to be talked into opening a poisoned shared vault.

Once inside, the malware was patient and quiet. Elastic found that it "queries" Ethereum blockchain instances, where "each request fetches the most recent transaction associated with a hardcoded wallet address" to resolve where to phone home.¹ Its supported commands include keylogging, screenshots, file drops, and privilege escalation.¹

Why a bug-free attack is the scary kind

The detail that should change how you think is the absence of a vulnerability. Elastic's own summary is the cleanest statement of the problem: "By abusing Obsidian's community plugin ecosystem rather than exploiting a software vulnerability, the attackers bypass traditional security controls entirely, relying on the application's intended functionality to execute arbitrary code."¹

Read that twice. The application did nothing wrong. A plugin meant to run shell commands ran a shell command. A plugin meant to hide content hid content. The payload "lives entirely within JSON configuration files that are unlikely to trigger traditional AV signatures, and execution is handed off by a signed, trusted Electron application," the researchers told The Hacker News.²

You cannot patch a feature. When the exploit and the intended behavior are the same operation, the only defense is to not have offered the operation. That is the architectural fork this whole essay turns on.

This is not an Obsidian problem

The pattern is everywhere extensibility lives, and Obsidian is far from the worst-exposed marketplace. Consider the editor most developers open every day. A peer-reviewed audit of 52,880 third-party VS Code extensions found that "~5.6% of the analyzed extensions have suspicious behavior, jeopardizing the integrity of the development environment and potentially leaking sensitive information."³

The root cause is the same grant of trust. The same study notes that "upon installation, a VS Code extension typically gains unrestricted access to the VS Code API," and that "possible threats include arbitrary code execution, unauthorized file manipulation, and data theft or corruption."³ An extension advertised for one harmless job can quietly do another.

The trend line is moving the wrong way. Visual Studio Magazine, reporting on industry detection data, found that in the first ten months of 2025, detections of malicious software on VS Code nearly quadrupled, from 27 in 2024 to 105.⁴ Browser extensions tell a parallel story. Wherever there is a marketplace and an install button, there is an attack surface — and the bigger the marketplace, the more install events there are to poison.

Obsidian's own answer: less is safer

Here is what makes this fair rather than a smear: the better argument is Obsidian's own. Its team published it before this incident broke, and it agrees with this post's thesis. The September 2025 essay on supply-chain risk states that "the primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code."⁵

They are honest about the limits, too. "No single measure can eliminate supply chain risk. But choosing fewer dependencies, shallow graphs, exact version pins, no postinstall, and a slow, review-heavy upgrade cadence together make Obsidian much less likely to be impacted."⁵ That is a mature security posture, stated by the people who own the product.

The rest of Obsidian's design deserves credit too. Community plugins ride a sync feature that, in Elastic's words, is "disabled by default" and is a "local client-side preference" that does not propagate through sync.¹ The attack needed a human to flip that switch.

The Hacker News confirms the boundary: the option "is disabled by default and cannot be remotely turned on," so the attacker "must convince the target to manually toggle the community plugin sync on their device."² And Obsidian's broader stance is genuinely local-first — "No account required, no ads, no tracking, no strings attached. Your data remains fully in your control, stored locally in plain text Markdown files."⁶

The cost of the door, even when it is closed

Restraint is not free, and the honest version of this argument concedes that. An extensible ecosystem is wildly useful. Obsidian's plugins "have passed 120 million total downloads," and "more than 4,000 plugins and themes have been created" by its community.⁷ That is a staggering amount of value built by people who wanted their tool to do more.

But scale is exactly the surface. A marketplace this large is millions of install events, any one of which is a moment of trust. To its credit, Obsidian is moving to make that trust legible. Its roadmap promises that "plugins will declare what they access: network, file system, clipboard, and other capabilities," and that "users will be able to see these disclosures before installing plugins."⁷

Capability disclosure is the right mitigation for a tool that has chosen extensibility. It narrows the door. It does not remove it. A disclosed capability is still a capability, and a user who can be socially engineered into opening a vault can be socially engineered into clicking "allow."

The structural alternative: nothing to weaponize

There is a different fork in the road — the one a minimal tool takes. If a note app runs no third-party plugins, has no marketplace, and lets nothing execute against your files, then there is no community-extension layer to socially-engineer into running a command. The only plugin that cannot be weaponized is the one that does not exist.

This is the structural property worth naming. Plain Markdown is inert — a text file has no API to grant, no shell to invoke, no capability to disclose, because it has no capability at all. Your notes sit locally on your own device as plain text, and nothing runs against them. There is no door because the wall was never cut.

Be clear about the trade. This means fewer power-user plugins — sometimes none. That is a real cost for people who want their note app to also be an automation platform. The argument is not that restraint is always right.

It is that restraint is a security property — not a missing feature — and it should be counted as one. This is the same restraint that argues for owning your data in plain files,⁸ for an export drill that survives your app's shutdown,⁹ and for tools whose value does not depend on chrome you cannot remove.¹⁰

Frequently asked questions

Are note-taking app plugins a security risk?

Yes — any plugin runs third-party code, and that code inherits real privileges. A peer-reviewed audit of 52,880 VS Code extensions found ~5.6% behaving suspiciously, with installed extensions gaining broad API access that enables file manipulation and data theft.³ The risk is proportional to how much the plugin system can do.

Can a note-app plugin contain malware?

It can, and the PHANTOMPULSE / REF6598 campaign demonstrated it in April 2026 by composing two real community plugins into a remote-access trojan.¹ Importantly, it abused intended functionality rather than a vulnerability, and the targeted victim first had to be socially engineered into enabling a sync feature that is off by default.²

Is my vault a security risk?

Your vault files are not the risk; executable plugins with file access are. Plain Markdown is inert — it cannot run, query, or exfiltrate anything on its own. The danger enters through third-party code you install and grant privileges to, not through the text you write.

What can a malicious note-app plugin actually do?

In the REF6598 case, the implant supported keylogging, screen capture, file drops, code injection, and privilege escalation, resolving its command-and-control server through transactions on the Ethereum blockchain.¹ A plugin granted file-system and shell access can, in principle, do anything the host process can do.

Are VS Code or browser extensions any safer?

They share the same architecture and the same exposure. Malicious-software detections on VS Code nearly quadrupled from 27 in 2024 to 105 across the first ten months of 2025, by industry data reported in Visual Studio Magazine.⁴ Any marketplace that grants extensions broad access carries this risk.

How do I make my notes more secure against this?

Reduce the third-party code that touches your files. Obsidian's own team puts it best: "the primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code."⁵ Keep capability-disclosure prompts honest, install little, and prefer tools that do not run untrusted plugins against your notes at all.

A plugin marketplace and an attack surface are the same architecture seen from two angles, and no amount of disclosure collapses them into one. The safest extension is the one a tool never had to offer — which is why, sometimes, the most secure thing a note app can do is less.

This post credits Obsidian's own "less is safer" doctrine, which made the case before the incident did. To keep that principle in practice, mnmnote.com runs no third-party plugins against your files — your notes stay as plain Markdown on your own device, with nothing executing against them.