LibreOffice Calc and Apache OpenOffice Calc can execute Java code when a user opens a crafted spreadsheet, without showing a macro warning.
There are two CVE records for this path. LibreOffice fixes CVE-2026-63277 in 26.2.5 and 26.8.0, while Apache’s CVE-2026-59265 covers OpenOffice through 4.1.16. Both demonstrations need usable Java and JDBC support, the installed application and its configuration determine exposure.
What is CVE-2026-63277? A malicious spreadsheet can use LibreOffice’s database connection features to load a remote Java driver. The flaw lets document-supplied settings reach code execution before an active-content trust prompt.
An Automatic Data Refresh Starts the Chain
An .ods file starts the public example. Its saved database range includes table:refresh-delay set to PT1S, so the range refreshes on a one-second interval after Calc restores it. No separate import action is needed from the person who opens the sheet.
During the refresh, Calc creates a com.sun.star.sdb.RowSet. It passes the range’s DataSourceName through DatabaseContext, which loads the external .odb named by the URL. That second file contains the settings for the database connection.
The attachment can therefore start the chain without carrying the driver code itself. Its reference selects another document; that document supplies another code location. Looking for embedded macros alone doesn’t account for either handoff, even though both originate in the spreadsheet the recipient opened.
Database Settings Become a Java Code Source
The database document provides JavaDriverClass and JavaDriverClassPath. One names the driver class; the other tells the application where to find its code. In the demonstrated exploit, the class path identifies a remote JAR through a jar:http URL.
Calc then retrieves that archive and instantiates the named JDBC driver. The supplied demonstration driver attempts to launch Calculator when the application loads or instantiates it. As a result, loading the driver reaches executable Java bytecode before the recipient makes a separate decision to run document code.
The relevant permission boundary sits at class loading. Connection settings from the database document select the executable content. Although the spreadsheet looks like a data file, its references reach code outside that file and outside the installed office suite.
Java Support Determines the Demonstrated Exposure
Java and JDBC support must be installed, enabled and usable by the office application. The proof of concept cannot follow this path when that support is unavailable. It also needs access to the database document and driver archive referenced by the spreadsheet.
Both reports confirm testing on Windows and Linux. For LibreOffice, the listed builds include 24.2.7.2 on Ubuntu and 26.2.4.2 on Windows. The OpenOffice report lists 4.1.16 on Linux Mint and Windows. In the Windows OpenOffice test, the 32-bit application requires a compatible 32-bit Java runtime.
The example serves its database and JAR from localhost for convenient reproduction. However, the reports explicitly state that an attacker could host those resources on a remote server. Local hosting is a test arrangement, not a restriction on the flaw.
Code runs in the office application’s process context. That establishes execution with the application’s existing authority; the reports do not demonstrate automatic administrator elevation.
The Two Products Have Different Fix States
LibreOffice lists 26.2.5 and 26.8.0 as fixed in its October 5 advisory. The change concerns the Java class path entry, which must use a file URL in the fixed builds. As a result, the documented remote JAR reference no longer reaches the driver through that path.
For Apache OpenOffice, the latest advertised release is still 4.1.16 on October 13. Apache’s October 2 advisory covers that version and earlier releases, with a fix expected in 4.1.17. The advisory describes 4.1.17 as a release candidate, so its planned fix does not establish availability of a final release.
An organization’s installed builds remain a separate fact. The announcements identify the project’s fix state, without establishing deployment on any particular fleet. Similarly, the demonstrations show a working execution path; the reviewed reporting does not identify a confirmed campaign using these flaws in the wild.
Other Data Connections Also Cross Security Boundaries
An embedded Firebird database accounts for another entry in the LibreOffice advisory, CVE-2026-63266. It can write to locations the user can access. The fix confines those operations to the database’s private directory.
Meanwhile, CVE-2026-63267 concerns a CSV data link. Opening the document could pull local file contents into the sheet or cause a request to a host named by the document. LibreOffice puts those external data updates under link update controls in the fixed versions.
Neither entry is an extra stage demonstrated by the JDBC PoC. However, both involve activity that starts through a data reference. Together with the driver flaw, they show several ways a spreadsheet’s connections can affect resources beyond the cells on screen.
Driver Loading Carries the Endpoint Risk
By the time the demonstration opens Calculator, Calc has followed the spreadsheet reference, loaded the database settings and instantiated a Java class. Those earlier steps explain how code reached the office process. The final child process is one visible result of that execution.
Execution Governance applies to the authority unknown code receives over the real endpoint, so the document-to-driver transition is relevant to that analysis. EDR can also provide telemetry around document opening, network retrieval and subsequent execution. These PoCs do not test an Xcitium deployment; product-specific prevention against this exact chain remains unverified.
Conclusion: No Macro Prompt. Still Code Execution.
CVE-2026-63277 and CVE-2026-59265 expose a dangerous assumption in document security: preventing macros from running does not necessarily prevent a document from executing code. LibreOffice Calc and Apache OpenOffice Calc can follow attacker-controlled database references that ultimately load executable Java code, without presenting the macro warnings users expect to see before active content runs.
The attack exploits functionality designed for legitimate data connectivity. A crafted spreadsheet triggers an automatic refresh, retrieves an external database document, and uses its connection settings to identify a Java driver hosted elsewhere. When the office application loads that driver, document-controlled configuration becomes executable code.
The distinction matters because the malicious instructions do not need to appear as embedded macros. They can reside across multiple external resources, with each reference appearing to serve a normal application feature. The demonstrated execution occurs within the office application’s existing privileges, making the user’s document-opening action sufficient to begin the chain when the required Java and JDBC components are available.
This is not a failure of macro warnings themselves. It is a separate execution path operating outside the security decision those warnings were designed to enforce.
Why This Threat Matters
- Macro restrictions do not cover every execution path. A spreadsheet can trigger Java code through database connectivity without containing conventional macros.
- Automatic refresh removes an additional user decision. Opening a crafted document can initiate the sequence without requiring a separate import or execution command.
- External references extend the attack beyond the document. The spreadsheet, database configuration, and executable JAR can reside in different locations.
- Exposure depends on application configuration. The demonstrated technique requires usable Java/JDBC support and access to the referenced resources.
- A patch is not yet available for every affected product. LibreOffice has released fixes, while Apache OpenOffice users must rely on mitigations until the corrected release becomes available.
Where Defensive Control Must Operate
Xcitium Vulnerability Assessment helps identify affected LibreOffice and OpenOffice installations, prioritize vulnerable systems, and verify remediation as security updates become available.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, adds endpoint visibility around suspicious document-triggered network access, unexpected process execution, and malicious follow-on activity.
Execution Governance provides an additional control layer when untrusted code attempts to affect the endpoint, although the demonstrated in-process Java loading path requires specific validation rather than an assumption of automatic prevention.
Close the Path From Document Data to Executable Code
Organizations should update LibreOffice to a fixed release and disable Java integration in vulnerable Apache OpenOffice installations until a corrected version is available. Systems that do not require Java-based database connectivity should have that functionality disabled. Security teams should also investigate unexpected external resources loaded by office applications and suspicious execution originating from document workflows.
The broader requirement is to treat document-controlled external references as security-sensitive operations. A spreadsheet should not gain the authority to select and execute remote code simply because that code is presented as a database driver.
