Allerte Sicurezza
CVE-2026-120460: bypass autorizzazione Docker in Jpom, come verificare e mitigare
6 min
Se usi Yuxi, la piattaforma open source per knowledge base e agenti basati su modelli linguistici, con le sandbox di esecuzione attive in Docker Compose, devi aggiornare alla versione 0.7.1 e ruotare le credenziali di PostgreSQL, Neo4j e MinIO. La vulnerabilità CVE-2026-97693 permette a un utente autenticato con privilegi minimi di uscire dal proprio perimetro e arrivare ai dati degli altri tenant e ai servizi interni, senza bisogno di alcun container escape.
Cosa è successo: la vulnerabilità CVE-2026-97693 in Yuxi
Yuxi mette a disposizione degli utenti delle sandbox Docker in cui eseguire comandi, create dinamicamente da un componente chiamato sandbox provisioner. Nelle versioni colpite le sandbox vivono sulla stessa rete Docker dei servizi applicativi fidati e il provisioner espone un'API di gestione senza autenticazione. Il risultato è una mancanza di isolamento tra contenitori con capacità di esecuzione e servizi che dovrebbero restare raggiungibili solo dal backend. L'advisory GHSA-qpm5-6332-9445 la classifica come critica e il fix è stato pubblicato nella release 0.7.1.
Chi è colpito: versioni vulnerabili di Yuxi
- Yuxi dalla 0.6.0.beta1 fino alla 0.7.0 inclusa (tutte le versioni precedenti alla 0.7.1).
- Versione corretta: 0.7.1 e successive.
Il problema riguarda in primo luogo i deployment Docker Compose in cui le sandbox di esecuzione sono abilitate. Secondo il produttore, le installazioni con la funzionalità sandbox completamente disattivata e con i servizi interni isolati in modo indipendente non sono interessate dal percorso di attacco dimostrato. Il backend Kubernetes è menzionato nella configurazione ma l'advisory non lo descrive come vettore: in caso di dubbio, verifica direttamente sull'advisory.
Quanto è grave: punteggio CVSS e sfruttamento attivo
Il punteggio è CVSS 9.9, vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. In pratica: attacco dalla rete, bassa complessità, servono credenziali di un utente qualsiasi, nessuna interazione da parte di altri, e l'impatto esce dal perimetro del componente vulnerabile (scope changed). Al momento la falla non risulta nel catalogo CISA KEV, quindi non ci sono conferme pubbliche di sfruttamento attivo. Non è una ragione per rinviare: il percorso è semplice e richiede solo un account.
Cosa ottiene un attaccante con un account a bassi privilegi, partendo dalla propria sandbox:
- raggiunge le API HTTP delle sandbox di altri tenant e legge variabili d'ambiente, file del workspace, upload e output;
- esegue comandi nelle sandbox attive di altri utenti;
- enumera, crea o cancella sandbox tramite l'API del provisioner, non autenticata (denial of service);
- raggiunge PostgreSQL, Neo4j, MinIO e Redis sulla rete applicativa condivisa e usa le credenziali di default se non sono mai state cambiate;
- se l'account PostgreSQL esposto è un superuser, ottiene esecuzione di comandi nel container del database.
Come capire se sei esposto: verifica versione, esposizione e log
Versione installata
Controlla il tag dell'immagine o del repository in uso. Dalla cartella del progetto: git describe --tags se hai clonato il repository, oppure docker compose images per vedere i tag delle immagini in esecuzione. Confronta con il changelog del progetto: tutto ciò che precede 0.7.1 è vulnerabile.
Sandbox attive e rete condivisa
Con docker ps cerca contenitori il cui nome inizia con il prefisso delle sandbox (di default yuxi-sandbox). Se ne vedi, la funzionalità è in uso. Poi esegui docker network inspect yuxi-know_app-network: se nella lista dei contenitori collegati compaiono sia le sandbox sia postgres, neo4j, minio o redis, l'isolamento manca.
Token del provisioner e porte pubblicate
Apri il file .env: nelle versioni vulnerabili la variabile SANDBOX_PROVISIONER_TOKEN non esiste. Con docker ps --format '{{.Names}} {{.Ports}}' verifica se le sandbox o il provisioner (porta 8002) pubblicano porte sull'host, e con ss -tlnp quali porte il server ascolta davvero. Se una di queste è raggiungibile da internet, la superficie d'attacco è molto più ampia.
Log e indicatori di compromissione
- docker logs del container del provisioner: richieste di creazione, enumerazione o cancellazione di sandbox non riconducibili a un utente legittimo.
- Log di PostgreSQL: connessioni provenienti da indirizzi IP di contenitori sandbox, o con l'utente superuser, in orari anomali.
- Log di accesso di MinIO: letture o scritture su bucket di tenant diversi dal richiedente.
- Sandbox cancellate o riavviate senza spiegazione, segnalate dagli utenti.
Come risolvere la vulnerabilità: patch, aggiornamento e rimedio
La patch è disponibile: aggiorna a Yuxi 0.7.1 (commit b5b5713 nel repository GitHub). Il fix crea una rete Docker separata per ogni sandbox, permette solo al provisioner di unirsi a quella rete, blocca il traffico sandbox-sandbox e sandbox-servizi applicativi, non pubblica più le porte dinamiche delle sandbox, richiede un SANDBOX_PROVISIONER_TOKEN specifico del deployment per ogni richiesta di gestione e proxy, restituisce URL proxy autenticati al posto degli indirizzi diretti dei contenitori e rimuove le credenziali di fallback per PostgreSQL, Neo4j e MinIO.
Passaggi operativi:
- Aggiorna i file Compose e le immagini alla 0.7.1.
- Nel file .env imposta SANDBOX_PROVISIONER_TOKEN con un valore di almeno 32 caratteri, ad esempio generato con openssl rand -hex 32.
- Valorizza esplicitamente POSTGRES_PASSWORD, NEO4J_PASSWORD, MINIO_ACCESS_KEY e MINIO_SECRET_KEY: senza fallback, il servizio non parte con valori vuoti.
- Ruota le credenziali persistite nei volumi. Aggiornare i file Compose non cambia le password già salvate nei dati di PostgreSQL, Neo4j e MinIO. Se erano quelle documentate o di default, vanno modificate manualmente dentro ogni servizio.
- Riavvia lo stack e ripeti il controllo con docker network inspect: le sandbox non devono più comparire sulla rete applicativa.
Cosa fare subito: mitigazioni e hardening
Se non puoi aggiornare subito, applica le misure indicate dal produttore in quest'ordine:
- Disattiva l'esecuzione nelle sandbox, oppure limita l'accesso a Yuxi ai soli amministratori di piena fiducia.
- Sposta ogni sandbox su una rete che non raggiunga né le altre sandbox né la rete applicativa.
- Blocca a livello di rete l'accesso dalle sandbox a PostgreSQL, Neo4j, MinIO, Redis e al provisioner.
- Cambia tutte le credenziali di default dei servizi interni e verifica che l'account PostgreSQL usato dall'applicazione non sia superuser.
- Non esporre su internet la porta del provisioner né le porte delle sandbox; se Yuxi deve essere raggiungibile da fuori, mettilo dietro VPN o reverse proxy con autenticazione.
La logica è la stessa che ho descritto per il bypass di autorizzazione Docker in Jpom: un contenitore che esegue codice utente va trattato come ostile e segmentato di conseguenza.
Se sospetti una compromissione: incident response e analisi forense
Se nei log trovi accessi cross-tenant, sandbox cancellate o connessioni al database da contenitori sandbox, non spegnere la macchina e non ricreare lo stack: perderesti la memoria dei contenitori e i log non persistiti. Isola l'host dalla rete, esporta i log con docker logs su un supporto separato, conserva i volumi dati e, se la piattaforma gestisce informazioni di clienti o dipendenti, valuta la notifica al Garante entro i termini del GDPR. Una copia forense dei volumi e della memoria permette poi di capire quali dati sono stati letti o modificati e da quale account. Nello studio seguo questi casi con il servizio di incident response, da 1.500 a 6.000 € a preventivo fisso; per una revisione preventiva della segmentazione Docker e delle credenziali l'audit di sicurezza parte da 2.000 €. Per le prime ore utili trovi una checklist nell'articolo su cosa fare nelle prime 24 ore dopo un incidente.
Fonti ufficiali
Se hai Yuxi o un'altra piattaforma con sandbox Docker in azienda e vuoi una verifica indipendente dell'isolamento, delle credenziali e dell'esposizione, richiedi un preventivo gratuito: rispondo entro 24 ore. Per un'emergenza in corso scrivimi direttamente dalla pagina contatti, anche su WhatsApp.
