LibreOffice and OpenOffice Flaws Let Malicious Spreadsheets Run Code Without Macro Warnings
- ID
- 32303
- Status
- summarized
- Published
- 06 Oct 2026, 7:57 PM
- Fetched
- 06 Oct 2026, 9:34 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/10/libreoffice-and-openoffice-flaws-let.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 6.0
- Created
- 06 Oct 2026, 9:35 PM
- Tags
- Audience
- developersdatabase_learners
What happened
Researchers demonstrated that a crafted Calc spreadsheet can make LibreOffice and Apache OpenOffice execute attacker-controlled Java code the moment the file is opened, with no macro-style trust prompt. The chain abuses intended features: a 'database range' in the sheet auto-refreshes from a remote ODB file named by a URL, which in turn names a JDBC driver whose JAR is downloaded and run inside the application. LibreOffice fixed it as CVE-2026-63277 in the October 5 updates (26.2.5 / 26.8.0); Apache OpenOffice has no fix yet for CVE-2026-59265, with every version up to 4.1.16 affected and 4.1.17 still in testing. The attack requires Java support to be enabled, was shown as a proof of concept on Windows and Linux, and has no reported real-world use.
Why it matters
Your existing defence — 'never enable macros in an untrusted document' — does not stop this, because no macro is involved. If your team or clients run LibreOffice, the decision is a version check: anything below 26.2.5 or 26.8.0 needs the October 5 update. If anyone is still on Apache OpenOffice, there is no patch available for any release up to 4.1.16, so the only options today are turning Java off in settings or refusing to open spreadsheets from outside your organisation — worth knowing before you accept a supplier's .ods or .xlsx file. This is especially relevant where open-source office suites are chosen to avoid Microsoft licensing, since those installs often sit on shared or lightly managed machines.
Discussion angle
Every individual feature here works as designed — database ranges, remote ODB sources, JDBC drivers — and the vulnerability only exists in the combination, bypassing a trust prompt the software already has. Worth asking: which of your own tools compose 'safe' features into an unguarded execution path, and how do you decide whether to patch, disable Java, or block file types while Apache OpenOffice stays unfixed?