CVE-2026-54349: SQL injection in Chartbrew, come verificare e aggiornare alla 5.2.1

CVE-2026-54349 è una vulnerabilità critica (CVSS 9.8) in Chartbrew, l'applicazione open source che si collega a database e API per creare grafici e dashboard. Nelle versioni precedenti alla 5.2.1, un utente non autenticato può manipolare i filtri passati via URL a un grafico pubblico o embedded e alterare la query SQL eseguita sul database collegato. Il risultato è una SQL injection che permette di leggere, modificare o cancellare i dati accessibili all'account database configurato. La correzione è nella versione 5.2.1. Al momento la vulnerabilità non risulta nel catalogo CISA KEV, ma l'assenza di autenticazione richiesta la rende prioritaria.

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

Chartbrew permette di definire query SQL salvate e di esporle come grafici, anche pubblici o incorporabili in altri siti. Queste query possono contenere variabili di dashboard che vengono sostituite con i valori passati nell'URL. Il problema sta nella funzione di sostituzione: usava le stringhe di rimpiazzo JavaScript in modo non sicuro e, per MySQL e MariaDB, non faceva l'escape dei backslash nei contesti tra apici. Due difetti distinti, stessa conseguenza: il valore fornito dall'utente finisce nella query e la modifica.

Chi è colpito: versioni vulnerabili di Chartbrew

Sono vulnerabili tutte le installazioni di Chartbrew precedenti alla 5.2.1. La condizione necessaria è questa: l'istanza deve esporre almeno un grafico pubblico o embedded che usa variabili controllate dall'URL dentro una query SQL. Vale per tutti i connettori SQL per la parte legata alle sequenze con il simbolo del dollaro. Il secondo percorso, quello dei backslash, riguarda solo le connessioni MySQL e MariaDB, inclusi i plugin mysql e rdsmysql che compaiono nel commit di correzione.

• Chartbrew self-hosted installato da sorgente o tramite container, versione inferiore a 5.2.1.
• Dashboard o grafici condivisi pubblicamente o incorporati con iframe.
• Query SQL salvate che contengono variabili sostituite a runtime.

Se nessun grafico è pubblico o embedded, la superficie descritta nell'advisory non è esposta, ma l'aggiornamento resta necessario perché una condivisione può essere attivata in qualsiasi momento.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il vettore è CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: attacco via rete, bassa complessità, nessun privilegio, nessuna interazione dell'utente, impatto alto su riservatezza, integrità e disponibilità. In pratica un attaccante che trova l'URL di un grafico pubblico può costruire valori di filtro che chiudono la stringa e aggiungono istruzioni SQL. Cosa ottiene dipende dai permessi dell'account database usato da Chartbrew: se è in sola lettura può esfiltrare dati, se ha permessi di scrittura può alterarli o cancellarli. Non risulta nel catalogo CISA KEV, quindi non c'è conferma di sfruttamento attivo, ma il tipo di falla è semplice da riprodurre.

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

Versione installata

• Installazione da sorgente: nella cartella del progetto leggi il campo version del file package.json, ad esempio con grep version package.json.
• Installazione in container: controlla il tag dell'immagine con docker ps e docker images. Se il tag è latest verifica la versione reale dentro il container con lo stesso comando sul package.json.
• Confronta con la pagina di rilascio v5.2.1 sul repository ufficiale.

Esposizione

• Elenca le dashboard e i grafici con condivisione pubblica o embed attivi.
• Per ognuno controlla se la query salvata usa variabili sostituite dall'URL.
• Verifica se l'istanza risponde da internet: una richiesta dall'esterno all'indirizzo pubblico o un controllo delle regole del firewall e del reverse proxy.
• Verifica i permessi dell'utente database configurato in Chartbrew: SELECT soltanto o anche INSERT, UPDATE, DELETE, DROP.

Log e indicatori

• Log del reverse proxy o del web server: cerca richieste verso gli endpoint dei grafici pubblici ed embedded con parametri di filtro contenenti sequenze con il dollaro, apici, backslash, commenti SQL o parole chiave come UNION e SELECT.
• Log del database MySQL o MariaDB, se attivi: query anomale provenienti dall'utente di Chartbrew, errori di sintassi ripetuti, operazioni di scrittura inattese.
• Dati: tabelle modificate o svuotate senza spiegazione.

Come risolvere la vulnerabilità: patch e aggiornamento a Chartbrew 5.2.1

La correzione è disponibile. Aggiorna Chartbrew alla versione 5.2.1 o successiva. Il commit di correzione aggiunge l'opzione escapeBackslash per i plugin mysql e rdsmysql e rivede la logica di sostituzione delle variabili nel modulo SQL condiviso. La stessa release blocca anche gli indirizzi NAT64/DNS64 nella protezione SSRF in uscita, quindi l'aggiornamento chiude più di un problema.

1. Fai un backup del database interno di Chartbrew e della configurazione.
2. Installazione da sorgente: aggiorna al tag v5.2.1, reinstalla le dipendenze e riavvia il servizio.
3. Container: aggiorna l'immagine alla 5.2.1, ricrea il container e verifica di nuovo la versione.
4. Dopo l'aggiornamento prova un grafico pubblico con un filtro legittimo per confermare il funzionamento.

La procedura esatta dipende dal metodo di installazione: segui le note di rilascio ufficiali.

Cosa fare subito: mitigazioni e hardening per CVE-2026-54349

Se non puoi aggiornare oggi, in ordine di priorità:

1. Disattiva la condivisione pubblica e gli embed dei grafici basati su query SQL con variabili da URL. È la misura che elimina la superficie descritta nell'advisory.
2. Riduci i permessi dell'account database usato da Chartbrew alla sola lettura delle tabelle necessarie. Limita l'impatto di una iniezione riuscita.
3. Limita l'accesso all'istanza: VPN, allowlist di IP o autenticazione sul reverse proxy, se i grafici devono restare raggiungibili solo da persone note.
4. Segmenta la rete: il server Chartbrew deve raggiungere solo i database che serve, non il resto della rete aziendale.
5. Ruota la password dell'utente database dopo l'aggiornamento, soprattutto se hai trovato richieste sospette nei log.

Un WAF può aiutare a filtrare pattern evidenti, ma non sostituisce la patch.

Se sospetti una compromissione: incident response e analisi forense

Se nei log compaiono richieste con payload SQL o se i dati risultano alterati, tratta la situazione come un incidente. Non spegnere il server e non cancellare nulla: isolalo dalla rete mantenendolo acceso, per conservare la memoria e i processi attivi. Esporta e conserva i log del proxy, dell'applicazione e del database prima che vengano ruotati. Fai una copia forense dei dischi e del database collegato prima di qualsiasi ripristino. Valuta quali dati erano accessibili all'account: se includono dati personali, serve la valutazione sull'obbligo di notifica al Garante secondo il GDPR. Come perito informatico forense seguo questa fase con acquisizione forense, analisi dei log e relazione tecnica utilizzabile anche in sede legale. Per orientarti sulle prime ore ho scritto una guida su cosa fare nelle prime 24 ore di un incidente. L'incident response dello studio parte da 1.500 € a preventivo fisso.

Fonti ufficiali

• Advisory GHSA-4wj7-9gq7-mrr2 su GitHub
• Note di rilascio Chartbrew v5.2.1
• Commit di correzione f93d31a

Hai Chartbrew esposto e vuoi un controllo?

Se la tua azienda usa Chartbrew o altre dashboard collegate direttamente ai database di produzione, posso verificare versione, esposizione e permessi, e sistemare la configurazione in modo che un grafico pubblico non diventi una porta sul gestionale. Trovi i dettagli dei servizi di sicurezza e consulenza IT dello studio. Per un controllo o un intervento urgente scrivimi dalla pagina contatti oppure richiedi un preventivo gratuito: rispondo entro 24 ore.