Office Suite Flaws: When Opening a Spreadsheet Runs Code

A spreadsheet is not always just a spreadsheetMost security awareness training still tells users not to enable macros. That advice is sound, but it is...

A spreadsheet is not always just a spreadsheet

Most security awareness training still tells users not to enable macros. That advice is sound, but it is no longer sufficient. Two recently disclosed vulnerabilities in popular office suites show that a document can trigger code execution simply by being opened, without any visible macro prompt and without the user clicking anything suspicious. For system administrators, hosting providers and SMEs running their own servers, this is a reminder that endpoint document handling and server-side protection are two halves of the same problem.

What the two flaws actually do

The first issue, tracked as CVE-2026-63277, affects LibreOffice Calc. It abuses the way the application resolves the Java class path when a document requests a database driver. If an entry in that class path points to a remote resource, the document can persuade the suite to load classes from a location controlled by the attacker. The fix tightens this behaviour by requiring every class path entry to be a local file URL, which effectively blocks remote class loading. LibreOffice users should move to version 26.2.5 or later, or 26.8.0 or later, to close the gap.

The second issue, CVE-2026-59265, affects Apache OpenOffice 4.1.16 and earlier. It allows local or remote code execution when a user opens an untrusted document that exploits the Java integration. A stable fix is expected in 4.1.17, but at the time of writing that release is still in candidate form, so organisations need temporary mitigations rather than waiting.

Why this matters for servers and hosting

It is tempting to file this under "desktop problem". That would be a mistake. Many Linux servers run LibreOffice headless to convert documents, generate PDFs from spreadsheets or process invoices received by email. In those pipelines, a malicious file does not need a human to double-click it; it only needs to reach the conversion service. The same applies to shared hosting environments where customers upload files that are later opened by automated tooling. If the process runs with elevated privileges, the blast radius grows quickly.

This is also a GDPR concern. A compromised conversion worker can expose customer data, invoices or personal records stored on the same machine. Under the GDPR, a breach caused by an unpatched document handler still has to be reported, and the reputational cost for a Catalan or Spanish SME can be significant.

Practical mitigations for administrators

Patch LibreOffice now. Upgrade to 26.2.5 or later, or 26.8.0 or later, on every desktop and server that processes documents.
Reduce Java exposure in OpenOffice. If Java integration is not strictly required, disable it until 4.1.17 is stable. In many deployments it is only used for a handful of legacy features.
Run document processing with least privilege. Use dedicated service accounts, containers or sandboxes so that any code execution stays confined.
Filter incoming files. Block or quarantine spreadsheets from unknown senders before they reach automated converters.
Review your office suite strategy. Keeping OpenOffice as a critical component without a predictable patch cycle is a risk that should be weighed against migration to a better-maintained alternative.

Layered defence: documents plus network reputation

Patching closes the known door, but attackers constantly probe for the next one. On servers exposed to the internet, the volume of automated scanning and brute-force attempts is relentless. This is where a centralised protection layer makes a real difference. Abuse Shield, developed by ALMC.es in Lleida, brings together automatic blocking of malicious IPs, managed fail2ban across multiple machines and a shared IP reputation feed. When one server in your fleet detects an abusive source, the others learn about it immediately, so the same attacker is stopped before it reaches your SSH, mail or web services.

Combined with timely patching, this creates a practical defence in depth: documents are handled safely on the endpoint, while the infrastructure itself refuses connections from known bad actors. For hosting companies managing dozens of machines, the shared reputation feed removes the repetitive work of configuring and tuning fail2ban on each host individually.

Act before the next file arrives

The lesson from these two CVEs is simple. A document that someone opens "just to check a figure" can be an execution vector, and every week without an update is a week of unnecessary exposure. Patch LibreOffice, restrict Java in OpenOffice, apply least privilege to document workers and back that up with centralised IP blocking and reputation management. Security is rarely about one perfect control; it is about stacking enough sensible ones that a single mistake does not become a breach.

Put these ideas into practice

Talk to ALMC about a solution for your business. Explore your options or contact our team.

Results without leaving the page.