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.