Una vulnerabilità in LibreOffice Calc permette a un foglio di calcolo preparato ad hoc di caricare ed eseguire codice Java remoto attraverso un driver JDBC, senza mostrare all’utente il consueto avviso associato alle macro.
Il problema, identificato come CVE-2026-63277, riguarda una combinazione di funzionalità legittime del programma che, sfruttate insieme, trasformano un documento apparentemente normale in un possibile vettore di esecuzione del codice. La Document Foundation ha corretto la vulnerabilità nelle versioni 26.2.5 e 26.8.0, mentre Apache OpenOffice presenta un problema corrispondente, identificato come CVE-2026-59265. Il caso è particolarmente interessante perché dimostra come un attacco possa aggirare il modello di sicurezza costruito intorno alle macro.
Come JDBC trasforma un foglio in un vettore d’attacco
Il meccanismo parte da una funzione di Calc chiamata database range, che permette di collegare un intervallo di celle a una sorgente dati esterna e aggiornarne il contenuto. Un documento può indicare una risorsa ODB, cioè un file di database di LibreOffice, attraverso un indirizzo remoto. Quando il foglio viene aperto, Calc può recuperare quella risorsa per aggiornare i dati collegati.
Il passaggio decisivo avviene all’interno dell’ODB. Il file può specificare un driver JDBC, acronimo di Java Database Connectivity, utilizzato dalle applicazioni Java per comunicare con differenti sistemi di database. Nel caso analizzato dai ricercatori, la configurazione può indicare anche il percorso del codice del driver attraverso una posizione remota. Calc scarica quindi un archivio JAR contenente il codice Java e procede alla sua inizializzazione all’interno del processo dell’applicazione. È questa catena, non il semplice utilizzo di JDBC, a creare la condizione per l’esecuzione di codice controllato dall’attaccante.
Il comportamento è diverso da quello di una macro. Le macro, infatti, appartengono a un meccanismo espressamente associato all’esecuzione di codice contenuto nei documenti e, in condizioni normali, LibreOffice può chiedere all’utente di autorizzarne l’esecuzione. In questo scenario, invece, il codice arriva attraverso il caricamento di un driver Java richiesto dalla configurazione della sorgente dati. Di conseguenza, l’utente apre il documento senza incontrare il classico avviso che potrebbe insospettirlo. I ricercatori hanno dimostrato il percorso con una proof of concept che avvia semplicemente la calcolatrice del sistema, utilizzata come dimostrazione innocua dell’esecuzione.
La vulnerabilità richiede comunque che il supporto Java sia disponibile e attivo nella suite. Questo elemento riduce le condizioni necessarie affinché l’attacco abbia successo, ma introduce anche una misura di mitigazione immediata per le installazioni che non dipendono dalle funzionalità Java. Disattivare l’integrazione Java impedisce infatti al percorso sfruttato dalla vulnerabilità di arrivare all’inizializzazione del codice remoto.
LibreOffice è corretto, OpenOffice deve ancora aggiornarsi
Per LibreOffice la correzione impone una restrizione al Java class path: nelle versioni aggiornate, le voci devono essere rappresentate come file URL, impedendo al documento di indicare direttamente una posizione remota per il caricamento delle classi Java. La Document Foundation raccomanda quindi di utilizzare almeno una delle release corrette già disponibili.
La situazione è diversa per Apache OpenOffice. Tutte le versioni fino alla 4.1.16 risultano interessate da CVE-2026-59265, mentre la correzione è prevista nella 4.1.17, ancora in fase di preparazione. Il progetto indica come mitigazione temporanea la disattivazione del runtime Java nelle impostazioni di OpenOffice.
Le vulnerabilità sono state individuate indipendentemente da Rick de Jager del team V12 e da Thomas Rinsma ed Edoardo Geraci di Codean Labs. La correzione di LibreOffice è stata realizzata da Caolán McNamara di Collabora Productivity. Al momento della divulgazione non risultavano attacchi reali documentati.