LibreOffice / OpenOffice Calc allows remote source execution when opening ODB / JDBC leaves

Researchers have shown that a malicious spreadsheet can force LibreOffice and Apache OpenOffice to run code controlled by an attacker at the time the file is opened, without showing the confidence warning that appears before running a macro. The vector explores Calc's ability to define data ranges linked to external databases (ODB files) and the power to load JDBC drivers in Java, so the application downloads and starts a remote JAR within its own process. LibreOffice already released a correction (followed as CVE-2026-63277) on October 5; Apache OpenOffice remains vulnerable in its current version 4.1.16 and records the failure as CVE-2026-59265, with an arrangement planned for 4.1.17.

In technical terms, the attack links three legitimate Calc functions. First, a "database range" can be configured to be automatically refreshed from an external source; that source can be an ODB file whose location is stored on the sheet. Second, an ODB can indicate which Java database controller (JDBC) to use and where your code resides, usually packaged in a JAR file. Third, if the Java support is active in the LibreOffice / OpenOffice installation, the suite downloads the JAR and starts the controller within the same application process. The safety problem is not a broken function, but the combination of these functions that results in code execution without the confidence check that applies to macros.

The researchers carried out a concept test on Windows and Linux; in that PoC the malicious "driver" opened the system calculator as a harmless demonstration, but the same chain can run any Java code once the JAR is loaded. In public demonstrations, the files resided locally to facilitate reproduction, but the authors point out that a real attack would place ODB and JAR on the attacker-controlled servers for the victim to download when opening the sheet.

Facts confirmed: LibreOffice corrected vulnerability and recommends updating to versions 26.2.5 or 26.8.0; Apache OpenOffice recognizes the failure and maintains all of its versions up to 4.1.16 as affected, with a solution expected at 4.1.17. The errors were reported by the above-mentioned research firms (V12 Security and Codean Labs) and the LibreOffice correction was implemented by a Collabora Productivity developer. There are, for now, no verified public reports that the explosion has been used in actual attacks.

Estimates and points still uncertain: It is unclear how many users keep Java support enabled in these suites in desktop environments and what fraction of deployments in companies could be vulnerable by configuration. There is also no public evidence of mass campaigns that are taking advantage of this path; the availability of a PoC increases the likelihood of targeted exploits, but the transition from PoC to real exploitation depends on operational factors (for example, that the victim opens an unreliable spreadsheet and has Java enabled).

Who does this affect? Mainly users and organizations using LibreOffice or Apache OpenOffice with the Java support enabled and opening spreadsheets from unverified origins. The environments where ODF / Ods files are accepted from external suppliers, finance equipment, management or any flow that process spreadsheets received by mail are particularly relevant, because a file that at first sight is a spreadsheet can contain the ODB reference that triggers the download and loading of the malicious JAR.

Possible real consequences: remote code execution in the context of the office suite process, which can result in local data theft, additional load discharge, lateral movement in internal networks or persistence establishment if the attacker has sufficient privileges. Since the execution occurs within the user process, the available permissions will be those of the user who opened the document.

Specific measures to be taken by the reader right now:

1) Update if you use LibreOffice. Install the corrected versions indicated by the project (mentioned by the foundation itself) or the latest stable version available on the official site: https: / / www.liberoffice.org. That's the ultimate defense for facilities that can't do without the Java support.

2) If you use Apache OpenOffice and can't update yet, disable Java. Open the program options and dismark the use of a Java (JRE) execution environment. This prevents Calc from downloading and starting external JDBC drivers and blocks this attack vector. The Java configuration is exposed to the options interface of both suites; if you are not sure, contact your IT team.

(3) Do not open spreadsheets of unknown or unexpected origin. Try with special caution files received by mail, even if they come from legitimate contacts whose systems could have been compromised. When you need to analyze a suspicious file, do so on an isolated machine or on a sandbox / VM without access to corporate credentials.

4) Reduce network and process exposure. In corporate environments, limit the capacity of the office suite to establish outgoing connections by firewall or proxy rules, and consider policies that prevent office processes from downloading executable code. Applications like AppArmor or SELinux can help to restrict what the LibreOffice / OpenOffice binary can load or run.

5) For administrators: update inventory, apply mitigation and monitor. Identify equipment with Java enabled in LibreOffice / OpenOffice and prioritize updates or Java deactivation. Add unusual traffic detection to remote ODB / JAR hosting servers and review endpoints records for processes that open HTTP (S) connections after opening office documents.

In order to better understand the JDBC component that allows this abuse, please refer to Oracle's technical documentation on JDBC: https: / / docs.oracle.com / javase / 8 / docs / techniques / guides / jdbc /. For official information and downloads of the affected suites, use the project pages: LibreOffice and Apache OpenOffice.

In short, vulnerability is not a one-function failure but the result of the orchestration of legitimate mechanisms that, combined, allow to execute code without asking for the confirmation required of the macros. Update LibreOffice or disable Java in OpenOffice, along with good document management practices and network controls, are the most effective defenses until Apache publishes its correction. We will maintain coverage as projects publish additional notices and patches.