Security1 publisherNot yet confirmed elsewhere2 min readPublished
Spreadsheet database ranges let LibreOffice and OpenOffice run Java code on open
LibreOffice 26.2.5 and 26.8.0 fix a flaw that lets a spreadsheet run Java code on open with no warning; Apache OpenOffice's fix waits on 4.1.17. The attack needs Java enabled, so OpenOffice users can block it now by turning Java off.
The Watch · Security desk
What happened
- LibreOffice tracks the flaw as CVE-2026-63277 and released the fixed versions on October 5; every earlier version is affected.
- Apache tracks the matching OpenOffice flaw as CVE-2026-59265, and every release up to and including the current 4.1.16 is affected.
- The trigger is a Calc database range, a block of cells that refreshes itself from an outside database file named by a web address in the spreadsheet.
- The attack worked in the researchers' tests on both Windows and Linux, and they say it does not depend on any single operating system.
- Rick de Jager of V12 and Codean Labs' Thomas Rinsma and Edoardo Geraci found the LibreOffice bug independently; Apache credits Codean Labs.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure OpenOffice installs face published exploit code with no vendor fix, so until 4.1.17 ships their protection depends on a settings change.
- constraint A user trained to refuse the macro prompt never gets one in this chain, so that habit does nothing to stop it.
- decision LibreOffice admins already have a shipped fix, so what is left is finding the installs still running older builds.
The exploit is public. V12 has published a proof of concept for both programs [14]. There are no reports of the technique being used in real attacks [4]. The demonstration launches the Calculator app as a harmless stand-in, and the same path runs any Java code the attacker chooses [10]. The victim only has to open the file. No prompt appears of the kind either suite shows before a macro runs [1].
The chain is built from features that each work as designed [2]. When the file opens, the database range refreshes and the program downloads the ODB file it points to [9]. That ODB can name a JDBC driver and say where the driver's code lives, including a JAR on a remote server [9]. The program fetches the JAR and starts the driver inside itself, and the driver is the attacker's code [9]. The researchers say the fault is the combination: it reaches code execution without ever asking the user to trust the document [2].
In the demonstration the ODB and the JAR sat on the test machine for convenience [12]. A real attack, the researchers say, would host both on a server the attacker controls [12]. In that form the spreadsheet holds a web address, and the database file and the code are downloaded when the victim opens it [18].
Caolán McNamara of Collabora Productivity wrote the LibreOffice fix [15]. Apache's 4.1.17 is still being tested [6]. Until it ships, the current OpenOffice release is affected, has no fix, and has public exploit code written for it [17]. Besides disabling Java, the other stopgap is not opening spreadsheets from sources you do not trust [7].
The Hacker News said it had contacted The Document Foundation, which develops LibreOffice, and the Apache OpenOffice project for comment [16].
What to watch
- Apache OpenOffice 4.1.17 leaving testing and shipping the fix for CVE-2026-59265.
- The first report of the database-range technique being used against real targets.
- Statements from The Document Foundation or the Apache OpenOffice project in response to The Hacker News.