The Hidden Cost of “Just Add a Plugin System”

Community plugin ecosystems are one of the most powerful growth mechanisms in software. They are also, almost universally, unsandboxed code execution on your users’ machines. Here is why Klarinotte builds features natively instead.

When I started building Klarinotte, one of the earliest decisions I had to make was whether to open it up to community plugins. The case for doing so is genuinely strong, and Obsidian is the proof: since opening its API in 2020, the community has produced more than 4,000 plugins and themes with over 120 million downloads between them. That’s an enormous amount of functionality that no small team could ever have shipped on its own. Dataview, Templater, Excalidraw — for a lot of users these are Obsidian. A plugin ecosystem turns your product into a platform, and a platform grows in directions you never anticipated.

I decided to build several of those features natively into Klarinotte instead, and the reason comes down to something Obsidian itself states plainly in its own documentation: community plugins are not sandboxed.

Community plugins can access files on your computer, connect to the internet, and install additional programs. … Due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels.

— Obsidian Help, “Plugin security”

That is not a criticism of Obsidian — they’re being unusually honest about a constraint that applies to nearly every desktop plugin architecture. But it means the security model is essentially: every plugin you install runs with the full privileges of the app itself, and therefore with your privileges. You are not installing a feature. You are installing a program, and trusting a stranger not to abuse it.

The browser extension world shows what that trust actually costs at scale. In December 2024, attackers ran a phishing campaign against extension developers, sending emails that impersonated Google and warned of policy violations. Developers who clicked were taken to a real OAuth consent screen and asked to authorize an app innocuously named “Privacy Policy Extension” — which granted attackers permission to publish updates to those developers’ extensions. At least 35 extensions were hijacked this way, reaching roughly 2.6 million users, including one belonging to the security company Cyberhaven. The injected code harvested Facebook session tokens and watched for QR codes and CAPTCHAs to work around two-factor authentication. Firefox has its own version of the problem: since April 2025, researchers have tracked a campaign of more than 40 fake add-ons impersonating MetaMask, Coinbase, Trust Wallet, Phantom, and Exodus, built by cloning the real open-source extensions and injecting seed-phrase theft, then padded with hundreds of five-star reviews — in some cases more reviews than the extension had installs.

The Visual Studio Code marketplace is where this gets most uncomfortable, because the victims are developers, and developers hold the keys to everything else. In May 2026, attackers compromised a maintainer of Nx Console and pushed a poisoned version to the marketplace. It ran a single shell command that pulled down a hidden package designed to steal credentials from 1Password vaults, npm, GitHub, AWS, and AI coding tool configs.

Because VS Code updates extensions automatically by default, eighteen minutes was enough. One of the machines it reached belonged to a GitHub employee, and GitHub confirmed days later that roughly 3,800 of its own internal repositories had been exfiltrated. This wasn’t a one-off, either: researchers scanning the marketplace have flagged over 1,200 extensions containing known malicious code, with something like 229 million installs collectively, and a proof-of-concept typosquat of the popular Dracula theme quietly landed inside more than 100 organizations before anyone noticed. A review process that catches bad extensions in hours is useless against an attack that completes in minutes.

None of this means plugin systems are a mistake — it means the trade is more lopsided than it looks, and the costs land on users who have no way to evaluate them. Centralized development has real, unglamorous advantages here that are easy to undervalue: there is exactly one supply chain to defend instead of thousands; features get audited, versioned, and updated as a single unit; a fix ships to everyone at once rather than waiting on whichever maintainer still has time for a side project; and when something goes wrong, there is one party who is unambiguously accountable. Features built in-house also tend to work together rather than merely alongside each other. The honest middle ground — which Obsidian is now moving toward with automated scanning, capability disclosures, and safety scorecards — is to build the features most people need into the core, sandbox extensions wherever the platform allows it, be explicit about what a plugin can reach, and treat every auto-update as the privileged code execution it actually is. Extensibility should be a deliberate architectural decision with a threat model attached, not a growth strategy you adopt because the roadmap is long and the team is small.