Eine manipulierte Tabellenkalkulationsdatei kann LibreOffice Calc oder Apache OpenOffice dazu bringen, beim Öffnen Java-Code zu laden und auszuführen, den ein Angreifer kontrolliert. Das zeigt ein kürzlich veröffentlichter Proof of Concept.
Die Technik nutzt die Unterstützung der Office-Suiten für externe Datenbankquellen und Java Database Connectivity-Treiber. Sie kommt ohne herkömmliches Dokumentmakro aus. Den Forschern zufolge löste der getestete Ausführungspfad auch nicht die Makro-Sicherheitswarnung aus, die Nutzer möglicherweise erwarten würden.
Damit der Angriff funktioniert, muss Java aktiviert sein. Die Forscher demonstrierten die Technik unter Windows und Linux. Die Schwachstelle beschränkt sich demnach nicht auf ein einzelnes Betriebssystem.
Zwei Schwachstellen stehen mit dem Problem in Verbindung: CVE-2026-63277 in LibreOffice Calc und CVE-2026-59265 in Apache OpenOffice. Für LibreOffice sind Updates verfügbar. Die korrigierte OpenOffice-Version befindet sich den vorliegenden Berichten zufolge noch in der Testphase.
Externe Datenbankverknüpfungen als Weg zur Codeausführung
Die Angriffskette kombiniert legitime Funktionen für Tabellen, Datenbanken und die Java-Integration.
Calc-Dokumente können Datenbankbereiche enthalten, die Informationen aus einer externen Quelle importieren. Die Verknüpfung ist in der Tabelle gespeichert, sodass die Anwendung die verknüpften Daten beim Öffnen des Dokuments abrufen und aktualisieren kann.
Im Szenario der Forscher verweist die Tabelle über eine Webadresse auf eine externe OpenDocument Database-Datei (ODB). Nachdem die Office-Anwendung diese Datei abgerufen hat, verarbeitet sie deren Datenbankkonfiguration.
Die ODB kann einen JDBC-Treiber und den Speicherort angeben, von dem die Java-Klassen des Treibers geladen werden sollen. Dabei kann es sich um eine URL zu einer JAR-Datei auf einem entfernten Server handeln. Die Anwendung ruft den Treiber dann ab und startet ihn. Dadurch wird sein Java-Code innerhalb des Prozesses der Office-Anwendung ausgeführt.
So kann ein Angreifer über ein präpariertes Dokument beliebigen Java-Code ausführen:
- Der Nutzer öffnet eine manipulierte Tabellenkalkulationsdatei.
- Das Dokument aktualisiert einen eingebetteten Datenbankbereich.
- Die Anwendung ruft eine in der Tabelle referenzierte ODB-Datei ab.
- Die ODB gibt einen JDBC-Treiber und den Speicherort seines Codes an.
- Die Anwendung lädt den Treiber und führt dessen Java-Code aus.
Für ihre harmlose Demonstration nutzten die Forscher die Codeausführung, um den Taschenrechner zu öffnen. Die Proof-of-Concept-Dateien waren der Einfachheit halber lokal gespeichert. Die Forscher zufolge könnte ein Angreifer die Datenbankdatei und die Java-Nutzlast jedoch auch auf einer Infrastruktur hosten, die er selbst kontrolliert.
Entscheidend ist, dass der Nutzer das Dokument öffnet. Der beschriebene Angriffspfad erfordert nicht, dass das Opfer ein Makro über die im Originalbericht beschriebene Warnmeldung freigibt.
LibreOffice behebt CVE-2026-63277 in zwei Versionszweigen
Laut dem Artikel sind alle LibreOffice-Versionen vor 26.2.5 beziehungsweise 26.8.0 betroffen. Je nach installiertem Versionszweig sollten Nutzer auf 26.2.5 oder 26.8.0 aktualisieren.
Der Bericht nennt den 5. Oktober als Veröffentlichungsdatum für Updates mit der Korrektur, gibt aber kein Jahr an. Das vorliegende Material enthält auch kein separates Datum für die Entdeckung oder die öffentliche Bekanntgabe.
Die Beschreibung von CVE-2026-63277 durch NVD konzentriert sich darauf, dass ein Calc-Zellbereich im Dokument mit einer externen Datenquelle verknüpft bleiben kann. Eine manipulierte Datei kann über diese Verknüpfung einen Java-Datenbanktreiber angeben, dessen Code auf einem entfernten Server liegt.
Die Korrektur schränkt Einträge im Java-Klassenpfad ein. In den behobenen LibreOffice-Versionen muss ein solcher Eintrag eine Datei-URL verwenden. Damit wird das entfernte Laden von Code verhindert, auf dem der demonstrierte Angriff beruht.
CVE-2026-63277 ist als CWE-829 klassifiziert. Diese Kategorie erfasst Funktionen, die ohne ausreichende Schutzmaßnahmen von außerhalb des vorgesehenen Kontrollbereichs eingebunden werden.
Die LibreOffice-Schwachstelle wurde unabhängig voneinander von Rick de Jager aus dem V12 security team sowie von Thomas Rinsma und Edoardo Geraci von Codean Labs gemeldet. Caolán McNamara von Collabora Productivity entwickelte die Korrektur für LibreOffice.
OpenOffice-Nutzer warten auf Version 4.1.17
Apache OpenOffice 4.1.16 und frühere Versionen sind von CVE-2026-59265 betroffen. NVD beschreibt die Schwachstelle als Problem mit der Java-Integration, durch das ein nicht vertrauenswürdiges Dokument beim Öffnen beliebigen Code ausführen lassen kann – auch Code, der aus dem Internet geladen wird.
Die geplante Korrektur soll in Apache OpenOffice 4.1.17 erscheinen. Das vorliegende Material beschreibt diese Version jedoch noch als Release Candidate und gibt nicht an, dass sie endgültig veröffentlicht wurde.
Bis 4.1.17 verfügbar ist, empfiehlt NVD, Java runtime integration im Einstellungsdialog zu deaktivieren. Laut der Schwachstellenbeschreibung von NVD verhindert das diesen Angriff.
Wenn sich die Java-Integration nicht deaktivieren lässt, sollten Nutzer zumindest keine Dateien aus nicht vertrauenswürdigen Quellen öffnen. Sobald die endgültige Version 4.1.17 verfügbar ist, sollten betroffene Installationen aktualisiert werden.
CVE-2026-59265 ist als CWE-426 eingestuft. Diese Kategorie betrifft nicht vertrauenswürdige Suchpfade. Codean Labs wird als Entdecker der OpenOffice-Schwachstelle genannt. Das V12-Team veröffentlichte einen Proof of Concept für beide Office-Suiten.
Java ist erforderlich, eine Makrofreigabe jedoch nicht
Die unmittelbare Folge ist, dass Code mit den Rechten ausgeführt wird, unter denen die Office-Anwendung läuft. Ein Angreifer könnte statt der harmlosen Taschenrechner-Anwendung aus der Demonstration auch anderen Java-Code ausführen lassen.
Für die Technik müssen mehrere Bedingungen erfüllt sein: Das Opfer muss das präparierte Dokument erhalten und öffnen, und Java muss in der betroffenen Office-Suite aktiviert sein. Anschließend muss die Anwendung die externen Datenbank- und Treiberverweise aus der Angriffskette verarbeiten.
Dass die beschriebene Makro-Sicherheitswarnung ausbleibt, verändert die Annahmen, auf die sich Nutzer beim Umgang mit verdächtigen Tabellen stützen. Wer davon ausgeht, dass potenziell ausführbarer Inhalt stets eine herkömmliche Makrowarnung auslöst, erhält bei diesem Angriffspfad möglicherweise keinen entsprechenden Hinweis.
Die Forscher testeten den Proof of Concept sowohl unter Windows als auch unter Linux. Das belegt, dass sich die Technik in den Testumgebungen plattformübergreifend einsetzen lässt. Es zeigt jedoch nicht, dass alle Konfigurationen der beiden Betriebssysteme gleichermaßen betroffen sind.
Den Berichten zufolge sind keine Angriffe mit diesen Schwachstellen in freier Wildbahn bekannt. Das ist eine Aussage aus der veröffentlichten Forschung und keine unabhängige Bestätigung dafür, dass es nie zu einer Ausnutzung gekommen ist.
Die vorliegenden NVD-Auszüge enthalten weder einen CVSS-Score noch einen CVSS-Vektor für eine der beiden Schwachstellen. Auch Angaben zum Status im Katalog „Known Exploited Vulnerabilities“ (KEV) der CISA oder zu einer Behebungsfrist fehlen. Daraus sollte nicht geschlossen werden, dass die CVEs nicht im KEV-Katalog aufgeführt sind.
Was Administratoren und Nutzer tun sollten
LibreOffice-Administratoren sollten den installierten Versionszweig prüfen und Systeme mit betroffenen Versionen auf 26.2.5 oder 26.8.0 aktualisieren. Die Korrektur passt die Verarbeitung des Java-Klassenpfads so an, dass die betreffenden Einträge Datei-URLs sein müssen.
Bei OpenOffice ist die Lage schwieriger, da 4.1.17 bislang als Release Candidate beschrieben wird. Für Installationen mit 4.1.16 oder früher empfiehlt NVD als konkrete Übergangsmaßnahme, Java runtime integration zu deaktivieren.
Organisationen, die Java-Funktionen benötigen, sollten bis zur Veröffentlichung der korrigierten OpenOffice-Version strengere Regeln für den Umgang mit Dokumenten einführen. Nutzer sollten insbesondere keine unerwarteten Tabellen oder Dokumente aus Quellen öffnen, deren Vertrauenswürdigkeit sich nicht überprüfen lässt.
Sicherheitsteams können außerdem prüfen, ob die Java-Integration in verwalteten Office-Installationen tatsächlich benötigt wird. Der Verzicht auf eine unnötige Laufzeitkomponente verringert das Risiko durch diese Angriffskette. Er ersetzt jedoch nicht die Installation einer korrigierten Softwareversion, sofern bereits ein Update verfügbar ist.
Der entscheidende Unterschied ist einfach: Für LibreOffice sind den vorliegenden Berichten zufolge bereits korrigierte Versionen verfügbar. OpenOffice-Nutzer müssen sich dagegen bis zur endgültigen Veröffentlichung von 4.1.17 mit der empfohlenen Schutzmaßnahme behelfen.
