Eine Fachabteilung erhält eine Kalkulation von einem Lieferanten. Makros sind gesperrt, die Datei wird geöffnet, eine Warnung bleibt aus. Genau diese vermeintliche Sicherheit stellen neue Veröffentlichungen zu LibreOffice Calc und Apache OpenOffice Calc infrage: Eine präparierte Tabelle kann über eine externe Datenbankverbindung Java-Code nachladen und ausführen. Der dokumentierte Weg benötigt keine Makrofreigabe, setzt aber installierte und aktivierte Java-/JDBC-Unterstützung voraus. [1,2,3]
Für Unternehmen ist das ein konkretes Endpoint-Security-Thema. Die praktische Prüffrage lautet nicht nur, ob Makros erlaubt sind, sondern welche weiteren Funktionen eines Dokuments Netzwerkzugriffe und ausführbaren Code erreichen können. Unsere Einordnung: Dokumentenverarbeitung gehört als eigene Ausführungsumgebung in die Sicherheitsarchitektur, auch wenn die Oberfläche wie eine gewöhnliche Tabelle aussieht.
Was tatsächlich neu ist
LibreOffice veröffentlichte am 5. Oktober 2026 seine Sicherheitsinformation zu CVE-2026-63277. Als korrigierte Versionsstände nennt das Projekt 26.2.5 und 26.8.0. Das Veröffentlichungsdatum des Advisories ist dabei nicht automatisch das Erscheinungsdatum dieser Programmversionen. Die technische Bekanntmachung liegt im aktuellen Recherchefenster; es handelt sich nicht lediglich um eine neu datierte Zusammenfassung alter Meldungen. [1]
Das entsprechende OpenOffice-Problem CVE-2026-59265 wurde bereits am 2. Oktober über die Sicherheitsmailingliste bekannt gemacht. Betroffen sind laut Apache Version 4.1.16 und älter. Zum Recherchestand am 7. Oktober befindet sich die vorgesehene Korrekturversion 4.1.17 noch in der Release-Candidate-Phase. Apache empfiehlt bis dahin, die Java-Laufzeitintegration abzuschalten. [2,4]
Die am 6. Oktober erschienene Berichterstattung und die öffentlich zugängliche V12-Dokumentation verbinden diese Versionsinformationen mit einer nachvollziehbaren Angriffskette. Ein öffentlich demonstrierter Machbarkeitsnachweis ist allerdings kein Beleg für bereits kompromittierte Unternehmensarbeitsplätze. [3,5]
Wie eine Datenverbindung zur Codeausführung wird
Der Ausgangspunkt ist ein in der Tabelle gespeicherter Datenbankbereich mit automatischer Aktualisierung. Dieser verweist auf ein externes ODB-Dokument, also eine Datenbankdatei. Beim Öffnen der Tabelle wird die Datenquelle aufgelöst und die ODB-Datei geladen. Deren JDBC-Konfiguration benennt wiederum einen Java-Datenbanktreiber und den Ort seines Programmcodes. [3]
JDBC ist die Java-Schnittstelle für Datenbankzugriffe. Ein Treiber ist dabei nicht bloß eine Konfigurationsdatei, sondern ausführbarer Code. In der beschriebenen Kette stammt er aus einem entfernten JAR-Archiv. Calc lädt den Treiber und erzeugt eine Instanz, ohne zuvor eine mit der Makrofreigabe vergleichbare Vertrauensentscheidung einzuholen. Die Demonstration startet lediglich einen Taschenrechner; entscheidend ist die erreichte Möglichkeit zur Ausführung fremden Java-Codes. [3]
Die Sicherheitsgrenze wird damit beim Übergang von Dokumentinhalt zu Laufzeitkonfiguration überschritten. Ein extern angeliefertes Dokument darf faktisch bestimmen, welcher Code in der Anwendung ausgeführt wird. LibreOffice beschreibt als Korrektur, dass ein Eintrag im Java-Klassenpfad eine Datei-URL sein muss. Das ist eine konkrete Beschränkung dieses Ladepfads, keine allgemeine Garantie für die Harmlosigkeit beliebiger Dokumente. [1]
Voraussetzungen und Grenzen der Aussage
Für den dokumentierten Angriff müssen Java und JDBC verfügbar und aktiviert sein. Außerdem muss das präparierte Dokument geöffnet werden. Beim beschriebenen entfernten Nachladen müssen die referenzierten Ressourcen erreichbar sein. Eine Formulierung wie „jede empfangene Tabelle übernimmt automatisch den Rechner“ wäre deshalb falsch. [3]
Ebenso wenig belegen die Quellen eine erfolgreiche massenhafte Ausnutzung. Die aktuelle Berichterstattung nennt einen Proof of Concept und keine bekannten realen Angriffe. Daraus folgt aber keine Entwarnung für verwundbare Installationen: Es bedeutet lediglich, dass öffentlich belegte Angriffszahlen fehlen. [5]
Unsere Risikobewertung sollte deshalb Installation, Konfiguration und Verarbeitungspfad gemeinsam berücksichtigen. Eine isolierte Testmaschine ohne geschäftliche Berechtigungen ist anders zu priorisieren als ein Arbeitsplatz mit Zugriff auf Kundenunterlagen und interne Freigaben. Diese Priorisierung ist eine betriebliche Empfehlung, keine Aussage über beobachtete Opfer dieses Falls.
Warum das über klassische Office-Sicherheit hinausgeht
Der Fall illustriert ein Architekturproblem: Eine Kontrolle kann korrekt funktionieren und trotzdem nicht den relevanten Ausführungspfad abdecken. Wer nur nach Makroausführung fragt, übersieht hier die Datenbankintegration. Die beschriebenen Schritte nutzen gerade Funktionen außerhalb der klassischen Makrofreigabe. [3]
Für Unternehmen empfehlen wir deshalb, auch automatisierte Dokumentenprozesse zu inventarisieren. Dazu gehören beispielsweise Konvertierungsdienste, Importstrecken und agentengestützte Arbeitsabläufe, sofern diese tatsächlich eine betroffene Office-Laufzeit aufrufen. Das ist eine Übertragung der technischen Erkenntnisse auf mögliche Unternehmensarchitekturen, kein Nachweis, dass solche Dienste oder KI-Agenten in diesem Fall bereits angegriffen wurden.
Die entscheidende Frage lautet dort: Mit welchen Rechten, Zugangsdaten und Netzwerkverbindungen verarbeitet die Anwendung fremde Dateien? Ein KI-Agent als Auftraggeber macht einen Dokumentenparser weder sicherer noch unsicherer; wichtig ist, welche technischen Möglichkeiten der nachgelagerte Prozess erhält.
Was Unternehmen jetzt konkret tun sollten
1. Laufende Version und Java-Konfiguration prüfen. Unsere Empfehlung ist eine gezielte Bestandsaufnahme statt einer pauschalen Warnmail. Erfassen Sie die tatsächlich eingesetzten Office-Versionen, zusätzliche portable Installationen und vorhandene Automatisierungsumgebungen. Prüfen Sie die Java-Einstellung in der Anwendung; allein eine installierte Java-Laufzeit beantwortet die Expositionsfrage nicht.
2. LibreOffice aktualisieren, OpenOffice gezielt entschärfen. Für LibreOffice nennt der Hersteller 26.2.5 beziehungsweise 26.8.0 als korrigierte Stände. Bei OpenOffice beschreibt Apache als Zwischenmaßnahme unter „Extras – Einstellungen – OpenOffice – Java“ das Deaktivieren der Java-Laufzeitumgebung; unter macOS liegt die Einstellung im Preferences-Dialog. Vor einer Wiederaktivierung sollte die freigegebene Korrekturversion anhand des Herstellerhinweises geprüft werden. [1,2]
3. Geschäftliche Abhängigkeiten testen. Wir empfehlen, vor einer breiten Java-Abschaltung relevante Datenbankfunktionen mit den Fachbereichen zu prüfen. Eine nötige Ausnahme sollte einen Verantwortlichen, einen dokumentierten Zweck und ein Ablaufdatum erhalten. Für unvermeidbare Verarbeitung unbekannter Dateien ist eine gesonderte, eingeschränkte Umgebung sinnvoller als eine dauerhafte Ausnahme auf privilegierten Arbeitsplätzen.
4. Ausgehende Verbindungen und Prozessrechte begrenzen. Als ergänzende Architekturmaßnahme sollten Dokumentenprozesse nur die Netzwerkziele erreichen, die ihr Arbeitsauftrag benötigt. Verwenden Sie keine administrativen Konten für normale Dokumentenarbeit. Für automatisierte Verarbeitung empfehlen wir separate Identitäten, begrenzte Dateifreigaben und möglichst kurzlebige Laufzeitumgebungen. Diese Maßnahmen ersetzen die Korrektur nicht, begrenzen aber den möglichen Folgeschaden.
5. Bei Verdacht untersuchen, nicht nur aktualisieren. Unsere Empfehlung an Incident-Response-Teams: Verdächtige Originaldateien sichern, Öffnungszeitpunkte rekonstruieren und zeitlich passende Netzwerk- sowie Prozessereignisse prüfen. Unerwartete Downloads von Datenbank- oder Java-Archiven können Prüfhinweise sein, sind allein aber kein Beweis. Ein fehlender Alarm rechtfertigt umgekehrt keine abschließende Entwarnung. Produktive Systeme sollten nicht durch das unkontrollierte Öffnen des öffentlichen Demonstrationsdokuments getestet werden.
Fazit
Die neue LibreOffice-Veröffentlichung und der parallele OpenOffice-Hinweis rechtfertigen eine konkrete Überprüfung von Versionen und Java-Integration. Die weitergehende Lehre lautet: Dokumentensicherheit lässt sich nicht auf Makros reduzieren. Unternehmen sollten fremde Tabellen als Eingaben mit möglichen Nebenwirkungen behandeln und die Rechte ihrer Verarbeitungsumgebung entsprechend begrenzen. Das ist eine überprüfbare technische Aufgabe, keine Aufforderung zur Panik.
Quellen
- LibreOffice: Security Advisories, CVE-2026-63277, bekannt gemacht am 5. Oktober 2026
- Apache OpenOffice: Herstellerhinweis zu CVE-2026-59265
- V12 Security: Office JDBC Classpath Bugs, technische Dokumentation für beide Produkte
- Apache-Mitteilung auf oss-security vom 2. Oktober 2026
- The Hacker News: LibreOffice and OpenOffice Flaws Let Malicious Spreadsheets Run Code Without Macro Warnings, 6. Oktober 2026
