Obsidian plugin was abused to deploy a remote access trojan

Original Article ↗ Hacker News Discussion ↗

An attack campaign targeting Obsidian, a popular markdown-based note‑taking app, used a shared vault preloaded with malicious community plugins to install a remote access trojan, relying on social engineering to get victims to bypass built‑in warnings. Commenters highlight that Obsidian’s plugin model gives third‑party code full access to users’ files and network, comparing it to broader problems with unsandboxed plugin ecosystems and arguing this makes the app risky for sensitive or enterprise use. Many call for a more “batteries‑included” core, stronger sandboxing and Android‑style permission prompts, while others defend Obsidian’s openness and note the company has announced upcoming security improvements.

Nature of the attack

  • Attack uses a shared Obsidian vault that already includes malicious community plugins, plus social engineering to:
    • Get the victim to enable community plugins.
    • Enable syncing of plugins from the shared vault.
  • Plugins then deploy a RAT; no evidence in the thread of a popular existing plugin being taken over.
  • Several commenters stress this is a social-engineering campaign rather than an exploit of a specific code vulnerability.

Obsidian’s current plugin security model

  • Community plugins run with effectively full access: can read/write files, access the network, and spawn programs.
  • This behavior is documented in Obsidian’s own security help, which some see as honest disclosure, others as “negligent by design.”
  • Plugins are not auto‑updated, but a malicious update to a popular plugin is seen as a high‑risk scenario.

Responsibility: user behavior vs platform design

  • One side: Obsidian has “proper protections”; the attack required users to override explicit warnings, analogous to running any untrusted software.
  • Other side: putting powerful, unsandboxed plugins behind easily dismissible warnings is called bad engineering, especially for a mainstream note app.
  • Debate over whether this makes Obsidian inappropriate for enterprise use; some call using it there “malpractice,” others say any app can be abused if users disable safeguards.

Sandboxing and permission ideas

  • Strong support for:
    • Granular permissions (filesystem, network, external programs) similar to Android/iOS.
    • Sandboxed plugin runtimes (e.g., WASM/WASI, Lua, or OS-level isolation).
    • Forcing plugins to declare network endpoints and capabilities upfront.
  • Counterpoints:
    • Proper sandboxing is hard and costly.
    • Many powerful plugins legitimately need broad access.
    • Over-restricting would “neuter” the ecosystem and user power.

Plugins: essential or optional?

  • Split opinions:
    • Some say Obsidian is unusable for serious workflows without community plugins.
    • Others happily run “vanilla” or only official/core plugins and view third‑party plugins as unnecessary risk or bloat.
  • Several users sandbox Obsidian at the OS level or only use self‑written / audited plugins.

Project response and future direction

  • A major plugin-security update is announced as “coming soon.”
  • Some commenters are skeptical, arguing concerns were raised years ago; others remain confident in the app but want more batteries‑included features plus enforced permissions.