squeeze440/supernote-obsidian-plugin-pocPoC — Path Traversal über bösartige Gerätesynchronisierung im Supernote Obsidian-Plugin (GHSA-3gx3-r874-5pp4, CVE-2026-86999, CVSS 5.6).
CVE-Status: beantragt, Zuweisung ausstehend. Dieser Fund wird als GHSA-3gx3-r874-5pp4 veröffentlicht. Bei der CVE-Zuweisung wird dieses Repository in
CVE-YYYY-NNNNN-supernote-obsidian-plugin-PoCumbenannt und dieser Banner durch den CVE-Link ersetzt.
| Forscher | Dostxodjayev Abdullox (@squeeze440) |
| Advisory | GHSA-3gx3-r874-5pp4 |
| CVSS 3.1 | 5.6 (Mittel) |
| Schwäche | CWE-22, CWE-73 |
Path Traversal in der Auto-Sync-Funktion des Supernote (Unofficial) Obsidian-Plugins (philips/supernote-obsidian-plugin) v2.9.1 ermöglicht es einem bösartigen oder kompromittierten „Supernote"-Gerät (oder einem On-Path-/On-LAN-Angreifer, der die IP des gekoppelten Geräts imitiert), den Obsidian-Client des Opfers dazu zu bringen, eine beliebige neue Datei überall dort zu schreiben, wo der Desktop-Prozess Schreibzugriff hat — einschließlich außerhalb des konfigurierten Sync-Ordners und außerhalb des Vaults selbst — über ein manipuliertes uri-Feld in der Verzeichnisauflistungsantwort des Geräts.
philips/supernote-obsidian-plugin („Supernote (Unofficial)"), ein Obsidian.md-Community-Plugin, das die Notizen eines physischen Supernote-E-Ink-Geräts über den lokalen „Browse and Access"-HTTP-Server des Geräts (http://<device-ip>:8089, ohne Authentifizierung, bedingt durch das Design der Gerätefunktion) in einen Vault synchronisiert.
48db5bf4dcfb100632c84699c830c1309da1abb9supernote-typescript: Commit 195415b3a1f74147... (selbst nicht betroffen — der Fehler liegt vollständig im eigenen Sync-Planungscode des Plugins)5.6 Mittel — CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:N
AV:A — der HTTP-Server des Geräts ist unverschlüsselt, unauthentifiziert und wird durch eine bloße IPv4-Adresse konfiguriert (IP_VALIDATION_PATTERN, src/settings.ts:6); um ihn als „das Gerät" zu erreichen, ist eine LAN-nahe Netzwerkposition erforderlich (Rogue AP, ARP-Spoofing oder Beanspruchung der IP), kein beliebiger Fernzugriff.AC:H — die Ausnutzung hängt davon ab, dass der Angreifer diese Netzwerkposition bereits einnimmt, wenn das Plugin des Opfers mit directConnectIP:8089 kommuniziert; es ist kein einmaliger Fernauslöser.UI:R — erfordert, dass das Opfer „Sync supernote notes now" ausführt (oder dass der Auto-Sync-Schalter bereits aktiviert ist), während es auf den angreiferkontrollierten Endpunkt zeigt.S:C — die verwundbare Komponente ist ein Vault-gebundenes Obsidian-Plugin; der Schreibvorgang landet vollständig außerhalb des Vaults, auf dem zugrunde liegenden Host-Dateisystem, was einen anderen Sicherheitsbereich darstellt.C:N — dies ist ein reines Schreib-Primitiv; nichts wird an den Angreifer zurückgelesen.I:H — angreiferkontrollierte Bytes landen an einem vom Angreifer gewählten Pfad mit einem vom Angreifer gewählten Dateinamen. Eingeschränkter Vorbehalt: writeBinaryAt() (src/syncEngine.ts:40-47) nimmt den Erstellungs-Zweig nur für Pfade, die nicht bereits im eigenen Sync-Manifest des Plugins erfasst sind, und Obsidians Vault.createBinary() weigert sich selbst, eine Datei stillschweigend zu überschreiben, die bereits physisch am aufgelösten Pfad existiert (empirisch bestätigt — siehe PoC) — es handelt sich also um „eine neue Datei überall platzieren", nicht um „jede vorhandene Datei überschreiben".A:N — keine Auswirkung auf die Verfügbarkeit nachgewiesen.runDeviceSync() (src/syncEngine.ts:100-196) listet die Dateien des gekoppelten Geräts über scanDeviceSupernoteTree() (src/FileListModal.ts:53-68) auf, das die eigene HTTP-Verzeichnisauflistung des Geräts rekursiv durchläuft und jeden Eintrag behält, dessen name mit /\.(note|spd)$/i übereinstimmt (src/FileListModal.ts:46,63). Das uri-Feld jedes Eintrags — ein separates, unabhängig kontrolliertes String-Feld im selben vom Gerät zurückgegebenen JSON-Objekt — wird niemals gegen name oder irgendetwas anderes validiert.
Diese rohe uri wird dann direkt in deviceUriToVaultPath() (src/deviceSync.ts:153-161) eingespeist:
const INVALID_FILENAME_CHARS = /[\\:*?"<>|]/g; // deviceSync.ts:144
export function deviceUriToVaultPath(syncFolder: string, deviceUri: string): string {
const segments = deviceUri
.split('/')
.filter((s) => s.length > 0)
.map((s) => s.replace(INVALID_FILENAME_CHARS, '_'));
const cleanRoot = syncFolder.replace(/^\/+|\/+$/g, '');
return cleanRoot ? `${cleanRoot}/${segments.join('/')}` : segments.join('/');
}
INVALID_FILENAME_CHARS entfernt \ : * ? " < > |, entfernt oder verwirft jedoch niemals ..-Pfadsegmente. Eine Geräte-uri von /../../PWNED.txt überlebt unverändert und wird an den konfigurierten Sync-Ordner (Standard "Supernote sync") angehängt, um vaultPath = "Supernote sync/../../PWNED.txt" zu erzeugen.
syncEngine.ts:128 berechnet diesen vaultPath aus der rohen uri der Auflistung, dann übergeben ensureFolder()/writeBinaryAt() (syncEngine.ts:146-148, 21-47) ihn direkt an app.vault.getAbstractFileByPath() / createBinary() / modifyBinary() ohne Traversal-Prüfung. Obsidians eigene Pfadauflösung normalisiert dann die ..-Segmente gegen das reale Vault-Verzeichnis auf der Festplatte, wodurch der Schreibvorgang oberhalb des Sync-Ordners landet — und mit genügend ../-Segmenten oberhalb des Vault-Stammverzeichnisses, auf dem Host-Dateisystem, im Berechtigungsbereich des OS-Benutzers selbst.
Geschwisterprüfung: Jede andere Vault-Schreib-Senke in dieser Codebasis (src/main.ts — Screen-Mirror-Aufnahme, PDF/Markdown-Import, „attach to note", DownloadListModal in src/FileListModal.ts:245-246) erstellt ihren Zielpfad über Obsidians eigenes app.fileManager.getAvailablePathForAttachment(file.name), das ausschließlich das name-Feld des Geräts verwendet und auf diese Weise nicht ausnutzbar ist. deviceUriToVaultPath() in der neueren Auto-Sync-Funktion ist die einzige Senke, die stattdessen einen Pfad aus dem uri-Feld des Geräts von Hand zusammenbaut, und sie ist diejenige, die die ..-Bereinigung übersprungen hat — ein klarer Fall von „bei jedem Geschwister geprüft, nur bei diesem nicht".
Die eigene Einstellungs-UI des Plugins besagt: „The sync command never writes anywhere outside this folder" (src/settings.ts, Sync folder description) — dieser PoC widerlegt diese Garantie direkt.
Dynamisch end-to-end bestätigt gegen ein echtes, unverändertes Obsidian 1.13.4 Desktop-Binary (Xvfb + fluxbox + xdotool + scrot), das die tatsächlich kompilierte main.js des Plugins ausführt — kein Mocking des Plugin-Codes.
./scripts/build) und in einen frischen Test-Vault geladen (Supernote (Unofficial) v2.9.1, aktiviert über „Trust author and enable plugins").Supernote IP address auf 127.0.0.1 gesetzt, Sync folder beim Standard Supernote sync belassen.127.0.0.1:8089 aufgesetzt, der ein bösartiges/kompromittiertes Gerät simuliert. Seine Verzeichnisauflistung gibt zurück:
{"name":"Quick notes.note","size":61,"date":"2026-07-31 00:00:00",
"uri":"/../../PWNED_BY_DEVICE_SYNC.txt","extension":"note","isDirectory":false}
name besteht den .note-Erweiterungsfilter; uri trägt das Traversal.) Jedes GET wird mit 200 und den Dateibytes beantwortet — echte HTTP-Clients normalisieren .. aus dem ausgehenden Anfrage-Pfad heraus, bevor er auf die Leitung gelangt (RFC 3986), was hier irrelevant ist, da der verwundbare Code den Schreib-Pfad aus dem ursprünglichen JSON-String berechnet, nicht aus der normalisierten Anfrage-URL.PWNED_BY_DEVICE_SYNC.txt, die die Bytes des Angreifers enthält, wurde ein Verzeichnis oberhalb des Vault-Stammverzeichnisses erstellt (Geschwister von testvault/, vollständig außerhalb des Vaults). Die eigene data.json des Plugins zeichnete den berechneten Pfad wörtlich auf: "vaultPath": "Supernote sync/../../PWNED_BY_DEVICE_SYNC.txt".Belege (echte Aufnahmen, ~/engagements/supernote-obsidian-plugin/evidence/):
01-vault-escape-file-write.png — echtes Terminal: ls -la testvault/ PWNED_BY_DEVICE_SYNC.txt zeigt die Datei als Geschwister des Vault-Verzeichnisses, plus ihren angreiferkontrollierten Inhalt via cat.02-plugin-data-json-vaultpath.png — die eigene persistierte Sync-State-Datei des Plugins, die "vaultPath": "Supernote sync/../../PWNED_BY_DEVICE_SYNC.txt" aufzeichnet.03-plugin-settings-security-claim.png — die Einstellungs-UI des Plugins, die behauptet, der Sync-Befehl schreibe „never writes anywhere outside this folder".Ein Angreifer, der als das konfigurierte Supernote-Gerät des Opfers antworten kann (LAN-nah: Rogue AP, ARP-Spoofing oder Beanspruchung der IP des Geräts), kann den Obsidian-Client des Opfers dazu bringen, eine neue, angreiferkontrollierte Datei an jedem Dateisystempfad zu erstellen, an den der Desktop-Prozess schreiben kann — innerhalb des Vaults (z. B. eine brandneue Datei unter .obsidian/plugins/<new-id>/, als Grundlage für weiteren Plugin-Vertrauensmissbrauch) oder vollständig außerhalb (z. B. ~/.config/autostart/*.desktop, ein neuer Crontab-Drop-in oder jeder andere Ort, an dem eine neue Datei — kein Überschreiben — ausreicht, um Ausführung oder Persistenz zu erlangen). Es kann eine Datei, die bereits am aufgelösten Pfad existiert, nicht stillschweigend überschreiben (Obsidians createBinary wirft in diesem Fall „File already exists", empirisch bestätigt), was das Primitiv auf das Platzieren neuer Dateien statt auf universelles Überschreiben beschränkt.
uri bestimmt direkt das Ziel auf der Festplatte)In deviceUriToVaultPath() (src/deviceSync.ts:153-161) sollten ..- (und leere/.-only) Pfadsegmente nach dem Aufteilen von deviceUri verworfen oder entfernt werden, z. B.:
const segments = deviceUri
.split('/')
.filter((s) => s.length > 0 && s !== '.' && s !== '..')
.map((s) => s.replace(INVALID_FILENAME_CHARS, '_'));
Zusätzlich sollte scanDeviceSupernoteTree() (src/FileListModal.ts:63) validieren, dass die uri eines Auflistungseintrags mit seinem name konsistent ist (z. B. dass uri mit demselben Dateinamen endet), anstatt den beiden Feldern unabhängig zu vertrauen — dieselbe Art von Verteidigung, auf die sich überall sonst in der Codebasis bereits implizit verlassen wird, die Pfade nur aus name/basename über getAvailablePathForAttachment() erstellt.
Dostxodjayev Abdullox
In diesem Repository ist keine SECURITY.md vorhanden. GitHubs private Schwachstellenmeldung ist für philips/supernote-obsidian-plugin bestätigt aktiviert (gh api repos/philips/supernote-obsidian-plugin/private-vulnerability-reporting --jq .enabled → true; 0 zuvor veröffentlichte Security Advisories). Es gilt der Standard-GHSA-Ablauf: https://github.com/philips/supernote-obsidian-plugin/security/advisories/new.