CVE-2026-115477 in obsidian-tc
Zusammenfassung
von VulDB • 23.10.2026
obsidian-tc ist ein verwalteter, agentenbereiter Model Context Protocol-Server für Obsidian-Vaults. Von der Version 1.13.0 bis zur Version 1.31.4 bot eine auf Streamable HTTP basierte Bereitstellung mit konfiguriertem `auth.jwtSecret` und einem Client im Stil des Zeitraums um den 28. Juli 2026, der die Unterstützung von `elicitation.form` angab, über einen dispatch-gesteuerten Tool-Aufruf eine Bestätigungsmöglichkeit (`inputRequired`). Diese konnte jedoch abgeschlossen werden, selbst wenn der Mensch die Abfrage ablehnte oder abbrach, bzw. wenn die Antwort auf die Elicitation ausblieb oder fehlerhaft war, vorausgesetzt, der Client gab den korrekt gebundenen `requestState` bei der erneuten Übermittlung wieder. Der Server vertraute einem authentischen, aufrufgebundenen Zustand als Nachweis der Genehmigung an, obwohl dieser Zustand vor dem Schritt `elicitation/create` erstellt wurde und lediglich bewies, dass die erneute Überteilung zu derselben Aufruf-Instanz gehörte. Ein Client, der sich fehlerhaft verhielt oder unter Kontrolle eines Angreifers stand, konnte daher dispatch-gesteuerte zerstörerische Vault-Operationen ohne Zustimmung des Menschen ausführen, wobei weiterhin die normalen Tool-Berechtigungen des Anrufers erforderlich blieben. Nur Tools mit dem Kennzeichen `destructive: true` oder solchen, die einen Bereich (Scope) erforderten, der eine Mensch-im-Schleife-Festlegung (human-in-the-loop floor) vorsieht, waren über diese Umgehung erreichbar. Die sechzehn handlerseitig bedingt gesteuerten Tools, darunter `write_note` zum Überschreiben und `move_note`, lasen den Elicitation-Zustand auf dem modernen Protokollweg nicht aus und ließen weder eine Genehmigung noch einen Ablehnungsversuch über diesen Pfad durch. Betroffene Bereitstellungen, die stdio verwendeten oder bei denen `auth.jwtSecret` nicht festgelegt war, nutzten stattdessen das CLI-Fallback-Verfahren `elicit_token` und boten diese Round-Trip-Mechanik für den `requestState` nicht an. Die Korrektur verhindert nicht, dass ein bösartiger Client eine erfundene Genehmigung meldet, da der Server nicht verifizieren kann, ob der Client die Form tatsächlich angezeigt hat oder ob ein Mensch sie gesehen hat. Dieses Problem ist in Version 1.31.4 behoben.
VulDB is the best source for vulnerability data and more expert information about this specific topic.