Summary: On October 5 the LibreOffice project published advisories for six CVEs in Calc's external-data plumbing — including CVE-2026-63277, remote Java code execution triggered by opening a crafted spreadsheet (CVSS4 8.5). The fixes have been shipping in LibreOffice 26.2.5 and 26.8.0 for weeks; Debian bookworm has no fixed version; Apache OpenOffice carries the same code-exec bug (CVE-2026-59265) with the remedy still an unreleased release candidate. If the machines your community runs — treasurer's laptop, city hall desktops, volunteer workstations — open spreadsheets from outside, this is the week to check what package those machines actually get.

Opening a spreadsheet should not be dangerous. On October 5 the LibreOffice project posted six new CVEs on its security page, all of them reachable through one Calc feature most users have never consciously touched: the ability to link a cell range to an external data source, with the link saved inside the document. That mechanism — calcext:data-mappings plus Calc's sql, csv, and Firebird data providers — turned out to be a delivery system for everything from silent file reads to remote code execution. The documents themselves were the payload.

What the six actually do

The advisories were announced October 5, credited to Thomas Rinsma and Edoardo Geraci of Codean Labs, with the code-execution vector reported independently by Rick de Jager of the V12 security team. All fixes are by Caolán McNamara of Collabora. Reading them in order of what they let an attacker do:

  • CVE-2026-63277 — RCE (CVSS4 8.5). A Calc data link can name a Java database driver, and the driver class was loaded from a remote location the document chose. Opening the document runs Java code from that location. This is the headline: arbitrary code execution from an office document, the exact class everyone associates with Word macro malware. The fix makes a Java class path entry resolve to a file URL only.
  • CVE-2026-63266 — arbitrary file write. An embedded Firebird database attached to a data link could write a file anywhere the user could write to. Fixed versions confine embedded Firebird to its own private directory.
  • CVE-2026-63267 — local file read + SSRF. An external csv link was fetched while the document loaded, which could pull a local file's contents into the visible sheet — or make a GET request to a host of the document's choosing. Fixed versions put document-supplied data links under the ordinary link-update control, the one that asks before refreshing anything.
  • CVE-2026-63268 — local file read. A sql-type link could name a folder of local text files as a database and read them into the sheet on open.
  • CVE-2026-63269 — local file read + SSRF through a media codec. A document can link audio and video; on Linux LibreOffice plays them with GStreamer, and a crafted HLS playlist made GStreamer read files and URLs listed inside it, their contents ending up in the document.
  • CVE-2026-63270 — environment and ini-file leaks. Links could expand environment variables or ini-file values and exfiltrate the result to a remote server. This one broke through the check added for CVE-2024-12426 — XForms instance data and the Calc csv and sql providers still reached the expansion. Fixed versions refuse internal-scheme URLs that come from the document.

Two things worth noticing in that list. First, the bug class is not parser memory corruption — it is the feature surface: external-link plumbing that was reaching too far in every direction, files, networks, the Java runtime, the media stack. Second, the recurring unit of fix is the one that should be boring and isn't: a link placed in a document by a third party must never load, read, fetch, or execute anything without the same explicit consent a user gives their own web link. That is the policy the fixed versions now apply in six places.

The same announcement cycle also surfaced older memory-safety entries on the security page — including a heap buffer overflow in WMF import (CVE-2026-63272, found by Anthropic's agents — reported by Ada Logics) — so the parsing bugs this site has written about are arriving on schedule there too. But the document-as-payload story this week is the external-data hole.

The distribution problem: your patch depends on your package

Fixed versions are LibreOffice 26.2.5 and 26.8.0. Those releases have existed for a while — 26.2.5 shipped in late July, 26.8.0 in August — which makes the October 5 announcement date a statement about publishing, not patch availability, and the gap is now a liability in both directions. Users of current releases were exposed-and-advertised-to weeks later; users of distro-packaged office suites have spent that window with no advisory telling them why the new package matters.

What your machine actually gets depends on the distro, and Debian's tracker shows the spread concretely as of tonight:

  • trixie: fixed, via DSA-6543-1 in 4:25.2.3-2+deb13u8. apt update && apt upgrade closes it.
  • bookworm: still listed vulnerable, no fixed version published yet. This matters because a large share of community-network volunteer machines, office desktops, and family laptops run Debian oldstable or a derivative of its lineage. If bookworm is your base, watch for the incoming DSA rather than assuming the archive is clean.
  • sid: fixed at 4:26.2.5.2-1.

If you run Ubuntu, a Debian derivative, or a rolling distro, check your own tracker entry for these CVE numbers before you relax — the Debian page's status is a data point, not a guarantee about your distro. Package lineage is where this vulnerability family hides, because "already patched upstream" and "the binary running on the treasurer's laptop" are different claims joined only by a maintainer's backport queue.

The harder problem is Apache OpenOffice

The same code-execution defect exists in Apache OpenOffice, where it was assigned CVE-2026-59265: "a crafted untrusted document can trigger the execution of arbitrary, even remote, code when it is opened." Severity per Apache: critical. Affected: all versions through 4.1.16 — which is the current release — and OpenOffice.org versions may also be affected.

The difference is what happens next. LibreOffice shipped fixes in existing releases. The OpenOffice advisory says the fix is expected in 4.1.17, which is in release-candidate phase — there is no patched release to install as of tonight. Until one ships, the mitigation is manual and per-machine: Tools → Options → OpenOffice → Java, and untick "Use a Java runtime environment." LibreOffice gives no workaround for CVE-2026-63277 in the advisory, though the same logic applies: the vector enters through the Java database-driver path, so a machine that has no Java integration bound into office documents has no route to the RCE.

This site keeps making the positive case for LibreOffice, because the format-sovereignty argument holds — the Euro Office's migration was the cleanest sovereignty data point Europe produced last month (covered here). The other side of that case is not LibreOffice's bug — it is that OpenOffice has been maintained only minimally — heise's phrase is "nur noch sehr rudimentär gepflegt" — long enough that when a critical document-exploit lands, the fix is an unreleased RC. If you have any OpenOffice installs left anywhere in an organization you support — older city-hall machines and volunteer hand-me-downs are where it survives — the honest recommendation was true before this CVE and is urgent now: the migration target is LibreOffice, and the migration is also the patch. Disabling the Java integration is the interim move on every machine you cannot touch right away.

The threat model for a community org — and the short checklist

Who sends a fire hall or a 3,000-person town a spreadsheet? Granting bodies with budget templates, vendors with invoices, a neighboring municipality sharing a per-capita sheet, an organizer with a roster, an attacker with a working exploit and any of the above as camouflage. The user-writable surface on a typical office desktop includes the user's own documents, browser data, and quite possibly an SSH key or two. The low-end CVEs in this set read files out of that surface quietly into a spreadsheet cell; the top one executes code. None of this requires a server. It requires one person opening one attachment.

What to do this week, in order:

  1. Inventory the office suite on every shared machine you support. Version first: LibreOffice Help → About (or libreoffice --version). Anything below 26.2.5 (or 26.8.0) on an affected branch needs the update; anything named OpenOffice needs a migration plan, starting with the Java checkbox.
  2. On Debian-family machines, check the tracker, not hope. apt-cache policy libreoffice-core will show you what the archive offers today; the DSA for trixie is out; bookworm's fix had not landed when this was written.
  3. Close the feature where it does no work. A community office that never links Calc ranges to live external data sources loses nothing by treating those links as hostile — after updating, that is the default the fix already gives you. Keep it in mind when you review any policy about which documents get opened on which machines; the machines that handle money (treasurer, accountant, admin desk) are the ones where "only I open attachments" does not survive contact with reality.
  4. Say the quiet part in your briefing: the server your self-hosted stack runs on was not the attack surface this week. The desktop next to it was. Community infrastructure posts tend to be about the servers because that is the layer you chose; this one is about the machine in the front office, which no one chose to be an attack surface but gets to be one anyway.

No known in-the-wild exploitation is documented as of tonight — neither vendor reports it, and the advisories frame this as researcher-driven code analysis. That is the same position the MikroTrick documents were in at disclosure, and the honest reading is identical: the absence of published exploitation is worth less with every month, and the patch costs an update window you are going to spend eventually anyway.

The one-sentence version: the fixes are already in the software — LibreOffice 26.2.5/26.8.0, and any distro that has picked them up — but the software on your users' machines is not the software in the release notes. Getting from one to the other is the whole of the security work for community-scale deployments. This week it is urgent, because the exploit class is the oldest one in personal computing, and OpenOffice users are still waiting on the binary that closes it.

Sources: LibreOffice security advisories page, updated October 5, 2026 (CVE-2026-63266, 63267, 63268, 63269, 63270, 63277); Apache OpenOffice advisory CVE-2026-59265; Debian security tracker, CVE-2026-63277 and DSA-6543-1; heise online, LibreOffice/OpenOffice Codeschmuggel warning.