Zum Inhalt springen

LibreOffice-Lücke: Remote-Angriff ohne Authentifizierung möglich

7. Mai 2026 durch
LibreOffice-Lücke: Remote-Angriff ohne Authentifizierung möglich
Tom Ziegler

Für LibreOffice liegt eine Sicherheitswarnung mit mittlerer Risikoeinstufung vor: Ein entfernter, anonymer Angreifer kann eine Schwachstelle in der Office-Suite ausnutzen, um einen nicht näher spezifizierten Angriff auszuführen. Betroffen ist LibreOffice als Produktfamilie; für Administratoren gehören damit alle eingesetzten LibreOffice-Installationen in den Prüfbestand, solange sie im eigenen Patch-Management nicht eindeutig als abgesichert geführt werden. Besonders relevant ist die Lücke dort, wo LibreOffice Dokumente aus externen Quellen verarbeitet — etwa auf Arbeitsplatzsystemen, in Terminalserver-Umgebungen oder in automatisierten Konvertierungsdiensten. Die zentrale Eigenschaft der Schwachstelle ist der Angriff ohne vorherige Authentifizierung.

Warum die Einstufung „mittel“ nicht harmlos ist

Eine mittlere Einstufung führt in vielen Unternehmen dazu, dass Tickets hinter kritischen Remote-Code-Execution-Fällen zurückstehen. Bei Office-Software ist das riskant. LibreOffice sitzt häufig direkt an der Schnittstelle zwischen externen Daten und internen Benutzerkonten: Anwender öffnen Anhänge, speichern Dokumente aus Webportalen oder verarbeiten Dateien aus Kunden- und Partnerkommunikation. Wenn eine Schwachstelle aus der Ferne und ohne Anmeldung ausnutzbar ist, reicht unter Umständen schon die Zustellung eines präparierten Inhalts an einen geeigneten Verarbeitungspfad.

Der Warnhinweis beschreibt keinen Angriff gegen eine Serverkomponente mit Login-Barriere, sondern eine Schwachstelle, die ein anonymer Remote-Angreifer adressieren kann. Für die Verteidigung ist diese Unterscheidung wichtig: Nicht nur exponierte Systeme im Internet zählen, sondern auch Clients und interne Dienste, die fremde Dokumente öffnen, indexieren, konvertieren oder in Vorschauen rendern. Gerade LibreOffice wird in vielen Umgebungen nicht nur interaktiv genutzt, sondern auch headless für Datei-Konvertierungen eingesetzt. Solche Prozesse laufen oft mit Service-Accounts und sind im Alltag weniger sichtbar als klassische Desktop-Installationen.

Technische Einzelheiten wie eine benannte CVE-Kennung, ein CVSS-Wert oder ein betroffener Codepfad liegen im vorliegenden Warntext nicht vor. Für die praktische Bewertung ändert das wenig: Die Schwachstellenklasse ist aus Betriebssicht als Angriff auf die sichere Verarbeitung von Office-Dokumenten zu behandeln. Bei Office-Suites stehen dabei besonders Parser, Importfilter, Makro- und Dokumentfunktionen sowie Rendering-Pfade im Fokus. Admins sollten deshalb nicht nur nach installierten Paketen suchen, sondern auch nach Diensten, die LibreOffice im Hintergrund aufrufen.

Wo LibreOffice im Unternehmen oft übersehen wird

Auf klassischen Linux-Desktops ist LibreOffice leicht zu inventarisieren. Schwieriger wird es auf Terminalservern, VDI-Images, Fachanwendungsservern und in Container-Umgebungen. Dort landet LibreOffice häufig als Abhängigkeit für PDF-Erzeugung, Dokumentenvorschau oder Stapelkonvertierung. Solche Installationen werden seltener aktiv genutzt, bleiben aber angreifbar, wenn sie Dateien aus nicht vertrauenswürdigen Quellen verarbeiten. Ein Helpdesk-Portal, das hochgeladene Office-Dateien automatisch in PDF umwandelt, ist aus Angreifersicht oft interessanter als ein einzelner Arbeitsplatz.

Auch E-Mail-Gateways und DMS-Workflows verdienen Aufmerksamkeit. Wenn Anhänge automatisiert analysiert oder konvertiert werden, entsteht ein vorgelagerter Angriffspfad, der nicht von der Aufmerksamkeit einzelner Nutzer abhängt. Selbst wenn die Warnung nur als „mittel“ eingeordnet ist, kann die Kombination aus anonymer Erreichbarkeit, automatisierter Verarbeitung und erhöhten Rechten den operativen Schaden deutlich vergrößern. Die Risikobewertung sollte daher nicht allein am Schweregrad hängen, sondern an der Frage, wo LibreOffice mit fremden Dokumenten in Berührung kommt.

Pragmatische Absicherung bis zum Rollout

Admins sollten die Lücke wie einen typischen Office-Datei-Angriffsweg behandeln: Inventarisieren, Update-Pfad klären, externe Dokumentflüsse begrenzen und Ausführungskontexte prüfen. Entscheidend ist, ob LibreOffice direkt oder indirekt Daten aus E-Mail, Web-Uploads, Ticketsystemen oder Filesharing-Diensten verarbeitet. Wo das der Fall ist, sollten Workflows temporär stärker isoliert werden, etwa durch getrennte Service-Accounts, restriktive Dateirechte und eine Ausführung in abgeschotteten Umgebungen.

Für Desktop-Systeme bleibt Patch-Management der wichtigste Schritt. Gleichzeitig sollten Security-Teams ihre Erkennung auf ungewöhnliche LibreOffice-Prozesse schärfen: Headless-Aufrufe, Kindprozesse aus Office-Kontexten, Zugriffe auf temporäre Verzeichnisse und Konvertierungsprozesse mit externen Eingabedateien sind gute Ansatzpunkte für Monitoring. In Managed-Endpoint-Umgebungen lohnt sich außerdem ein Abgleich, ob LibreOffice über Betriebssystempakete, Drittanbieter-Repositories oder manuelle Installationen verteilt wurde. Unterschiedliche Bezugswege führen schnell zu uneinheitlichen Patchständen.

Für PLUTEX-Kunden und interne IT-Teams gilt: Die Warnung ist kein Grund für Panik, aber ein guter Anlass, Office-Verarbeitung als Angriffsfläche ernst zu nehmen. Priorität haben Systeme, die ohne Nutzerinteraktion Dateien aus externen Quellen verarbeiten oder LibreOffice als Backend-Komponente einsetzen. Dort sollte ein Wartungsfenster früher eingeplant werden als bei isolierten Einzelplatzsystemen.

  • LibreOffice-Installationen vollständig inventarisieren, inklusive Servern, Images und Containern.
  • Verfügbare Sicherheitsupdates über den etablierten Paket- oder Softwareverteilungsweg einspielen.
  • Automatisierte Dokumentkonvertierung bis zur Aktualisierung isolieren oder einschränken.
  • Monitoring auf auffällige LibreOffice- und Headless-Prozesse schärfen.
LibreOffice-Lücke: Remote-Angriff ohne Authentifizierung möglich
Tom Ziegler 7. Mai 2026
Diesen Beitrag teilen