A malicious spreadsheet can make LibreOffice Calc run attacker-supplied code the moment it opens, without the macro warning that normally guards against executable content, The Document Foundation disclosed on Sunday.
The flaw, tracked as CVE-2026-63277, is fixed in LibreOffice 26.2.5 and 26.8.0, which were released on Sunday. The same bug exists in Apache OpenOffice as CVE-2026-59265, disclosed on October 2 and still unpatched, with a fix expected in OpenOffice 4.1.17. Neither CVE has been assigned a severity score yet, and no source reports exploitation in the wild. Both were reported independently by Rick de Jager of the V12 security team and by Thomas Rinsma and Edoardo Geraci of Codean Labs.
The attack abuses a feature of Calc called a database range — a block of cells that pulls its contents from an external data source and can refresh on a timer. A crafted spreadsheet sets a range to refresh every 1 second after the file loads and points it to a remote database document rather than a local one.
When the range refreshes, Calc fetches that remote .odb document to resolve the data source. The .odb is where the trap sits: it names a Java database driver and supplies a classpath, and that classpath is allowed to be a jar:http://… URL on an attacker’s server. Calc downloads the remote JAR and instantiates the named driver class — and instantiating the class is enough to run its code.
Each piece of that chain is a supported feature in its own right. The security problem is that they combine to load Java class loading using settings supplied by a second document fetched from a URL controlled by the spreadsheet, and the application never stops to ask the user whether the document should be trusted. Opening a macro prompts a warning; opening this does not.
In the researchers’ proof of concept, the loaded driver simply launches the system calculator — calc.exe on Windows, Calculator on macOS, xcalc on Linux — the conventional harmless stand-in for “arbitrary code ran here.” The real primitive is the execution of whatever Java bytecode the attacker ships in the JAR.
“Opening a spreadsheet should not silently load and instantiate Java classes,” the researchers wrote in their report, arguing the behaviour should demand the same explicit trust decision as a macro.
The flaw only fires where Java and JDBC support are installed and enabled in the office suite — a non-default but common configuration, especially on Linux desktops that pull in the Base and Java packages. It was confirmed on LibreOffice 24.2.7 on Ubuntu 24.04 and 26.2.4 on Windows, and on OpenOffice 4.1.16 on Linux Mint and Windows.
The fix narrows what a document is allowed to specify: in the patched LibreOffice builds, an entry in the Java classpath must be a local file URL, which closes the remote JAR path. The same advisory from The Document Foundation carries four other Calc data-source bugs reported with it — an arbitrary file write through an embedded Firebird database, two local-file-read and server-side request forgery flaws in the CSV and SQL providers, and an environment-variable leak — all fixed in the same releases.
LibreOffice users should update to 26.2.5 or 26.8.0. OpenOffice users have no patched build yet; until 4.1.17 ships, Apache’s guidance is to disable Java runtime integration in the Preferences dialog, which blocks the attack.
Community Discussion
Join the conversation. Ask questions, share solutions, and help others.
Be the first to start the discussion!
