CVE-2026-85295: sessioni falsificabili in Chartbrew, verifica e patch 5.2.3

Se usi Chartbrew per costruire dashboard sui dati aziendali e lo hai installato dai sorgenti o con il Docker Compose del repository, devi aggiornare alla versione 5.2.3. La vulnerabilità CVE-2026-85295 permette a chiunque raggiunga l'API di farsi passare per un utente qualsiasi, senza password e senza superare l'autenticazione a due fattori, se il valore di CB_SECRET è quello di default, debole o comunque conosciuto. Ecco cosa è noto, come controllare la tua installazione e cosa fare.

Cosa è successo: la vulnerabilità CVE-2026-85295 in Chartbrew

Chartbrew è un'applicazione web open source che si collega a database e API per generare grafici e dashboard. Fino alla versione 5.2.3, quattro helper di autenticazione lato server accettavano token di sessione JWT firmati con HS256 usando la chiave CB_SECRET come fallback, anche quando quella chiave era un valore di default distribuito con il software, un valore debole o un valore noto. I moduli coinvolti sono server/modules/verifyToken.js, verifyUser.js, getUserFromToken.js e socketManager.js, quindi il problema tocca sia l'API REST sia il livello socket.

Il meccanismo è semplice: HS256 è una firma simmetrica. Chi conosce la chiave può firmare un token che contiene l'id dell'utente che vuole impersonare. La verifica legacy lo accettava come sessione valida. Il correttivo, nel commit da8c71f, elimina il fallback e verifica i token di sessione solo con CB_ENCRYPTION_KEY.

Chi è colpito: versioni vulnerabili di Chartbrew

• Versioni interessate: tutte le release di Chartbrew precedenti alla 5.2.3.
• Condizione necessaria: un CB_SECRET noto, debole o lasciato al valore di default. L'advisory indica esplicitamente le installazioni dai sorgenti e quelle con il Docker Compose del repository come casi tipici.
• Non colpiti da questo percorso: i container in cui CB_SECRET non è definito affatto, perché il fallback non ha una chiave con cui verificare.

Se hai una installazione con CB_SECRET lungo, casuale e mai condiviso, il rischio concreto è più basso, ma il codice vulnerabile è comunque presente e l'aggiornamento resta necessario.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il punteggio CVSS 3.1 è 9.8, gravità critica, con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: attacco dalla rete, bassa complessità, nessun privilegio e nessuna interazione dell'utente richiesti, impatto alto su riservatezza, integrità e disponibilità.

In pratica si tratta di un bypass di autenticazione con impersonificazione completa. Un attaccante che forgia un token ottiene i privilegi dell'utente scelto su tutta l'API e sul layer socket: può leggere le dashboard, vedere e modificare le connessioni ai database, lanciare query sui dati collegati e, se impersona un amministratore, gestire utenti e progetti. Non serve rubare credenziali e la 2FA non interviene.

Al momento CVE-2026-85295 non risulta nel catalogo CISA KEV delle vulnerabilità sfruttate attivamente. Questo non va letto come assenza di rischio: lo sfruttamento richiede solo una richiesta HTTP con un token costruito a tavolino.

Come capire se sei esposto: verifica versione, esposizione e log

Versione installata

• Installazione Docker: docker compose ps e controlla il tag dell'immagine; poi docker compose exec sul container server con cat package.json | grep version.
• Installazione dai sorgenti: nella cartella del progetto git describe --tags oppure leggi il campo version in package.json.
• Dall'interfaccia: la versione è di norma visibile nelle impostazioni o nel footer; in caso di dubbio fidati del file.

Valore di CB_SECRET

Apri il file .env o la sezione environment del docker-compose.yml e verifica CB_SECRET: grep CB_SECRET .env. Se il valore è quello presente nel repository, una stringa corta, una parola di dizionario o un valore riutilizzato altrove, considera l'istanza esposta. Verifica allo stesso modo CB_ENCRYPTION_KEY, che dopo la patch diventa l'unica chiave di verifica delle sessioni.

Raggiungibilità dalla rete

Controlla se l'API è pubblicata su internet: dall'esterno della tua rete prova a raggiungere l'indirizzo dell'API con curl -I, verifica le regole del firewall e la configurazione del reverse proxy. Un'istanza raggiungibile solo in VPN riduce molto la superficie, ma non azzera il rischio da parte di chi è già dentro la rete.

Indicatori da cercare nei log

• Log del reverse proxy (Nginx, Traefik, Caddy): richieste all'API con header Authorization da IP mai visti, in orari insoliti, o sequenze di chiamate senza una precedente richiesta di login.
• Log del container server: accessi come utenti amministrativi senza passaggio dalla 2FA.
• Dentro Chartbrew: connessioni a database aggiunte o modificate, nuovi utenti, dashboard condivise di recente, query inattese.
• Log dei database collegati: query provenienti dall'host di Chartbrew fuori dal normale schema di utilizzo.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

La correzione è nella release v5.2.3, disponibile sulla pagina delle release di GitHub. Con Docker Compose aggiorna il tag dell'immagine, poi docker compose pull e docker compose up -d. Con installazione dai sorgenti fai checkout del tag v5.2.3, reinstalla le dipendenze e riavvia i servizi.

Dopo l'aggiornamento i token firmati con CB_SECRET vengono rifiutati. Alcune note dalla release:

• I token di condivisione delle dashboard pubbliche sono migrati a CB_ENCRYPTION_KEY. Esiste l'opzione temporanea CB_ALLOW_LEGACY_SHARE_TOKENS per i link già distribuiti: usala solo come ponte e disattivala appena possibile.
• La 5.2.3 include altre correzioni di sicurezza, tra cui la protezione del pannello BullMQ in /apps/queues con HTTP Basic Authentication tramite CB_BULLMQ_USERNAME e CB_BULLMQ_PASSWORD.

Chartbrew ha già avuto una falla critica in questa stessa serie, descritta nell'articolo su CVE-2026-54349 e l'aggiornamento alla 5.2.1: se sei fermo a quella versione, la 5.2.3 chiude entrambe.

Cosa fare subito: mitigazioni e hardening

1. Aggiorna alla 5.2.3. È l'unico rimedio completo.
2. Se non puoi aggiornare oggi, limita l'accesso all'API: regole firewall o VPN, così che solo la rete interna la raggiunga.
3. Sostituisci CB_SECRET e CB_ENCRYPTION_KEY con valori lunghi e casuali. Il cambio di chiave invalida le sessioni esistenti, quindi avvisa gli utenti che dovranno rifare il login.
4. Ruota le credenziali dei database e delle API collegate a Chartbrew, perché un utente impersonato poteva leggerle o usarle.
5. Segmenta: Chartbrew dovrebbe raggiungere i database solo attraverso utenti in sola lettura e con i permessi minimi.
6. Rivedi gli utenti presenti nell'istanza e rimuovi quelli non riconosciuti.

Se sospetti una compromissione: incident response e analisi forense

Se nei log trovi accessi anomali o connessioni modificate, non cancellare container, volumi o log e non riavviare a caso per ripulire. Isola l'host dalla rete mantenendolo acceso, esporta i log del proxy e del container su un supporto separato, salva una copia dei volumi e, dove possibile, della memoria. Una copia forense fatta con metodo è ciò che permette di capire cosa è stato letto o modificato e di sostenere eventuali contestazioni verso fornitori o assicurazioni.

Se i dati esposti riguardano persone fisiche, valuta con il responsabile privacy la notifica al Garante prevista dal GDPR entro i termini. Nello studio mi occupo di incident response e analisi forense con preventivo a prezzo fisso: l'incident response va da 1.500 a 6.000 €, un audit di sicurezza dell'infrastruttura da 2.000 a 8.000 €.

Fonti ufficiali

• Advisory GHSA-qvv4-r3q6-8797 su GitHub
• Release v5.2.3 di Chartbrew
• Commit da8c71f: reject session tokens signed with legacy CB_SECRET

Hai bisogno di una verifica?

Se non sai quale versione stai usando, chi ha accesso all'istanza o come è configurato il server, posso controllare l'installazione e i log, applicare l'aggiornamento e sistemare l'esposizione in rete. Chiedi un preventivo gratuito, rispondo entro 24 ore, oppure scrivimi dalla pagina contatti, anche su WhatsApp.