obsidian-tc: Zugriff auf fremde Vaults über das Tool-Argument vault
Zusammenfassung
obsidian-tc ist ein Model Context Protocol Server, der KI-Agenten Zugriff auf Obsidian Vaults gibt. Vor Version 1.3.1 konnte jeder gültige Token im Argument vault von Tool-Aufrufen einen anderen konfigurierten Vault angeben und dessen Inhalte lesen, schreiben oder löschen, da der Token nicht an einen Vault gebunden war und die Ordner-Zugriffsliste global galt. Voraussetzung sind ein gültiger Token und ein Server mit mehreren konfigurierten Vaults, der über den HTTP-Transport erreichbar ist; der CVSS-Basiswert gemäss CNA-Eintrag ist 9.9 (kritisch).
Betroffen
- obsidian-tc Versionen unterhalb 1.3.1 (npm-Paket)
- Deployments mit mehreren Vaults sind am stärksten gefährdet
- Deployments mit einem einzigen Vault sind kaum von vaultübergreifendem Zugriff betroffen (Ableitung)
Behoben in
- Behoben in 1.3.1 (erste veröffentlichte Version mit dem Fix)
- Spätere Releases der 1.3-Linie enthalten den Fix ebenfalls; die aktuelle npm-Version vor dem Upgrade prüfen
- Fix-Commit 38b4992
Umgehung
- Unbekannt. Kein vom Hersteller bestätigter Workaround. Ungeprüfter Drittquellentext empfiehlt, pro Server-Prozess nur einen Vault zu betreiben.
- Die Anzahl der Personen mit gültigen Token einschränken und den HTTP-Transport deaktivieren, falls er nicht benötigt wird (eigene Ableitung, keine Herstellerempfehlung).
Ausnutzung
- Zum Analysezeitpunkt wurden kein öffentlicher Proof of Concept und keine Ausnutzung in freier Wildbahn gefunden.
- CISA SSVC: Ausnutzung keine, automatisierbar nein, technische Auswirkung total.
- EPSS 0.00309 (niedrig).
Unsere Empfehlung
- Prüfen, ob eine obsidian-tc-Instanz mit einer Version unterhalb 1.3.1 läuft (npm ls, Container-Image-Tags, CLI-Version).
- Auf das aktuelle Release upgraden, nicht nur auf 1.3.1, und gegen die npm-Registry verifizieren.
- Prüfen, ob der HTTP-Transport aktiviert ist oder über localhost hinaus erreichbar ist; deaktivieren oder mit Authentifizierung und Netzwerkkontrollen einschränken, falls nicht benötigt.
- Nach dem Upgrade bei Deployments mit mehreren Vaults Token mit einem vault-Claim pro Vault ausstellen; Token ohne Claim sind auf den Standard-Vault beschränkt.
- Logs auf Anfragen prüfen, bei denen das Argument vault vom Vault des Tokens abweicht, sofern Protokollierung vorhanden ist.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- GitHub Security Advisory GHSA-84c9-qqpq-2pq5 github.com
- Fix commit 38b4992 github.com
- Pull Request #72 github.com
- Release v1.3.1 github.com
- GitLab Advisory CVE-2026-77366 advisories.gitlab.com
- OSV CVE-2026-77366 osv.dev
- VulDB 417139 vuldb.com
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 30.10.2026 15:31.
Referenzen der NVD (4)
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.