Execução de Código Arbitrário Orientada por Frontmatter no Note Toolbar via Cadeia de Variáveis {{prop_NAME}} → {{js:}}

Status do CVE: solicitado, aguardando atribuição. Esta descoberta está publicada como GHSA-q8cw-3m8c-5pf2. Após a atribuição do CVE, este repositório será renomeado CVE-YYYY-NNNNN-obsidian-note-toolbar-PoC e este banner será substituído pelo link do CVE.

Pesquisador	Dostxodjayev Abdullox (@squeeze440)
Aviso	GHSA-q8cw-3m8c-5pf2
CVSS 3.1	7.0 (Alto)
Fraqueza	CWE-94, CWE-1336

---

Execução de Código Arbitrário Orientada por Frontmatter no Note Toolbar via Cadeia de Variáveis {{prop_NAME}} → {{js:}}

Resumo

A neutralização inadequada de saída no motor de substituição de variáveis do Note Toolbar (plugin do Obsidian) permite que um atacante que controla o frontmatter YAML de uma nota (por exemplo, um colaborador em um cofre sincronizado/compartilhado) alcance execução de código arbitrário na máquina da vítima quando a vítima simplesmente abre a nota, injetando um payload {{js: ...}} em uma propriedade de frontmatter que um item de barra de ferramentas pré-existente, não-script, referencia via {{prop_NAME}} em seu rótulo/tooltip/link.

Produto

Note Toolbar (note-toolbar) — plugin da comunidade Obsidian Repositório: https://github.com/chrisgurney/obsidian-note-toolbar

Versão Testada

v1.34.12 (commit 520271c3027eb6da38bab10a686b21e14c664c13, 2026-07-29), contra Obsidian desktop 1.13.4 no Linux.

CVSS v3.1 Estimado

7.0 (Alto) — CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

• AV:L — o componente vulnerável (o avaliador JS do plugin, executando dentro do renderer Electron do Obsidian) não é voltado à rede; o payload chega como conteúdo local de cofre/arquivo sincronizado por qualquer meio que a vítima utilize (Git, Syncthing, Obsidian Sync, pasta compartilhada), consistente com descobertas anteriores desta família (por exemplo, obsidian-syncthing-integration, obsidian-codescript-toolkit).
• AC:H — a exploração depende de condições fora do controle do atacante que já devem existir na instalação da vítima: (1) a configuração "Scripting" do plugin já deve estar habilitada (desativada por padrão), e (2) a vítima já deve ter configurado um item de barra de ferramentas cujo rótulo, tooltip ou link seja uma referência {{prop_NAME}} pura a alguma chave de frontmatter. Ambas são padrões de uso realistas e documentados, mas nenhuma é o padrão.
• PR:N — o atacante não precisa de acesso ao sistema da vítima, apenas da capacidade de colocar uma nota no cofre da vítima com frontmatter controlado pelo atacante.
• UI:R — a vítima deve abrir/visualizar a nota específica; nenhum clique no item da barra de ferramentas é necessário, a barra de ferramentas é renderizada automaticamente.
• S:U, C:H/I:H/A:H — o código executa com acesso total ao Node.js (require('child_process'), sistema de arquivos, etc.) como a conta de usuário local que executa o Obsidian.

Detalhes

O Note Toolbar suporta uma variável documentada {{prop_NAME}} que substitui o valor de frontmatter de uma nota no rótulo, tooltip ou link de um item da barra de ferramentas (skills/note-toolbar-variables/SKILL.md, wiki Variables.md). Também suporta uma variável {{js: <expr>}} que avalia a expressão como JavaScript ativo quando a configuração "Scripting" do plugin está habilitada.

O bug está na ordem das operações em src/Toolbar/VariableResolver.ts::replaceVars():

1. Linhas 74–92: os placeholders {{prop_KEY}} são substituídos pelo valor bruto de frontmatter[KEY] da nota atual — incondicionalmente, independentemente da configuração scriptingEnabled, e independentemente da origem desse valor de frontmatter.
2. Linhas 94–104 (dentro de if (this.ntb.settings.scriptingEnabled)): a função então verifica s.trim().startsWith('{{js:') na string s já substituída, e se verdadeiro, remove o invólucro {{js:/}} e passa o restante para JavaScriptAdapter.use() para avaliação.

Como o passo 1 executa antes do passo 2 e reescreve s no local, um valor de frontmatter que ele mesmo começa com {{js: e termina com }} é promovido de "texto exibido" para "script executado" — mesmo que o item da barra de ferramentas nunca tenha sido criado como um item de script. O proprietário do item da barra de ferramentas apenas digitou {{prop_status}}; o payload executável vem inteiramente do próprio frontmatter da nota.

JavaScriptAdapter.evaluate() (src/Adapters/JavaScriptAdapter.ts:143-205) executa a expressão com um AsyncFunction real e sem sandbox:

src/Adapters/Adapter.ts:11
protected static readonly AsyncFunction = (Object.getPrototypeOf(async function(){}) as { constructor: typeof Function }).constructor;

src/Adapters/JavaScriptAdapter.ts:164
const func = new JavaScriptAdapter.AsyncFunction("input", expression);
...
result = await Promise.resolve((func as (...args: unknown[]) => unknown)(args));

Este é o construtor AsyncFunction genuíno do motor JS, não um interpretador/sandbox — dentro do renderer Electron do Obsidian isso tem acesso total a require()/Node.js, confirmado no PoC abaixo via require('child_process').execSync(...).

Crucialmente, o adaptador JS é integrado e não requer plugin complementar (src/Adapters/AdapterManager.ts:59: adapter = this.js; // built-in, doesn't rely on plugin), diferentemente dos prefixos de variável Dataview/Templater/JS-Engine que exigem esses plugins instalados. Apenas o próprio toggle "Scripting" do plugin (scriptingEnabled, padrão false, src/Settings/NoteToolbarSettings.ts:300) o controla.

Por fim, o caminho de renderização que dispara a substituição é automático, não condicionado a clique: ToolbarRenderer.ts::renderLItems() chama this.ntb.vars.resolveText(toolbar, file) (src/Toolbar/ToolbarRenderer.ts:418) toda vez que uma barra de ferramentas é renderizada para uma nota — ou seja, ao abrir/visualizar a nota — o que resolve o rótulo e o tooltip de cada item via replaceVars(). Nenhum clique no item da barra de ferramentas afetado é necessário.

A atribuição de barra de ferramentas para nota é ela mesma orientada por frontmatter (configuração toolbarProp, chave padrão notetoolbar, src/Settings/NoteToolbarSettings.ts:317), então uma nota sincronizada pode selecionar qual barra de ferramentas é renderizada nela — mas isso não é necessário para a exploração se a vítima já usa uma barra de ferramentas padrão ou mapeamento de pasta que inclua o item vulnerável.

Isso é distinto do risco que o próprio SECURITY.md do mantenedor documenta ("User scripts... executes JavaScript provided by the user... intentional and by design") — isso descreve um usuário criando conscientemente um item de barra de ferramentas {{js:}}, ou importando conscientemente uma configuração de barra de ferramentas compartilhada que contenha um. Aqui, o item da barra de ferramentas não é de forma alguma um item de script da perspectiva do configurador (é um rótulo simples de exibição de propriedade), e o payload executável chega via conteúdo/frontmatter comum de nota — o mesmo modelo de ameaça de conteúdo de cofre não confiável que outras descobertas de execução de código de sincronização/configuração do Obsidian (obsidian-syncthing-integration, obsidian-codescript-toolkit).

Prova de Conceito

Verificado dinamicamente contra uma instância real do Obsidian 1.13.4 desktop (Xvfb + fluxbox), carregando o plugin real compilado (main.js compilado a partir do código-fonte auditado), não uma extração de função isolada.