SURIQ
Most coverage of today's LibreOffice fixes will tell you not to open spreadsheets from strangers. That advice is fine for a laptop. It misses where the real damage happens: servers that open documents for you. Plenty of hosting, webmail, and file-sync stacks run LibreOffice headless to convert or preview whatever a user uploads, and in that pipeline the person who opens the file is your machine, acting on an attacker's file with nobody to be suspicious.
On October 5, 2026, The Document Foundation published six advisories for LibreOffice. The headline one, CVE-2026-63277, carries a CVSS 4.0 base score of 8.5. A Calc document can name a Java database driver to back an external data link, point that driver at a remote location, and older builds fetch and run it when the document opens. Loading a spreadsheet turns into running someone else's Java code.
Six ways an opened document can reach off your machine
The Java driver bug is the most severe, but it is not alone. The same release closes five more flaws in the code that lets a Calc document link to external data. Read together, they are one design pattern failing six ways: the document says where to get something, and the vulnerable builds went and got it at open time.
| CVE | What an opened document can do | Class |
|---|---|---|
| CVE-2026-63277 | Loads a remote Java database driver and runs its code | Remote code execution |
| CVE-2026-63266 | Writes a file to any folder the user can write, through an embedded Firebird database | Arbitrary file write |
| CVE-2026-63267 | Reads a local file into the sheet or sends a request to a chosen host, on load | Local file read and SSRF |
| CVE-2026-63268 | Reads a local text file into the sheet by naming a folder of files as a database | Local file read |
| CVE-2026-63269 | Reads local files or reaches remote URLs through a linked media playlist (Linux) | Local file read and SSRF |
| CVE-2026-63270 | Expands environment variables and settings-file values into a URL and leaks them | Information disclosure |
Several of these fetch or read automatically as the document loads, with no further click. The comma-separated-value link flaw (CVE-2026-63267) pulls a local file into the sheet or sends a request to a host the document chooses, which is a server-side request forgery (SSRF) primitive: the document makes your machine issue the request. We have covered where an SSRF reaches cloud metadata and the same pattern inside a Red Hat component; a document that can steer outbound requests sits in that risk class.
Turning off macros does not help here
The reflex for a booby-trapped Office file is "macros are disabled, so I am safe." That model gives false comfort. None of these six use Basic macros. They abuse the data-link, database-connector, and media-handling code, which runs no matter what your macro security setting says. Macro hardening changes nothing about this class of bug.
Where this actually bites: headless LibreOffice on a server
LibreOffice is not only a desktop app. Document-conversion services, webmail attachment preview, groupware, and file-sync suites routinely drive it headless to turn an uploaded spreadsheet into a PDF or a thumbnail. In those stacks the file comes from whoever uploaded it, and the open happens unattended. A crafted upload that triggers the automatic fetch, a local file read or an outbound request, or the Java driver load, lands as a server-side problem, not a desktop one. If you run such a pipeline, treat this as a server patch and assume the input is hostile.
There is no public proof-of-concept and no reported exploitation as of this writing. The flaws were reported privately, by Rick de Jager of the V12 security team and by Thomas Rinsma and Edoardo Geraci of Codean Labs, and fixed by Caolan McNamara of Collabora Productivity before disclosure. That is the good window: you can patch ahead of any working exploit.
How to tell if a document pulled the trigger
Patching closes the hole. It does not tell you whether a crafted file already ran through a conversion worker in the window before you patched. The observable is simple: a plain spreadsheet load should not spawn a Java runtime or open an outbound connection. On a Linux host, hunt for either coming from the office process.
soffice --version ps -eo pid,ppid,comm | awk '$3=="java"' ss -tnp 2>/dev/null | grep -i soffice
A Java process whose parent is soffice.bin, or an outbound socket held by soffice.bin during a document load, is the anomaly worth chasing (MITRE ATT&CK technique T1203 for client execution, T1105 for the remote driver fetch). On a conversion host that should only ever be running LibreOffice, any unexpected java process is a lead on its own. A managed SIEM that collects process lineage and outbound connections from your hosts turns this one-off hunt into a standing detection, which is what Suriq's managed service does.
Patch to 26.2.5 or 26.8.0, then audit your conversion pipeline
Upgrade LibreOffice to 26.2.5 or 26.8.0; both ship all six fixes. Older release lines are affected too, so move anything on an unsupported branch onto one of these. Then do the part the desktop advice skips: inventory every server that opens user-supplied documents with LibreOffice, confirm it is on a fixed build, and sandbox the conversion process so a load that does reach out cannot touch anything that matters. The fixes narrow where a document may point, a file URL for the Java class path and a Firebird database confined to its own directory. Your pipeline should assume the next untrusted file tests exactly that boundary.