Secondo un proof of concept pubblicato di recente, un foglio di calcolo malevolo può indurre LibreOffice Calc o Apache OpenOffice a caricare ed eseguire codice Java controllato dall’attaccante all’apertura del file.
La tecnica sfrutta il supporto delle suite per ufficio alle origini dati esterne e ai driver Java Database Connectivity. Non si basa sulle tradizionali macro dei documenti e, secondo i ricercatori, il percorso di esecuzione testato non mostra l’avviso di attendibilità delle macro che gli utenti potrebbero aspettarsi.
Perché l’attacco funzioni, è necessario che il supporto a Java sia abilitato. I ricercatori hanno dimostrato la tecnica su Windows e Linux: il problema, quindi, non riguarda un solo sistema operativo.
Le vulnerabilità che interessano il problema sono due: CVE-2026-63277 in LibreOffice Calc e CVE-2026-59265 in Apache OpenOffice. Per LibreOffice sono già disponibili gli aggiornamenti, mentre, secondo le informazioni pubblicate, la versione corretta di OpenOffice è ancora in fase di test.
I collegamenti a database esterni diventano una via per eseguire codice
La catena d’attacco combina funzionalità legittime dei fogli di calcolo e l’integrazione con database e Java.
I documenti di Calc possono contenere intervalli di database che importano informazioni da una fonte esterna. Il collegamento è salvato nel foglio di calcolo e permette all’applicazione di recuperare e aggiornare i dati associati all’apertura del documento.
Nello scenario descritto dai ricercatori, il foglio di calcolo indica un file OpenDocument Database (ODB) esterno tramite un indirizzo web. Una volta recuperato il file, l’applicazione per ufficio ne elabora la configurazione del database.
Il file ODB può specificare un driver JDBC e il percorso da cui caricare le classi Java del driver. Il percorso può puntare a un file JAR ospitato su un server remoto. L’applicazione recupera e avvia il driver, eseguendone il codice Java all’interno del proprio processo.
La sequenza offre all’attaccante un modo per passare da un documento creato ad hoc all’esecuzione di codice Java arbitrario:
- L’utente apre un foglio di calcolo malevolo.
- Il documento aggiorna un intervallo di database incorporato.
- L’applicazione recupera un file ODB indicato nel foglio di calcolo.
- Il file ODB specifica un driver JDBC e il percorso del relativo codice.
- L’applicazione carica il driver ed esegue il suo codice Java.
Per la dimostrazione, priva di effetti dannosi, i ricercatori hanno usato la capacità di eseguire codice per aprire l’applicazione Calcolatrice. Per comodità, i file del proof of concept erano archiviati in locale, ma i ricercatori hanno precisato che un attaccante potrebbe ospitare il database e il payload Java su un’infrastruttura sotto il proprio controllo.
L’azione decisiva da parte dell’utente è l’apertura del documento. Il percorso descritto non richiede alla vittima di autorizzare una macro tramite l’avviso illustrato nel rapporto originale.
LibreOffice corregge CVE-2026-63277 in due rami di versione
Secondo l’articolo, la vulnerabilità di LibreOffice interessa le versioni precedenti alla 26.2.5 o alla 26.8.0. Si consiglia agli utenti di passare alla 26.2.5 o alla 26.8.0, a seconda del ramo di versione installato.
Il rapporto indica il 5 ottobre come data di rilascio degli aggiornamenti con la correzione, ma non specifica l’anno. Il materiale fornito non riporta una data distinta per la scoperta o la divulgazione pubblica.
La descrizione di CVE-2026-63277 pubblicata da NVD si concentra sul modo in cui un intervallo di celle di Calc può mantenere un collegamento a un’origine dati esterna contenuta nel documento. Un file malevolo può sfruttare il collegamento per specificare un driver di database Java il cui codice si trova su un server remoto.
La correzione limita le voci in un percorso delle classi Java. Nelle versioni corrette di LibreOffice, tali voci devono usare un file URL, impedendo così il caricamento remoto alla base dell’attacco dimostrato.
CVE-2026-63277 è classificata come CWE-829, che riguarda le funzionalità importate dall’esterno di un ambito di controllo previsto senza adeguate misure di protezione.
Il problema di LibreOffice è stato segnalato in modo indipendente da Rick de Jager del team di sicurezza V12 e da Thomas Rinsma ed Edoardo Geraci di Codean Labs. Caolán McNamara di Collabora Productivity ha realizzato la correzione per LibreOffice.
Gli utenti di Apache OpenOffice attendono la versione 4.1.17
Apache OpenOffice 4.1.16 e versioni precedenti sono interessati da CVE-2026-59265. NVD descrive il problema come una vulnerabilità nell’integrazione con Java, attraverso la quale un documento non attendibile può causare l’esecuzione di codice arbitrario, anche recuperato da remoto, all’apertura del file.
La correzione è prevista nella versione Apache OpenOffice 4.1.17. Tuttavia, secondo le informazioni disponibili, la versione è ancora in fase di release candidate e non risulta ancora rilasciata in via definitiva.
In attesa della disponibilità della 4.1.17, NVD consiglia agli utenti di disabilitare Java runtime integration nella finestra di dialogo Preferenze. Secondo la descrizione della vulnerabilità, questa operazione impedisce l’attacco.
Se non è possibile disabilitare l’integrazione con Java, o come misura precauzionale aggiuntiva, è consigliabile evitare di aprire file provenienti da fonti non attendibili. Una volta disponibile la versione definitiva della 4.1.17, occorrerà aggiornare le installazioni interessate.
CVE-2026-59265 è classificata come CWE-426, che riguarda percorsi di ricerca non attendibili. Codean Labs ha segnalato la vulnerabilità di OpenOffice, mentre il team V12 ha pubblicato un proof of concept che riguarda entrambe le suite per ufficio.
L’attacco richiede Java, ma non l’autorizzazione a eseguire una macro
La conseguenza immediata è l’esecuzione di codice nel contesto dell’applicazione per ufficio. L’attaccante potrebbe scegliere codice Java diverso dal payload innocuo che, nella dimostrazione, apriva l’applicazione Calcolatrice.
La tecnica è soggetta ad alcune condizioni. La vittima deve ricevere e aprire il documento creato ad hoc e il supporto a Java deve essere attivo nella suite interessata. A quel punto, l’applicazione deve elaborare i riferimenti a database esterni e driver incorporati nella catena d’attacco.
L’assenza dell’avviso di attendibilità delle macro descritto modifica le aspettative di sicurezza relative ai fogli di calcolo sospetti. Un utente che si aspetta che i contenuti potenzialmente eseguibili facciano comparire il consueto avviso sulle macro potrebbe non ricevere alcuna segnalazione attraverso questo percorso.
Il proof of concept è stato testato sia su Windows sia su Linux. I risultati dimostrano la fattibilità multipiattaforma negli ambienti di test dei ricercatori, ma non provano che tutte le configurazioni dei due sistemi operativi siano interessate nello stesso modo.
Secondo quanto riportato, non risultano attacchi noti che sfruttino queste vulnerabilità. Si tratta di un’affermazione contenuta nella ricerca pubblicata, non di una conferma indipendente che lo sfruttamento non sia mai avvenuto.
Gli estratti di NVD disponibili non riportano un punteggio o un vettore CVSS per nessuna delle due vulnerabilità. Non indicano neppure lo stato nel catalogo CISA Known Exploited Vulnerabilities né una scadenza per la correzione. Queste omissioni non vanno interpretate come prova che le CVE non siano presenti nel catalogo KEV.
Cosa devono fare amministratori e utenti
Gli amministratori di LibreOffice dovrebbero verificare il ramo esatto installato e aggiornare i sistemi con versioni vulnerabili alla 26.2.5 o alla 26.8.0. La correzione modifica la gestione dei percorsi delle classi Java, imponendo che le voci pertinenti siano file URL.
Per OpenOffice la situazione operativa è diversa, perché la 4.1.17 è ancora descritta come release candidate. Per le installazioni che rimangono alla 4.1.16 o a versioni precedenti, la misura temporanea indicata da NVD consiste nel disabilitare Java runtime integration.
Le organizzazioni che hanno bisogno delle funzionalità Java dovrebbero applicare controlli più rigorosi alla gestione dei documenti finché non sarà rilasciata la versione corretta di OpenOffice. In particolare, gli utenti non dovrebbero aprire fogli di calcolo o documenti inattesi provenienti da fonti non verificabili.
I team di sicurezza possono anche valutare se l’integrazione con Java sia necessaria nelle installazioni di suite per ufficio gestite. Eliminare una dipendenza dal runtime che non serve riduce l’esposizione a questa specifica catena d’attacco, ma non sostituisce l’installazione della versione corretta quando è già disponibile una patch.
La distinzione fondamentale è semplice: secondo le informazioni pubblicate, gli utenti di LibreOffice possono già installare versioni corrette, mentre quelli di OpenOffice devono affidarsi alla misura di mitigazione indicata finché la 4.1.17 non sarà rilasciata in via definitiva.
