LibreOffice and OpenOffice flaws allow silent code execution via spreadsheets
Security researchers found vulnerabilities in LibreOffice and Apache OpenOffice that let malicious spreadsheets run code without macro warnings. LibreOffice has patched the issue, but OpenOffice remai
Security researchers have identified critical vulnerabilities in LibreOffice and Apache OpenOffice that allow malicious spreadsheets to execute arbitrary code immediately upon opening. The flaw bypasses standard macro security warnings, posing a significant risk to users who rely on these open-source office suites for daily document handling.
What happened
The vulnerability exploits how both applications handle external data sources within spreadsheet files. Specifically, it leverages a feature called "database range," which allows a block of cells to automatically pull and refresh data from an outside source. In this attack scenario, the spreadsheet contains a reference to an external database file, known as an ODB, hosted at a web address controlled by the attacker. When the user opens the spreadsheet, the application automatically downloads this ODB file.
The downloaded ODB file then specifies a Java database driver, or JDBC driver, and points to a JAR file containing the attacker’s code. The office suite proceeds to download this JAR file and executes the driver within the application itself. Because each step uses legitimate features intended for data connectivity, the software does not trigger the usual security prompts that appear when running macros. This chain of events results in silent code execution, giving the attacker full control over the application context.
While the proof of concept demonstrated by researchers only opened the Calculator app as a harmless test, the same mechanism can run any Java code the attacker chooses. The attack works on both Windows and Linux systems, provided that Java support is enabled in the office suite settings. Researchers noted that in a real-world scenario, the malicious database and code files would be hosted on remote servers controlled by the attacker, rather than locally as shown in the demonstration.
Key details
- LibreOffice has released fixes for CVE-2026-63277 in versions 26.2.5 and 26.8.0, available since October 5.
- Apache OpenOffice remains vulnerable with CVE-2026-59265 affecting all versions up to and including 4.1.16.
- A fix for Apache OpenOffice is expected in version 4.1.17, which is currently in testing.
- The attack requires Java support to be enabled in the application settings to function.
- No reports of active exploitation in the wild exist yet; the findings are based on proof-of-concept demonstrations.
- Disabling Java or avoiding untrusted spreadsheets are the primary mitigations for OpenOffice users until a patch is released.
Background
To understand this vulnerability, it helps to know how modern office suites manage dynamic data. Features like database ranges are designed to keep spreadsheets updated with live information from external databases. This is useful for business intelligence and reporting but introduces complexity in how the application trusts external resources. Typically, office software treats macros—scripts embedded in documents—as high-risk and requires explicit user permission to run them. However, data connectivity features are often treated as lower risk because they are seen as passive data retrieval tools.
Java plays a central role in this exploit because both LibreOffice and OpenOffice use it for various backend operations, including database connectivity. JDBC drivers are standard components that allow Java applications to interact with databases. By chaining the automatic refresh of a database range with the loading of a custom JDBC driver, attackers can bypass the macro security model entirely. This highlights a common security challenge: individual features may be secure in isolation, but their interaction can create unexpected attack surfaces.
Why it matters
For teams that self-host their infrastructure or rely on open-source tools for cost and control reasons, this incident underscores the importance of timely patch management. LibreOffice users who update promptly are protected, but those managing fleets of machines must ensure that all endpoints receive the new versions. Delaying updates leaves organizations exposed to potential remote code execution attacks, which could lead to data theft or system compromise.
Apache OpenOffice users face a more difficult situation since no patch is currently available. Many small businesses and legacy systems still depend on OpenOffice due to habit or specific compatibility requirements. These users must actively configure their software to mitigate risk, such as disabling Java support. This workaround may break legitimate functionality that depends on Java, forcing IT managers to balance security against operational needs. It also serves as a reminder to evaluate whether continuing to use software with slower release cycles is sustainable for security-conscious environments.
Furthermore, this vulnerability affects both Windows and Linux environments, dispelling the notion that Linux desktops are immune to such threats. Since many servers and developer workstations run Linux, administrators must verify that their LibreOffice installations are updated. The cross-platform nature of the flaw means that security policies cannot be OS-specific; they must address the application layer consistently across all devices.
What you can do
- Update LibreOffice immediately to version 26.2.5 or 26.8.0 to apply the fix for CVE-2026-63277.
- If using Apache OpenOffice, disable Java support in the application settings to prevent the exploit from running.
- Avoid opening spreadsheets from untrusted sources, especially those that prompt for external data connections.
- Monitor for the release of Apache OpenOffice 4.1.17 and plan to update as soon as it becomes available.
- Audit your organization’s use of Java-enabled features in office suites and restrict them if not strictly necessary.
- Educate users about the risks of enabling Java in office applications and the importance of verifying document sources.



