squeeze440/zotlit-pocPoC — l'importazione degli allegati copia file da percorsi locali non approvati in ZotLit (GHSA-4qh7-66xv-h329, CVE-2026-87000, CVSS 5.5).
Stato CVE: richiesto, in attesa di assegnazione. Questa segnalazione è pubblicata come GHSA-4qh7-66xv-h329. All'assegnazione del CVE questo repository viene rinominato
CVE-YYYY-NNNNN-zotlit-PoCe questo banner viene sostituito con il link al CVE.
| Ricercatore | Dostxodjayev Abdullox (@squeeze440) |
| Advisory | GHSA-4qh7-66xv-h329 |
| CVSS 3.1 | 5.5 (Medium) |
| Debolezza | CWE-73, CWE-200 |
Sommario
Il controllo esterno del nome file o del percorso nella funzionalità di importazione degli allegati in AidenLx ZotLit (aidenlx/zotlit) 1.1.12 consente a un attaccante che controlla una libreria Zotero condivisa/sincronizzata di divulgare file locali arbitrari dal filesystem della vittima all'interno del vault Obsidian della vittima tramite un percorso di allegato linked_file appositamente creato.
Prodotto
ZotLit — plugin Obsidian per l'integrazione con Zotero (aidenlx/zotlit, id plugin zotlit, versione manifest 1.1.12)
Versione testata
Git commit 41e60aaa6178629b34f8a42d104e757594b72435 (2026-07-31)
CVSS v3.1 stimato
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — 5.5 (Medium)
Metriche non ovvie: AV:L — lo sfruttamento avviene quando il processo locale Obsidian/zotlit della vittima elabora metadati di elementi Zotero forniti dall'attaccante (veicolati tramite una libreria condivisa/sincronizzata), la stessa convenzione usata per i bug di tipo "file malevolo elaborato da un'app locale", anche se la consegna stessa può avvenire su rete (libreria di gruppo condivisa, file di esportazione inviato via email). UI:R — la vittima deve importare/sincronizzare la libreria malevola in Zotero ed eseguire la funzione di importazione note di ZotLit (o l'incorporamento di annotazioni/citazioni) su una nota che fa riferimento all'allegato appositamente creato; si tratta di un uso ordinario della funzionalità principale del plugin, abilitata di default (attachment.import è true di default), non di un'azione insolita. I:N/A:N — questa segnalazione è solo una primitiva di lettura/copia; non viene rivendicato alcun path traversal lato destinazione (vedere Dettagli per un'osservazione correlata ma non verificata).
Dettagli
ZotLit legge i metadati degli allegati direttamente dal database SQLite di Zotero (o da una libreria sincronizzata/condivisa), inclusa la colonna di testo libero itemAttachments.path, e si fida completamente di essa quando determina da dove leggere un allegato "linked":
packages/db/src/lib/zt-path.ts:62-63 — attachmentAbsPath(), caso "linked-absolute":
case "linked-absolute":
return parsed.path;
Per le righe con linkMode: 2 (linked_file) il cui path non contiene il segnaposto della directory base attachments:, parsed.path è la stringa grezza del DB restituita testualmente come percorso assoluto del filesystem da leggere — nessuna allowlist, nessun confinamento alla directory dati di Zotero o a qualsiasi posizione approvata dall'utente.
packages/db/src/lib/context/zt-template-attach.ts:101-106 — attachmentFilename(), caso "linked-absolute":
case "linked-absolute":
return basename(path.path);
Il nome file usato per costruire la copia nel vault deriva da quello stesso percorso controllato dall'attaccante tramite basename(), quindi il nome file di destinazione è influenzato dall'attaccante ma privo di separatori di percorso (sicuro rispetto al traversal su questo ramo).
apps/obsidian/src/services/note-import/note-parser.ts:403-430 — resolveEmbeddedImage() viene invocata durante la conversione di un'annotazione immagine incorporata in una nota bibliografica Zotero in Markdown Obsidian (un'azione ordinaria e predefinita della funzionalità "Import Note" di ZotLit). Risolve sourcePath = attachmentAbsPath(attachment, ...) e chiama deps.resolveLink({ sourcePath, vaultName: \${attachment.key}-${filename}` })` — accodando una copia di qualsiasi percorso assoluto scelto dall'attaccante nel vault.
apps/obsidian/src/services/attachment-import/service.ts:125-155 — AttachmentImportBatch.resolveLink() accoda { source: sourcePath, dest: <vault attachment folder>/<key>-<filename> }, vincolato solo dall'impostazione attachment.import, il cui default è true (apps/obsidian/src/services/settings/schema.ts:123).
apps/obsidian/src/lib/copy-attachments.ts:43-60 — copyAttachment() esegue la lettura+scrittura effettiva senza alcuna validazione del percorso: stat(source) poi copyFile(source, dest).
Effetto netto: un attaccante che riesce a inserire un elemento Zotero linked_file (linkMode 2) nella libreria della vittima — ad esempio una libreria di gruppo Zotero condivisa, un'esportazione .rdf/.json/Better BibTeX che la vittima importa, o una libreria sincronizzata su cui l'attaccante ha accesso in scrittura — può impostare il percorso dell'allegato di quell'elemento su qualsiasi file sul disco della vittima (~/.ssh/id_rsa, archivi di credenziali del browser, altri vault, file .env, ecc.). Nel momento in cui la vittima esegue l'importazione note di ZotLit (o visualizza/incorpora quell'annotazione) con l'impostazione predefinita attachment.import: true, ZotLit copia silenziosamente il contenuto di quel file nel vault Obsidian della vittima con un nome prevedibile (<attachmentKey>-<basename>). Poiché i vault vengono abitualmente sincronizzati, sottoposti a commit git o pubblicati, questo sposta dati che l'attaccante non potrebbe altrimenti raggiungere in una posizione che l'attaccante (o chiunque altro con accesso alla destinazione di sincronizzazione) può leggere.
Osservazione correlata, non verificata (non fa parte del PoC di questa segnalazione): il ramo gemello "storage" di attachmentFilename() (zt-template-attach.ts:103-104) restituisce il suffisso di percorso grezzo senza la chiamata basename() applicata agli altri due rami. Se questo sia sfruttabile in modo indipendente dipende da come il meccanismo di sincronizzazione dello storage di Zotero stesso nomina i file scaricati localmente, cosa che esula da questo repository e non è stata verificata — segnalato qui solo come lacuna di hardening che varrebbe la pena chiudere per coerenza.
Proof of Concept
Verifica dinamica: le funzioni vulnerabili esatte (parseAttachmentPath, attachmentAbsPath, attachmentFilename, copyAttachments/copyAttachment/writeCopy/destMatches, isErrno, reflink) sono state estratte testualmente (con file:riga citati sopra, logica invariata) dal sorgente distribuito ed eseguite direttamente in Node, poiché in questa sandbox non era disponibile un'installazione completa offline del workspace pnpm (toolchain corepack/pnpm non funzionante offline). L'unica sostituzione è stata scambiare la chiamata al logger LogTape con console.warn — puramente cosmetico, nessun effetto sul flusso di controllo. Script: ~/engagements/zotlit/evidence/poc-verify.mjs.