A malicious Obsidian community plugin was weaponized to deliver Phantom Pulse, a remote access trojan that targets the exact file types developers and knowledge workers keep in their vaults: SSH keys, .env files, browser cookies, and project notes containing API tokens. The plugin shipped through the standard community plugins flow, which means anyone who installed it during the window between publication and takedown received the payload through the same trusted-by-default channel they use for syntax highlighting and Kanban boards.
This is not a novel exploit. It is the same supply chain pattern that has hit npm, PyPI, the VS Code marketplace, and Chrome extensions. What makes the Obsidian case worth examining is the threat model gap: most teams treat their note-taking tool as a productivity app, not a code execution surface. Obsidian plugins run as Node.js modules with full filesystem access. So do VS Code extensions. So do Cursor extensions. So do most things you install with one click in a developer-adjacent tool.
How the attack chain worked
The reported pattern matches a well-understood supply chain template:
- Plausible plugin metadata. The malicious plugin ships under a name that looks legitimate — typosquatting a popular plugin, or filling a small gap in the ecosystem (a new exporter, a niche theme).
- Initial install runs trusted code. The plugin's stated functionality works as advertised. The hostile payload is gated behind a delay, a config check, or a remote fetch.
- Second-stage delivery. The plugin reaches out to an attacker-controlled host on first run or first vault open, downloads a binary or script, and writes it to a persistence location (LaunchAgent on macOS, scheduled task on Windows, systemd user unit on Linux).
- Phantom Pulse activates. Once installed, the RAT establishes command-and-control, exfiltrates credentials and SSH material, and waits for operator instructions. RATs in this class typically include keylogging, screenshot capture, clipboard monitoring, and file exfiltration.
Treat any tool that loads third-party plugins as a code execution platform, not just a content viewer. Obsidian, VS Code, Cursor, JetBrains, Raycast, and Alfred all execute plugin code with your user account's full permissions. A single compromised plugin can read every file your account can touch.
If you installed an unverified Obsidian community plugin during the affected window, the practical move is to assume compromise until you verify otherwise. Rotate any credential that lived in your vault or in environment variables your shell loaded during that window. Check ~/Library/LaunchAgents (macOS), Task Scheduler (Windows), and ~/.config/systemd/user/ (Linux) for unfamiliar entries. Audit your shell history for unexpected outbound traffic.
Why developer tools keep getting hit
The same dynamics that make plugin ecosystems useful make them attackable:
- Low-friction install. One click, no review, no signing requirement on most platforms. Obsidian plugins, VS Code extensions, Cursor extensions, and Raycast extensions all install and execute without a meaningful security gate.
- Implicit trust transfer. When a plugin is listed in an official community directory, users transfer trust from the platform to every plugin in the directory. The platform did not actually vouch for the code.
- Wide privilege. Plugins inherit the permissions of the host process — full filesystem read/write, network access, and child-process spawning. There is no permission prompt for "this plugin wants to read your .ssh directory."
- Update-time payload swap. A plugin that was clean on day one can ship malicious code in a later update. Ownership transfers, account compromise of the maintainer, or a deliberate switch by the original author all produce the same result.
Cursor and VS Code share most of this attack surface. Both run extensions in the renderer or extension host with broad permissions, and the Cursor extension marketplace inherits VS Code's open-by-default model. If you use AI coding tools that load community extensions, the same audit applies.
A practical audit you can run this week
You do not need a security team to reduce your exposure here. Three concrete steps:
1. Inventory what you have installed.
For Obsidian: open Settings → Community plugins and list every enabled plugin. Note the plugin's GitHub repository and the maintainer's account.
For VS Code or Cursor: run code --list-extensions --show-versions (or cursor --list-extensions --show-versions).
For Raycast: open the extensions tab.
Write the list down. You will not remember to audit something you did not know you installed.
2. Apply a minimum-viable trust filter.
For each plugin, check three things:
- Is the source repository public, and does it have meaningful commit history from more than one contributor?
- Is the maintainer's account active and identifiable?
- Did the most recent update change anything beyond what the changelog claims? Diff the release if you can.
A plugin that fails any of these is not necessarily malicious, but it is a candidate for removal if you do not actively need it. The goal is not to verify every line — it is to remove the long tail of plugins you no longer use.
3. Separate your secrets from your plugin host.
Stop keeping API keys, recovery phrases, and credentials in your Obsidian vault as plain text, even in private vaults. Use a dedicated secret manager (1Password, Bitwarden, or the system keychain). For shell environment variables, load them from a secret store at session start instead of writing them into .env files that any plugin can read.
What this changes about how you pick tools
The Phantom Pulse incident does not mean abandon Obsidian or any other plugin-driven tool. It means treating plugin install as a privileged action — closer to "run this binary I downloaded from the internet" than to "enable a feature." The platforms with the strongest stories here are the ones that sandbox plugin execution or require code signing and review.
Until Obsidian, VS Code, and Cursor add meaningful sandboxing for community plugins, the audit is on you. Keep the list short. Prefer plugins from maintainers you can identify. Pin versions when you can, and read the diff when an update lands.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)