CVE-2026-115477
WysokieCVSS 7.1Streszczenie
W obsidian-tc w wersjach od 1.13.0 do 1.31.4, wdrożenie Streamable HTTP z skonfigurowanym `auth.jwtSecret` pozwalało na obejście potwierdzenia człowieka przy wywołaniach narzędzi oznaczonych jako destrukcyjne. Serwer ufał ważnemu powiązanemu z wywołaniem `requestState` jako dowodowi zatwierdzenia, mimo że stan ten był tworzony przed zapytaniem `elicitation/create` i potwierdzał jedynie przynależność ponownego zgłoszenia do tego samego wywołania. Klient działający niepoprawnie lub pod kontrolą atakującego mógł wykonać destrukcyjne operacje na skarbcu bez zgody człowieka, zachowując zwykłe uprawnienia narzędzia.
Ocena ryzyka
Organizacja korzystająca z obsidian-tc w trybie Streamable HTTP z `auth.jwtSecret` może doświadczyć nieautoryzowanych, destrukcyjnych operacji na skarbcu Obsidian (np. nadpisania lub przeniesienia notatek) bez wiedzy i zgody użytkownika. Ryzyko dotyczy wyłącznie narzędzi oznaczonych `destructive: true` lub wymagających zakresu z wymogiem obecności człowieka.
Rekomendacja
Zaktualizuj obsidian-tc do wersji 1.31.4 lub nowszej. Jeśli aktualizacja nie jest możliwa, rozważ przejście na transport stdio albo usunięcie konfiguracji `auth.jwtSecret`, co wymusza użycie fallbacku `elicit_token` i eliminuje tę ścieżkę obejścia.
Inne podatności w obsidian-tc
Zobacz wszystkie- CVE-2026-115478Wysokie
W obsidian-tc (od 1.0.1 do 1.31.4) narzędzia create_entity, link_entities, rename_entity, unlink_entities i delete_entity regenerują notatki pamięci z SQLite pod ścieżką memory/<typ>/<nazwa>.md bez niezawodnego zachowania własności notatki, co może nadpisać całą treść ręcznie utworzonej notatki lub osieroconej notatki innej encji o tej samej znormalizowanej ścieżce. Ponadto kilka narzędzi modyfikuje SQLite przed operacjami na systemie plików, więc błąd zapisu może pozostawić niespójny graf pamięci względem notatek na dysku.
- CVE-2026-77366Krytyczne
W obsidian-tc przed wersją 1.3.1 dyspozytor narzędzi nie porównuje wartości input.vault kontrolowanej przez wywołującego z sejfem przypisanym do wywołującego, token JWT nie zawiera roszczenia vault, a lista kontroli dostępu do folderów jest współdzielona globalnie. Każdy ważny token może wybrać inny skonfigurowany sejf i odczytywać, zapisywać lub usuwać jego zawartość.
- CVE-2026-77362Średnie
obsidian-tc przed wersją 1.3.1 nie stosuje spójnie listy kontroli dostępu (ACL) do wszystkich zwracanych pól. Narzędzie tasks_filter ujawnia liczby grup pochodzące z niedozwolonych notatek, makemd_query przekazuje nieprzefiltrowane pola wynikowe, a list_templates ujawnia ścieżki szablonów i treści funkcji użytkownika bez sprawdzenia białej listy odczytu. Uwierzytelniony wywołujący może wywnioskować lub odczytać dane z notatek spoza swojej listy ACL.
- CVE-2026-77361Średnie
obsidian-tc przed wersją 1.3.1 sprawdza listę kontroli dostępu (ACL) na podstawie leksykalnej ścieżki względem katalogu, podczas gdy sprawdzenia zawierania używają ścieżki rozwiązanej. Dowiązanie symboliczne w katalogu, które jest dozwolone przez glob, ale wskazuje na zabroniony folder, może ominąć ACL i ujawnić pliki w zabronionym folderze. Wykorzystanie wymaga dowiązania symbolicznego umieszczonego poza pasmem i nie pozwala na wyjście poza katalog główny.
- CVE-2026-77364Średnie
obsidian-tc to zarządzany serwer Model Context Protocol dla sejfów Obsidian. W wersjach przed 1.3.1 niezdefiniowane ustawienia readPaths i writePaths zezwalają na wszystkie ścieżki, strictReadDefault nie chroni bezpośrednich żądań, a katalogi kontrolne .obsidian, .git i .trash są wykluczane tylko podczas enumeracji. Uwierzytelniony wywołujący może bezpośrednio odczytać wrażliwe pliki, takie jak .obsidian/plugins/*/data.json.
- CVE-2026-77363Wysokie
Podatność w obsidian-tc, serwerze Model Context Protocol dla vaultów Obsidian, przed wersją 1.3.1, nie waliduje nagłówków Host lub Origin ani nie włącza ochrony przed DNS-rebinding w transporcie Streamable HTTP. Przy konfiguracji loopback z auth.mode ustawionym na none, złośliwa strona internetowa może wysyłać żądania do lokalnego punktu końcowego MCP i uzyskać nieograniczony dostęp do vaultu przez wywołanie http-local. Wersja 1.3.1 naprawia problem poprzez włączenie walidacji hosta, origin i DNS-rebinding.
Oryginalny opis (angielski, źródło NVD)
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. From 1.13.0 until 1.31.4, on a Streamable HTTP deployment with `auth.jwtSecret` configured and a 2026-07-28-era client declaring `elicitation.form` support, a dispatch-gated tool call offered an `inputRequired` confirmation could still complete after the human declined or cancelled, or the elicitation response was omitted or malformed, provided the client echoed the validly bound `requestState` on resubmission. The server trusted an authentic, call-bound state as proof of approval even though that state was minted before the `elicitation/create` leg was asked and proved only that the resubmission belonged to the same call. A client behaving incorrectly or under an attacker's control could therefore execute dispatch-gated destructive vault operations without the human's approval, while still requiring the caller's ordinary tool permissions. Only tools marked `destructive: true` or requiring a scope with a human-in-the-loop floor were reachable through this bypass. The sixteen handler-side conditionally gated tools, including `write_note` overwrite and `move_note`, did not read elicitation state on the modern wire and let neither approval nor decline through that path. Affected deployments using stdio or leaving `auth.jwtSecret` unset instead used the CLI `elicit_token` fallback and did not offer this `requestState` round trip. The fix does not prevent a malicious client from reporting a fabricated approval, because the server cannot verify that the client displayed the form or that a human saw it. This issue is fixed in version 1.31.4.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS