MaxKB: il percorso di dispatch dell’agente consente a un utente a cui è stato negato l’accesso a uno strumento di chiamarlo comunque e di leggerne le credenziali

MaxKB, l'assistente AI aziendale open-source mantenuto da 1Panel-dev, fornisce un elenco di autorizzazioni per utente e per strumento, così che un amministratore possa concedere a un membro del workspace uno strumento e negarne un altro. Secondo l'avviso di sicurezza pubblicato il 2 settembre 2026, tale diniego veniva applicato sulle rotte proprie dello strumento ma non sul percorso che un agente o un workflow utilizza per chiamare lo stesso strumento. Un membro del workspace con il ruolo più basso poteva indicare l'identificatore di uno strumento negato durante la creazione di un workflow, eseguire il workflow e ricevere non solo l'output dello strumento ma anche le credenziali che MaxKB decifra lato server per eseguirlo. Le versioni dalla 2.0.0 alla 2.9.2 sono interessate, e l'avviso non indicava alcuna versione corretta. Questo record — il bypass dell'autorizzazione nel dispatch degli strumenti di MaxKB — è una voce dell'OrcaRouter AI Incident Archive, che contiene l'insieme completo dei record e le voci adiacenti a questo incidente.

Ciò che rende il caso meritevole di una lettura attenta non è il punteggio. È che il prodotto aveva già il controllo giusto, lo applicava alla porta ovvia e lasciava senza sorveglianza una seconda porta verso la stessa funzionalità. L'avviso, GHSA-383v-fx78-pphm, è stato scritto dal ricercatore che ha individuato la falla e pubblicato tramite il sistema di avvisi di GitHub alle 07:43 UTC del 2 settembre 2026, attribuendo il merito a Matteo Panzeri (@matte1782). Il record CVE, CVE-2026-77516, è seguito il 21 settembre 2026.

Cosa stabilisce l'avviso

Il modello per-tool di MaxKB è WorkspaceUserResourcePermission, descritto nell'advisory come una allow-list con negazione predefinita risolta al momento della richiesta. Le route dedicate degli strumenti la applicano. L'advisory elenca l'applicazione in apps/tools/views/tool.py, dove Operate.put, Operate.get, Debug.post, Export.get e Delete presentano ciascuno un controllo dei permessi di visualizzazione rispetto al permesso dello strumento dell'area di lavoro del chiamante. Debug.post è la route più vicina alla semplice esecuzione di uno strumento, ed è protetta.

Il percorso di dispatch dell'agente e del workflow non riapplica quel controllo. L'advisory individua tre punti distinti in cui esso viene a mancare. In apps/application/serializers/application.py, il serializer dell'applicazione associa tool_ids, skill_tool_ids e mcp_tool_ids direttamente dall'input della richiesta senza autorizzazione per singolo tool — e l'advisory sottolinea che l'asimmetria è visibile nello stesso file, poiché knowledge_id_list viene validato rispetto alle basi di conoscenza accessibili all'utente poche righe più sotto, mentre i tool no. In apps/common/utils/shared_resource_auth.py, filter_authorized_ids lascia passare incondizionatamente ogni tool nel workspace del chiamante; il controllo cross-workspace su cui si basa è un hook disponibile solo nell'edizione enterprise, assente nell'edizione community, e non consulta mai WorkspaceUserResourcePermission. E al sink, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py esegue il codice memorizzato del tool con i suoi init_params decifrati da rsa_long_decrypt sotto l'identità dell'applicazione, senza alcun controllo di autorizzazione per singolo tool.

L'avviso definisce il risultato un'esecuzione confused-deputy: il dispatch del workflow esegue uno strumento, e i relativi segreti archiviati, a cui lo stesso chiamante non ha accesso sulle route proprie dello strumento. L'esposizione delle credenziali è la parte che va oltre il normale uso non autorizzato di uno strumento. Di uno strumento, gli init_params sono crittografati a riposo con RSA e decifrati lato server solo al momento dell'esecuzione, quindi un chiamante che attiva tale esecuzione riceve valori che non ha mai posseduto e che non avrebbe potuto fornire.

La dimostrazione, nei numeri dello stesso ricercatore

L'avviso riporta una conferma dinamica su v2.9.2, eseguita dall'immagine ufficiale all-in-one, 1panel/maxkb:v2.9.2. La configurazione prevedeva un workspace, un amministratore e un secondo membro con ruolo USER. L'amministratore ha creato Tool A e Tool B, ha inserito un nuovo segreto casuale in init_params di Tool B e ha scritto il corpo di Tool B in modo che restituisse quel segreto quando eseguito. Al membro è stata poi concessa un'autorizzazione per singolo strumento solo per Tool A, e l'avviso afferma che lo stato di zero autorizzazioni per Tool B è stato ricontrollato nel database dopo l'esecuzione.

La metà negata del test ha restituito ciò che il prodotto promette. Come membro, la route di debug per Tool B ha risposto 403, la route di aggiornamento ha risposto 403, la route di esportazione ha risposto 403 e Tool A autorizzato ha restituito 200 come verifica di sanità. La metà di bypass ha quindi associato Tool B a un'applicazione workflow tramite un nodo tool-library — l'associazione è stata accettata con HTTP 200 e nessun controllo per singolo tool — e l'esecuzione del workflow ha restituito HTTP 200 con un corpo contenente il nome del tool, il segreto sentinella e l'elenco delle chiavi ["api_key"].

L'avviso afferma che il segreto è emerso a tre livelli: nella risposta dell'API del workflow, in un record di esecuzione dello strumento con stato SUCCESS e nella riga del database in cui init_params di Tool B si trova come testo cifrato RSA di 344 byte — ed è così che il ricercatore sostiene che il valore sia stato decifrato lato server con l'identità dell'applicazione anziché fornito dal chiamante. Lo stesso membro a cui è stato negato l'accesso alla route di esecuzione dello strumento ha ottenuto il segreto decifrato dello strumento legandolo a un workflow.

Un punteggio pubblicato, uno più alto sostenuto

Il punteggio associato a CVE-2026-77516 è CVSS 3.1 5.4, Medio, con il vettore AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Il record di NVD mostra che tale punteggio proviene dal feed degli avvisi di GitHub anziché dall'analisi propria di NVD, e la voce riporta lo stato Deferred, il che significa che NVD non l'ha arricchita. La classificazione dell'archivio segue quel punteggio pubblicato: gravità media, nessun danno documentato nel mondo reale.

La sezione stessa dell'avviso dedicata all'impatto sostiene che serve di più. Indica una severità di 7.1, Alta, su un vettore che innalza a alto l'impatto sulla riservatezza, e afferma che il valore sale a 8.1 quando lo strumento distribuito esegue scritture privilegiate con l'identità dell'applicazione. Si tratta di un disaccordo su come conteggiare l'esposizione delle credenziali, non sull'esistenza del bypass: lo stesso documento da un lato dimostra la falla e dall'altro sostiene che la sua gravità viene sottovalutata. Nulla nella documentazione pubblica chiarisce quale valore sia corretto, e la valutazione media dell'archivio segue il punteggio CVE pubblicato anziché l'argomentazione dell'avviso.

Agli atti risultano due ulteriori valutazioni. I punti decisionali SSVC della CISA, aggiunti alla voce NVD il {{1}}28 settembre 2026{{/1}}, registrano lo sfruttamento come "{{2}}poc{{/2}}", l'automatizzabilità come "{{3}}no{{/3}}" e l'impatto tecnico come "{{4}}partial{{/4}}" — il valore "{{5}}poc{{/5}}" riflette l'esistenza di una proof of concept, che effettivamente è presente nell'advisory stesso; non è una constatazione di sfruttamento in the wild. Il modello EPSS di FIRST ha posto la probabilità di sfruttamento nei prossimi 30 giorni a {{6}}0,242%{{/6}}, al {{7}}15,2° percentile{{/7}}, nella stima datata {{8}}27 ottobre 2026{{/8}}.

Una correzione che precede l'avviso, e nessuna all'interno dell'intervallo interessato

La tabella delle versioni dell'advisory indica che le versioni interessate vanno dalla 2.0.0 alla 2.9.2, che non esistono versioni corrette e il suo testo afferma che, al momento della revisione, non è disponibile alcuna versione corretta, aggiungendo che una correzione in una release con tag consentirebbe a una CVE di ancorarsi ad essa. Il repository del fornitore racconta una storia leggermente diversa, e la differenza conta per chiunque debba decidere cosa eseguire.

Nel repository MaxKB, le funzioni che chiudono il percorso di dispatch — validate_bound_tool_permissions e get_authorized_tool_ids in apps/application/serializers/application.py — sono assenti dal tag v2.9.2 e da v2.10.2-lts, v2.10.3-lts e v2.10.4-lts, e presenti a partire da v2.10.5-lts. Quella release è stata pubblicata il 6 agosto 2026, quattro settimane prima dell'advisory. Lo stesso tag aggiunge a base_tool_lib_node.py un controllo degli strumenti per utente, basandosi su WorkspaceUserResourcePermission, e aggiunge a shared_resource_auth.py un filtro che tiene conto dell'utente — vale a dire che implementa, in linea di massima, i tre passaggi correttivi che l'advisory raccomanda in seguito.

Nessuno ha dichiarato pubblicamente questo nesso. Le note di rilascio della v2.10.5-lts non menzionano una correzione delle autorizzazioni degli strumenti; elencano quattro elementi di sicurezza non correlati e una serie di interventi su funzionalità e bug. L'avviso non cita la 2.10.5 e il suo intervallo interessato si ferma semplicemente alla 2.9.2, l'ultima versione della linea 2.9. La cronologia delle release non mostra alcuna patch 2.9.x successiva all'avviso, quindi un'installazione su 2.9.2 non dispone di alcuna build corretta all'interno della propria linea. La versione corrente è la v2.10.8-lts, pubblicata il 22 ottobre 2026, le cui note descrivono correzioni X-Pack all'autorizzazione degli strumenti condivisi anziché qualsiasi cosa nel percorso di dispatch dell'edizione community.

Che cosa non è stabilito

Tre cose vanno tenute distinte dalla dimostrazione. In primo luogo, non esiste alcun rapporto pubblico secondo cui l'aggiramento sia stato usato contro qualcuno. Quello che risulta è una vulnerabilità trovata, non un'intrusione oggetto di indagine; non ha vittime, né attori attribuiti, né danni, e la proof of concept dell'avviso è stata eseguita dal ricercatore in un ambiente di lavoro controllato. In secondo luogo, nessuna testata giornalistica, autorità di regolamentazione o secondo team di ricerca sembra aver analizzato la falla: la copertura esistente è confinata a database e aggregatori di vulnerabilità — tra cui VulDB, il database di Rapid7, Armis, SOCRadar e openCVE — che elencano la CVE e riportano la descrizione dell'avviso, e nessuno dei quali offre una valutazione indipendente del codice. Il meccanismo descritto qui, pertanto, si basa su un unico avviso e sul codice sorgente dello stesso fornitore. In terzo luogo, non esiste alcun dato su quante installazioni di MaxKB rientrino nell'intervallo interessato, e né il fornitore né il ricercatore ne hanno pubblicato uno.

La popolazione a rischio è ristretta ma non banale da conteggiare: installazioni MaxKB self-hosted in edizione community dalla 2.0.0 alla 2.9.2 con più di un membro del workspace, in cui un amministratore ha usato le autorizzazioni per singolo strumento per negare uno strumento che contiene credenziali. La falla non è un'esecuzione di codice da remoto e richiede un account valido con privilegi bassi, motivo per cui è l'impatto sulla riservatezza a determinare il punteggio anziché il percorso di attacco. Ciò che un attaccante ottiene è limitato da ciò che contengono gli strumenti negati — chiavi API, token e tutto ciò che questi sbloccano — ed è anche per questo che gli autori dell'avviso sostengono che l'impatto sia maggiore di quanto implichi una valutazione bassa della riservatezza.

Cosa può fare un operatore

Le misure correttive dell'advisory sono rivolte ai maintainer anziché agli operatori, e i suoi tre passaggi corrispondono al codice comparso in v2.10.5-lts: applicare l'autorizzazione per singolo strumento prima di eseguire uno strumento nelle implementazioni di tool-library e del nodo tool, convalidare ogni identificativo associato presente in tool_ids, skill_tool_ids e mcp_tool_ids al momento del binding, come knowledge_id_list già avviene, e fare in modo che filter_authorized_ids consulti l'autorizzazione per singolo strumento anziché la sola appartenenza al workspace.

Per un team che esegue una build interessata, i passaggi pratici che discendono dalla descrizione stessa dell'avviso sono i seguenti.

• Considera ogni segreto memorizzato negli init_params di uno strumento su un deployment interessato come raggiungibile da qualsiasi membro del workspace, incluso il ruolo più basso, e ruota quelle credenziali invece di presumere che la negazione per singolo strumento le abbia protette.

• Verifica l'appartenenza al workspace. Il bypass richiede un account autenticato nel workspace, quindi rimuovere i membri inattivi o non attendibili riduce l'esposizione anche laddove non sia possibile applicare patch al codice.

• Verifica quali workflow e agenti associano strumenti che contengono credenziali, poiché tale associazione è il passaggio che l'avviso indica come accettato senza un controllo per singolo strumento.

• In caso di aggiornamento, tenere presente che il controllo per utente compare nel repository a partire dalla v2.10.5-lts e che nessuna release è designata come correzione dall'advisory — un operatore che si affida all'aggiornamento si affida al codice sorgente con tag, non a una dichiarazione di patch del fornitore.

Niente di tutto ciò rende il difetto drammatico. Lo rende ordinario in un modo specifico e istruttivo: il modello di autorizzazione è stato progettato correttamente, documentato correttamente e applicato sulle rotte che qualcuno si è ricordato di proteggere. Il percorso di dispatch è stato scritto da persone che pensavano a ciò che un workflow dovrebbe poter fare, non a chi stesse facendo la richiesta — e in una piattaforma di agenti, è il percorso che la maggior parte delle richieste intraprende davvero.

La lezione del caso è strutturale, non numerica. Un permesso per risorsa è tanto solido quanto il suo punto d’ingresso meno protetto, e una piattaforma per agenti accumula rapidamente punti d’ingresso: una route di debug, una route di esportazione, un nodo di workflow, un trigger di chat. MaxKB aveva l’elenco delle concessioni e il controllo; ciò che gli mancava, per la linea dalla 2.0 alla 2.9, era l’abitudine di porre la stessa domanda a ogni porta.