Many serious vulnerabilities found in Obsidian's Excalidraw plugin | ZeroQuarry Research

Sign in<br>Request scan ->

Developer tools are an unusually high-value target<br>Example 1: A drawing file could execute script on open<br>Example 2: A pretty icon could become executable UI<br>Example 3: A link in a drawing could become an Obsidian command<br>Example 4: A cleanup feature could delete the wrong files<br>Example 5: A convenience preview leaked private URLs<br>Example 6: AI-generated HTML became active content<br>Why SAST usually misses this<br>How ZeroQuarry found these for less than $30 of inference<br>The maintainer response matters<br>ZeroQuarry is free for open-source projects

Most security tools are good at spotting code smells.

They can flag dangerouslySetInnerHTML. They can complain about new Function. They can warn about outdated packages. They can tell you that a URL is being fetched, or that user input reaches a file path.

But the hardest vulnerabilities are rarely just "bad function used here."

They are usually: bad function used here, in this product workflow, after this kind of file is shared, with these permissions, inside this trust model, by this kind of user.

That is where many static analysis tools struggle. And that is exactly the class of issue ZeroQuarry was built to find.

In May 2026, ZeroQuarry scanned the Excalidraw plugin for Obsidian, a widely used visual thinking and whiteboarding plugin. The initial scan reported 41 high-severity, 32 medium-severity, and 2 low-severity findings. A later re-scan, after fixes, showed that the highest-risk surface had been substantially reduced.

The interesting part is not the count. The interesting part is the *type* of vulnerabilities ZeroQuarry found.

These were not simple "regex found eval" findings. They were product-context findings: issues that only matter if you understand how Obsidian vaults are shared, how Excalidraw drawings are represented as Markdown, how plugin scripts work, how users install community scripts, how drawings embed links and images, and how people collaborate by passing around notes, vaults, and canvases.

That is the gap ZeroQuarry is designed to close.

Developer tools are an unusually high-value target

Developer and power-user tools sit in a strange place in the security landscape.

They are often open source. They are often trusted deeply. They are often installed by technical users. They often run locally with broad access to files, credentials, notes, source code, SSH keys, API keys, browser-accessible sessions, and internal URLs.

They also tend to have rich extension systems: plugins, scripts, templates, Markdown processors, embedded webviews, custom protocol handlers, AI helpers, import/export pipelines, and sync workflows.

That richness is what makes them useful. It is also what makes them difficult to secure.

The Excalidraw Obsidian plugin is a good example. On the surface, it is a drawing plugin. In practice, it is a miniature application platform inside Obsidian:

Drawings are Markdown files.

Drawings can contain frontmatter.

Drawings can embed images, files, links, HTML-like content, Mermaid diagrams, and script-driven behavior.

Scripts can automate the plugin and interact with Obsidian APIs.

Users share drawings and vaults with each other.

The plugin runs in an Electron/Obsidian environment, not a locked-down browser tab.

That means the security question is not simply, "Is there an unsafe function?"

The real question is: Can attacker-controlled vault content cross a trust boundary and become executable behavior?

ZeroQuarry found multiple places where the answer was yes.

Example 1: A drawing file could execute script on open

One of the clearest examples was frontmatter-driven execution.

Excalidraw drawings in Obsidian are stored as Markdown-like files. The plugin supported an excalidraw-onload-script frontmatter field. ZeroQuarry traced the path from a drawing file's frontmatter into the plugin's script engine.

The issue was not merely that a script engine existed. Script engines are a legitimate feature. The issue was that a drawing file -- something a user might receive, sync, import, or open as content -- could carry executable code that ran automatically when the drawing opened.

Conceptually, the dangerous object looked like this:

excalidraw-plugin: parsed<br>excalidraw-onload-script: |<br>// attacker-controlled JavaScript executed when the drawing opens<br>// could read, modify, or delete vault files through plugin APIs<br>The product-context problem is subtle:

Users treat a drawing file as content.

The plugin treated a field inside that content as code.

The code ran automatically on open.

The execution context had access to Excalidraw automation and Obsidian plugin capabilities.

A conventional scanner might flag the dynamic execution primitive. But it likely would not know whether this was a legitimate trusted script feature, a user-approved automation path, or an untrusted drawing-file execution...