Vulnerabilità di Google MCP Toolbox: cosa dovrebbero controllare gli utenti di IA self-hosted

Immagine di copertina: Google Cloud — architettura di MCP Toolbox.

CVE-2026-93328 collega un avviso software concreto a un problema più ampio dei server domestici: un servizio di strumenti AI può disporre di autorizzazioni su file e archiviazione cloud che superano quelle necessarie per l’attività richiesta a un agente. Parti dal componente esatto interessato, invece di presumere che tutti i server MCP presentino la stessa vulnerabilità.

Questa guida distingue l’evento pubblicato dalle implicazioni pratiche dell’implementazione. Spiega cosa stabiliscono le fonti, dove si fermano le prove e come valutare un flusso di lavoro con file privati senza presumere che un modello impressionante o un server più recente eliminino la necessità di accessi limitati e verifiche.

Quale software descrive l’avviso?

La voce del GitHub Advisory Database descrive un problema di attraversamento dei percorsi e di autorizzazione mancante nella sorgente di archiviazione cloud di Google Cloud MCP Toolbox for Databases. L’intervallo interessato è specifico per il componente. Un’implementazione MCP non correlata, un connettore che non esegue mai questa sorgente o una versione diversa richiedono una valutazione a parte. Conserva il digest dell’immagine installata, il tag di rilascio e la configurazione, così che il confronto possa essere verificato anziché dedotto dal nome visualizzato dell’applicazione.

La voce del database era contrassegnata come non revisionata al momento del controllo, quindi non va presentata come un avviso completo sulla distribuzione del fornitore. Segui i riferimenti fino al repository upstream e confrontali con le note di rilascio attuali. La pull request collegata aggiunge restrizioni per i bucket e i percorsi locali, ma la data di merge precedente non è la data di divulgazione pubblica. Una cronologia che affermi che il progetto ha risolto tutto per la prima volta questa settimana traviserebbe le prove.

Perché l’aggiornamento è solo una parte del perimetro di sicurezza?

Un’immagine aggiornata può includere controlli, ma continuare a funzionare con impostazioni permissive, mount non necessari o credenziali cloud troppo ampie. Esamina la configurazione effettiva invece di presumere che il nome di un’impostazione dimostri una distribuzione con restrizioni. Uno strumento in grado di leggere il filesystem dell’host e scrivere in un bucket remoto crea un canale per il trasferimento dei dati anche quando il modello è ospitato altrove. È l’identità con cui viene eseguito lo strumento a determinare cosa può raggiungere.

Fai l’inventario delle directory radice locali, degli accessi ai bucket, degli utenti di runtime e dell’esposizione alla rete. Preferisci una directory dedicata alle attività e un’identità di servizio con uno scopo specifico. Se il processo non può accedere all’archivio di famiglia o a bucket cloud non correlati, un comando errato impartito allo strumento ha meno autorizzazioni da sfruttare impropriamente. Le restrizioni devono essere applicate anche al di sotto del livello del prompt: le autorizzazioni del sistema operativo, i mount del container e le policy IAM del cloud restano efficaci quando un agente interpreta male una richiesta o riceve istruzioni ostili in contenuti recuperati.

La pull request upstream collegata cita allowedBuckets e allowedLocalRoot e segnala impostazioni predefinite permissive. Controlla i valori effettivi per la sorgente distribuita: la semplice presenza di queste impostazioni in un binario più recente non dimostra che la distribuzione sia configurata con restrizioni. Nella stessa cronologia si fa riferimento alla versione 1.5.0, rilasciata a giugno; pertanto, un avviso pubblicato di recente non dovrebbe essere descritto come una correzione appena integrata a ottobre.

Come verificare l’esposizione senza riprodurre un attacco?

Leggi prima la configurazione e i metadati di runtime. Individua il tipo di sorgente distribuito, la versione esatta e se l’endpoint è raggiungibile da reti non attendibili. Verifica poi le directory radice locali e i bucket consentiti usando dati di test temporanei in un ambiente di staging. Non è necessario inviare segreti di produzione né ricostruire una sequenza di esfiltrazione per dimostrare la presenza di credenziali o mount con autorizzazioni eccessive.

Se i log o altre prove indicano attività non autorizzate, conserva i registri pertinenti prima delle normali operazioni di pulizia e ruota le credenziali associate al servizio esposto. Un aggiornamento di versione non può revocare una chiave copiata né recuperare un file che ha già lasciato il sistema. Tieni i registri delle operazioni di ripristino separati dai test esplorativi e verifica i flussi di lavoro normali dopo la modifica. L’obiettivo è un servizio di strumenti con autorizzazioni dimostratamente circoscritte, non semplicemente un container che si riavvia correttamente.

Che cosa dovresti misurare prima di fidarti di questo flusso di lavoro?

Crea un registro delle esposizioni per ogni istanza distribuita: digest dell’immagine, configurazione sorgente, identità di runtime, percorsi montati, identità cloud ed endpoint raggiungibili. Distingui tra un componente installato e la fonte interessata abilitata. Un’etichetta del container o un pacchetto elencato in un lockfile sono indizi utili, ma non indicano quale configurazione sia attiva nel processo in esecuzione. Conserva le prove usate per giungere a ogni conclusione.

Valuta l’applicazione delle restrizioni con casi di test innocui. Un’operazione consentita all’interno di una radice di test dedicata dovrebbe riuscire; una richiesta al di fuori di tale radice dovrebbe essere negata dal controllo effettivo, senza che il modello debba decidere se sia inappropriata. Applica lo stesso ragionamento all’ambito dei bucket e a IAM. Non dedurre l’applicazione delle restrizioni basandoti soltanto su un file di configurazione sul disco: conferma che il servizio abbia caricato quel file e che le sostituzioni della configurazione in fase di distribuzione non abbiano ampliato le restrizioni previste.

Come mantenere i risultati verificabili e recuperabili?

Considera una sospetta esposizione come un evento operativo con una cronologia. Prima delle normali operazioni di pulizia, conserva i log di accesso pertinenti, i registri di distribuzione e gli identificativi delle credenziali, limitando al contempo l’accesso non necessario a tali registri. Annota ciò che sai e ciò che ancora non puoi accertare. La presenza di una versione vulnerabile non dimostra che sia stato effettuato l’accesso ai dati; l’assenza di una voce di log facilmente reperibile non dimostra che l’accesso fosse impossibile.

Il ripristino dipende dall’autorità interessata. Limita o disabilita la fonte esposta, sostituisci il software vulnerabile se opportuno, ruota le credenziali coinvolte e, se necessario, ripristina i file sovrascritti da una copia nota. Poi verifica che le normali operazioni autorizzate continuino a funzionare con i permessi ridotti. Dopo la correzione, conserva un registro del digest distribuito e delle allowlist effettive. Un aggiornamento può modificare il codice eseguibile senza correggere un montaggio troppo ampio, un’impostazione predefinita permissiva o una credenziale già esposta.

Come puoi testare il flusso di lavoro prima di usare file importanti?

Il testo seguente è un protocollo di convalida editoriale, non un’affermazione che ZimaSpace abbia sottoposto il servizio a benchmark. Esegui il protocollo con dati di test usa e getta o approvati e conserva le condizioni del test insieme al risultato.

1. Fai l’inventario del componente in esecuzione e della sorgente interessata. Confronta la versione distribuita con l’intervallo indicato nell’avviso e conserva l’identificativo esatto del digest dell’immagine e della configurazione.
2. Leggi insieme l’avviso e la modifica upstream. Distingui la data della divulgazione dalla cronologia precedente dell’implementazione e controlla le informazioni sulla versione corrente prima di scegliere un aggiornamento.
3. Mappa le autorizzazioni effettive. Esamina le directory locali, i mount dei container, le autorizzazioni di runtime, l’ambito dei bucket, IAM e la raggiungibilità degli endpoint; individua le autorizzazioni non necessarie per il processo previsto.
4. Verifica le restrizioni con dati di test temporanei nell’ambiente di staging. Controlla i percorsi e i bucket consentiti e negati senza inserire segreti di produzione nelle richieste di test.
5. Conserva le prove e intervieni sulle credenziali esposte, se sospetti attività anomale. Distingui le osservazioni sull’incidente dalle supposizioni e dai test esplorativi.
6. Dopo la correzione, ripeti il normale flusso di lavoro autorizzato. Registra la versione finale, la configurazione caricata e l’esito dell’applicazione delle restrizioni, così che la modifica possa essere verificata in modo indipendente.

Qual è il ruolo di un server ZimaOS?

Una ZimaCube 2, NAS cloud personale può offrire un livello locale di archiviazione e applicazioni quando un progetto richiede davvero più unità, un livello di lavoro su SSD o l’accesso condiviso a un archivio in crescita. Scegli l’hardware in base ai dati da conservare, ai servizi attivi e alle politiche di backup. La raccomandazione del prodotto fornisce un contesto architetturale, ma non dimostra che questo modello cloud, servizio di anteprima o sistema di ricerca venga eseguito localmente sul NAS.

Separa l’inferenza dalla custodia dei dati. Un modello ospitato può ricevere estratti approvati, mentre gli originali autorevoli restano sul server. L’indicizzazione, la conversione o i servizi basati su modelli più piccoli eseguiti localmente, se utilizzati, richiedono una valutazione specifica della memoria e delle risorse di calcolo. Conserva una seconda copia recuperabile al di fuori del dispositivo principale e non considerare RAID o un caricamento completato come una strategia di backup completa. Un server esistente più piccolo resta una scelta ragionevole se soddisfa già il carico di lavoro misurato.

Domande frequenti

Questo avviso riguarda tutti i server MCP?

No. La voce citata descrive la sorgente di archiviazione cloud nelle versioni 1.2.0–1.4.0 di googleapis/mcp-toolbox. Le altre implementazioni e distribuzioni devono essere valutate separatamente.

L’aggiornamento dell’immagine completa la correzione?

Un aggiornamento è solo una parte della valutazione. Verifica le restrizioni effettive sulla directory locale e sui bucket, i percorsi montati, l’identità del runtime e le credenziali cloud. Anche un binario più recente può operare con autorizzazioni eccessive.

Dovrei riprodurre l’esportazione dei file usando dati di produzione?

Usa le prove di configurazione e dati di prova innocui in un ambiente di staging per valutare l’esposizione. Per verificare un mount, un’identità o una allowlist troppo permissivi non servono segreti di produzione né file privati.

Dovrei esporre l’intero archivio privato a uno strumento IA?

Fornisci solo il materiale necessario per l’attività, tramite un account o una directory di lavoro adeguatamente limitati. Verifica cosa carica, registra e conserva il servizio specifico. Una posizione di archiviazione privata non garantisce che uno strumento collegato continui a elaborare i dati localmente.

Quando diventa utile un NAS più capiente?

Quando la crescita misurata dei dati di origine, l’accesso condiviso, le applicazioni attive o i requisiti di conservazione giustificano la topologia di archiviazione. Non risolve automaticamente i problemi di accesso ai modelli, i runtime non supportati, i limiti di caricamento in rete o l’incertezza su un’affermazione di ricerca.

Qual è la condizione per fermarsi prima dell’uso in produzione?

Fermati se non riesci a determinare l’identità del software/modello, i poteri assegnati all’input, la disponibilità della funzionalità richiesta o il percorso di ripristino. Risolvi prima queste condizioni, poi ripeti il test ridotto. Non compensare la mancanza di prove formulando una raccomandazione più sicura.

Fonti e approfondimenti

• Annuncio o avviso ufficiale
• Modifiche upstream ai controlli di accesso allo spazio di archiviazione cloud
• Versioni dei progetti upstream

Verifica delle segnalazioni aggiornata al 28 ottobre 2026. La disponibilità dei prodotti, i piani di accesso e gli avvisi di sicurezza possono cambiare. Le dichiarazioni di fonti esterne sono attribuite; i consigli sui flussi di lavoro e gli esempi di architettura sono analisi editoriali, non misurazioni effettuate con un test hardware ZimaSpace.

Guida correlata: Un agente IA self-hosted può operare tramite una vista del file system in sola lettura?.

Guida correlata: Come verificare che le autorizzazioni dell’agente coprano solo le azioni necessarie dello strumento.

Guida correlata: Rilevamento delle vulnerabilità tramite IA e applicazione automatica delle patch: a cosa serve ciascuno?.