A malicious spreadsheet can make LibreOffice Calc or Apache OpenOffice load and execute attacker-controlled Java code when the file is opened, according to a recently published proof of concept.
The technique exploits the office suites’ support for external database sources and Java Database Connectivity drivers. It does not depend on a conventional document macro, and the researchers reported that the tested execution path did not produce the macro-trust warning users might expect.
Java support must be enabled for the attack to work. Researchers demonstrated the technique on Windows and Linux, indicating that the exposure is not confined to one operating system.
Two vulnerabilities track the issue: CVE-2026-63277 in LibreOffice Calc and CVE-2026-59265 in Apache OpenOffice. LibreOffice updates are available, while the corrected OpenOffice release remains in testing according to the available reporting.
External database links become a code-execution path
The attack chain combines legitimate spreadsheet, database and Java integration features.
Calc documents can contain database ranges that import information from an external source. The link is stored inside the spreadsheet, allowing the application to retrieve and refresh the linked data when the document opens.
In the researchers’ scenario, the spreadsheet identifies an external OpenDocument Database file, or ODB, using a web address. After retrieving that file, the office application processes its database configuration.
The ODB can specify a JDBC driver and a location from which the driver’s Java classes should be loaded. That location may point to a remotely hosted JAR file. The application then retrieves and starts the driver, causing its Java code to run inside the office application’s process.
This sequence gives an attacker a route from a crafted document to arbitrary Java execution:
- The user opens a malicious spreadsheet.
- The document refreshes an embedded database range.
- The application retrieves an ODB referenced by the spreadsheet.
- The ODB identifies a JDBC driver and its code location.
- The application loads the driver and executes its Java code.
For their harmless demonstration, the researchers used the code-execution capability to open the Calculator application. The proof-of-concept files were stored locally for convenience, but the researchers said an attacker could host the database file and Java payload on infrastructure under their control.
Opening the document is the critical user action. The reported path does not require the victim to approve a macro through the warning described in the original report.
LibreOffice fixes CVE-2026-63277 in two release branches
The LibreOffice vulnerability affects versions before 26.2.5 or 26.8.0, according to the article. Users are advised to move to either 26.2.5 or 26.8.0, depending on their installed release branch.
The report gives October 5 as the release date for updates containing the correction, but it does not state a year for that date. The supplied material provides no separate date for discovery or public disclosure.
NVD’s description of CVE-2026-63277 focuses on how a Calc cell range can remain linked to an external data source inside the document. A malicious file can use that link to name a Java database driver whose code resides remotely.
The correction restricts entries in a Java class path. In fixed LibreOffice versions, such an entry must use a file URL, preventing the remote-loading behavior at the center of the demonstrated attack.
CVE-2026-63277 is classified as CWE-829, which covers functionality imported from outside an intended control sphere without sufficient safeguards.
The LibreOffice issue was reported independently by Rick de Jager of the V12 security team and by Thomas Rinsma and Edoardo Geraci of Codean Labs. Caolán McNamara of Collabora Productivity wrote the LibreOffice correction.
Apache OpenOffice users are waiting for version 4.1.17
Apache OpenOffice 4.1.16 and earlier are affected by CVE-2026-59265. NVD describes the flaw as a Java integration issue through which an untrusted document can cause arbitrary code—including code obtained remotely—to execute when the user opens it.
The planned fix is Apache OpenOffice 4.1.17. However, the available material places that version in the release-candidate phase and does not say it has received a final release.
Until 4.1.17 becomes available, NVD advises users to disable Java runtime integration in the Preferences dialog. Its vulnerability description states that doing so prevents this attack.
Where Java integration cannot be disabled, or as an additional precaution, users should avoid opening files from untrusted sources. Once the final 4.1.17 release is available, affected installations should be upgraded.
CVE-2026-59265 is categorized as CWE-426, covering untrusted search paths. Codean Labs is credited with reporting the OpenOffice vulnerability, while the V12 team published a proof of concept covering both office suites.
Exploitation requires Java, but not a macro approval
The immediate consequence is code execution under the context in which the office application is running. An attacker could choose Java code other than the benign Calculator payload used in the demonstration.
The technique has several conditions. A target must receive and open the crafted document, and Java support must be active in the affected office suite. The application must then process the external database and driver references embedded in the attack chain.
The absence of the described macro-trust prompt changes the defensive assumptions around suspicious spreadsheets. A user who expects potentially executable content to trigger a conventional macro warning might not receive that signal through this route.
The proof of concept was tested on both Windows and Linux. That finding demonstrates cross-platform feasibility in the researchers’ test environments, but it does not establish that every configuration of either operating system is affected in an identical way.
The reporting says there are no known attacks using the vulnerabilities in the wild. That is a statement from the published research, not independent confirmation that exploitation has never occurred.
The available NVD extracts provide no CVSS score or vector for either vulnerability. They also contain no CISA Known Exploited Vulnerabilities status or remediation deadline. Those omissions should not be interpreted as evidence that the CVEs are absent from the KEV catalog.
What administrators and users should do
LibreOffice administrators should verify the exact installed branch and upgrade systems running affected versions to 26.2.5 or 26.8.0. The fix changes Java class-path handling so that the relevant entries must be file URLs.
OpenOffice presents a different operational problem because 4.1.17 is still described as a release candidate. For installations remaining on 4.1.16 or earlier, disabling Java runtime integration is the specific interim control identified by NVD.
Organizations that require Java functionality should apply stricter document-handling controls until the fixed OpenOffice version is released. In particular, users should not open unexpected spreadsheets or documents obtained from sources they cannot verify.
Security teams can also review whether Java integration is needed across managed office installations. Removing an unnecessary runtime dependency reduces exposure to this specific chain, although it should not replace installing the corrected software where a patch is already available.
The central distinction is straightforward: LibreOffice users have patched versions available now, based on the reporting, while OpenOffice users must rely on the stated mitigation until 4.1.17 reaches final release.
