Obsidian plugin was abused to deploy a remote access trojan

Original Article ↗ Hacker News Discussion ↗

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.