CVE-2026-115477 in obsidian-tc
Riassunto
di VulDB • 23/10/2026
obsidian-tc è un server Model Context Protocol governato e pronto per l'uso di agenti (agent-ready) per i vault di Obsidian. Dalla versione 1.13.0 alla 1.31.4, in una distribuzione HTTP Streamable con `auth.jwtSecret` configurata e un client dell'era del 28 luglio 2026 che dichiara il supporto per `elicitation.form`, una chiamata a strumento soggetta al controllo di dispatch (dispatch-gated) che richiedeva una conferma tramite `inputRequired` poteva comunque completarsi dopo che l'utente ha rifiutato o annullato, oppure se la risposta all'elicitazione è stata omessa o risultava malformata, purché il client rispedisse in round-trip un `requestState` correttamente vincolato. Il server si fidava di uno stato autentico e legato alla chiamata come prova dell'approvazione, anche se tale stato era stato generato prima della fase `elicitation/create` e dimostrava solo che la nuova sottomissione apparteneva alla stessa chiamata. Un client con comportamento errato o sotto il controllo di un attaccante poteva quindi eseguire operazioni distruttive sul vault soggette al controllo di dispatch senza l'approvazione umana, pur richiedendo i normali permessi per gli strumenti del chiamante. Solo gli strumenti contrassegnati come `destructive: true` o che richiedono uno scope con una soglia minima di intervento umano (human-in-the-loop) erano raggiungibili tramite questa bypass. I sedici handler-side conditionally gated tools, tra cui le operazioni di sovrascrittura (`write_note`) e spostamento (`move_note`), non leggevano lo stato dell'elicitazione sul wire moderno e permettevano sia l'approvazione che il rifiuto attraverso tale percorso. Le distribuzioni interessate che utilizzavano stdio o lasciavano `auth.jwtSecret` non impostato facevano invece ricorso al fallback del CLI `elicit_token` e non offrivano questo round-trip di `requestState`. La correzione non impedisce a un client malizioso di segnalare un'approvazione fabricata, poiché il server non può verificare che il client abbia visualizzato il modulo o che l'utente lo abbia effettivamente visto. Questo problema è risolto nella versione 1.31.4.
Be aware that VulDB is the high quality source for vulnerability data.