Obsidian Plugin Safety Scorecards: Audit Community Plugins Before the October 30 Deadline

Obsidian plugins can read your notes, reach the internet and run code on your machine. Many users install them on impulse and then forget them. Obsidian now has a systematic check for this. Every community plugin has an automated safety scorecard in the web-based Community directory. A deadline is also approaching that could pull failing plugins out of the in-app browser.

XDA Developers writer Nolen Jonker audited their own vaults against the scorecards and ended up uninstalling a few plugins. This article covers what the scorecards check, how to read them, and how to treat the results as evidence rather than a guarantee.

What changed in Obsidian's plugin review​

Obsidian's help documentation says Obsidian automatically scans every plugin version for security vulnerabilities, code quality issues, and malware. Results appear on each plugin's directory page as a safety scorecard. Manual reviews continue for popular, featured, and flagged plugins.

That is a real shift. Obsidian's own announcement says initial submissions were manually reviewed and approved by its small team until the transition. The new system scans every version for security and code quality, not just the initial submission. Before this, a plugin approved years ago could have changed substantially with no one re-checking it. XDA reports the web directory went live in May. The official pages I consulted confirm the system but not that date.

The scorecards are not in the app. XDA notes that you have to look for it in a browser.

Reading the scorecard​

XDA describes a Scorecard tab and a sidebar with two bars:

• Health covers whether anyone is still maintaining the plugin. It also pulls in recent commits and install numbers.
• Review scans the latest release and checks for vulnerable dependencies and whether the published build can be reproduced byte-for-byte from the source.
• Disclosures and Other spell out what a plugin can reach.

Obsidian's directory help page describes the review section along the same lines. It lists passed checks, such as no known vulnerable dependencies, no obfuscated code and verified GitHub artifact attestations. It also lists disclosures (things the entry does that aren't necessarily issues but that you should be aware of, such as accessing your clipboard or making requests to external domains) and other notes.

A disclosure is not an accusation. XDA's example is Excalidraw, whose scorecard says it reads the clipboard and can see file paths in the vault. For a drawing tool, that is plausible behaviour. It is still something you may not have thought about.

I could not find an official formula for the Health grade. Treat it as a maintenance and activity signal, not a security rating.

Interpreting results without over-trusting them​

"Malware scan not available"​

All four plugins in XDA's test vault showed this line, as did big names like Dataview and Templater. The writer's reading is that it means no malware result exists yet. That is the writer's observation and not an official definition. The practical point stands either way: this label cannot tell you a plugin is malware-free.

Base64 flags and reproducible builds​

Excalidraw was flagged for base64 encoding, which the scorecard says is sometimes used to hide things like URLs or API keys. XDA then saw that Obsidian had rebuilt the plugin from public source and got a file identical to the installed one.

That is useful provenance evidence. It shows the shipped file matches readable source. It does not prove the source is harmless, and a match is not a substitute for judging whether the plugin's behaviour suits your vault.

The article also gives two different Excalidraw figures, 97.5K installs and 8.5 million downloads. I can't say what each measures, so don't rely on either number.

When Health and Review disagree​

XDA suggests looking for mismatches. Text Generator had excellent Health but a "caution" Review rating. Screen Pet Companion passed review but has a single release and about 450 installs, which suggests a small side project. JokerType passed everything, but the writer removed it because they rarely used it.

Obsidian's documentation says a lower health or review score has its own interpretation guidance. A caution or warning is not the same as a failure.

The October 30 cutoff​

On August 27, 2026, the Obsidian team posted a notice on a plugin repository's GitHub issue tracker. It said automated scans for existing entries were informational only until October 30th, 2026. After that date, if a plugin's latest release still does not pass automated review, it will no longer be listed in the directory or installable in the Obsidian app.

Here is what that does and does not mean:

• It applies to releases that still fail review, meaning errors. It does not apply to every plugin with a caution or warning.
• It concerns directory listing and new installs. The notice does not say already-installed copies will be removed or stop working.
• Maintainers can fix scan errors on their entry dashboard and publish a new release.

If a plugin you depend on is poorly maintained, check its scorecard now. Look for an alternative, or an update, before it disappears from the browser.

The limit that no scorecard removes​

Obsidian is blunt about the underlying design. Due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels, so plugins inherit Obsidian's access levels. The documentation lists examples: plugins can access files on your computer, connect to the internet and install additional programs.

So a passing scorecard is not isolation. It is transparency and release-time checking layered on top of a trust model that is still broad. For sensitive data, Obsidian recommends an independent security audit before installing a community plugin.

Obsidian also warns that scorecards are young. Its announcement says scorecards are new and can contain errors, including false positives and false negatives. The same announcement says they will continue to improve as disclosures, privacy labels, artifact attestation and manual review results are incorporated. XDA's pages also carry a work-in-progress banner.

A practical audit routine​

1. Open each installed plugin's page in the Community directory and read the detailed findings, not only the summary bars.
2. Separate errors from warnings, cautions and recommendations. Only unresolved failures are tied to the October 30 deadline.
3. Compare the disclosures against the plugin's purpose. A clipboard or network disclosure on a plugin that has no reason for it deserves a closer look.
4. Check whether the plugin is still maintained. Look at recent commits, release count and open issues.
5. Remove what you don't use. XDA's rule of thumb is to uninstall anything that has been disabled for a few months. That is the writer's housekeeping habit, not an Obsidian requirement.
6. For sensitive vaults, consider Restricted Mode. Obsidian says installed plugins remain in your vault even if you turn on Restricted mode, but are ignored by Obsidian. You can toggle it in Settings → Community plugins.

If you suspect a plugin is malicious, Obsidian's help says you can flag it from its directory page.

Bottom line​

The scorecards fix a genuine gap, because approval is no longer a one-time event. They are best read as an inventory prompt and a source of evidence. They are not a verdict. XDA's author found nothing sketchy, yet still trimmed their plugin list, and that is a perfectly good outcome for a security feature.