Een spreadsheet die je opent in LibreOffice of Apache OpenOffice, kan in een verleidelijke maar gevaarlijke val lopen: onderzoekers laten zien dat er LibreOffice OpenOffice code kan worden uitgevoerd zonder dat je eerst een duidelijke macro-waarschuwing ziet. Daarmee omzeilt de aanval de vertrouwde beveiligingsvraag die je normaal bij macro’s verwacht.
Het goede nieuws: LibreOffice heeft de kwetsbaarheid inmiddels gepatcht. Voor Apache OpenOffice is er (op moment van publicatie) nog geen definitieve fix beschikbaar, maar je kunt wél maatregelen nemen om risico te beperken.
Wat is er precies aan de hand?
De kern van de kwestie is dat Calc-spreadsheets in zowel LibreOffice als OpenOffice functies combineren die op zichzelf bedoeld zijn om te werken zoals ontworpen. De combinatie maakt het mogelijk om code te laten uitvoeren tijdens het openen van een bestand.
Onderzoekers beschrijven dat het niet draait om klassieke macro’s. Er is dus geen voorafgaande waarschuwing zoals bij het draaien van macrocode. In plaats daarvan wordt misbruik gemaakt van een mechanisme dat cellen kan laten verversen door data uit een externe bron op te halen.
Hoe werkt de aanval zonder macro?
De aanval gebruikt een keten van stappen die samen leiden tot code-uitvoering:
- De spreadsheet bevat een database range: een blok cellen dat automatisch externe data kan ophalen en verversen.
- Die externe bron wordt gespecificeerd via een adres dat in de sheet is opgenomen.
- Bij het openen haalt het programma dat bronbestand op, een databasebestand (een ODB).
- In het ODB-bestand kan een Java database driver worden opgegeven (een JDBC-driver) plus waar die drivercode zich bevindt.
- De applicatie downloadt vervolgens de benodigde Java-componenten (bijvoorbeeld als een JAR), waarna de driver in de context van het programma kan starten.
Elk onderdeel van deze keten werkt op zich normaal. De veiligheidsschaamte ontstaat doordat de gebruiker niet expliciet wordt gevraagd of hij de inhoud vertrouwt, zoals gebeurt bij macro’s.
Wat zien onderzoekers in de praktijk?
In het proof of concept tonen de onderzoekers aan dat de drivercode bijvoorbeeld een applicatie kan starten. Dat gebeurt in hun demonstratie als voorbeeldactie (Calculator als herkenbare, onschuldige vervanger). De onderzoekers geven daarbij aan dat in dezelfde logica andere Java-code kan worden uitgevoerd die de aanvaller kiest.
Ze hebben de proef ook getest op zowel Windows als Linux. Volgens de onderzoekers is de kwetsbaarheid niet gebonden aan één specifiek besturingssysteem.
Daarnaast benadrukken ze dat de proof of concept in de demo op één machine stond, maar dat een echte aanval realistischer zou uitgaan van bestanden die op een server van de aanvaller staan.
Welke versies zijn getroffen?
De problemen worden als aparte kwetsbaarheden gevolgd:
- LibreOffice: CVE-2026-63277. De kwetsbaarheid is opgelost in updates van 5 oktober. Gebruikers wordt aangeraden te upgraden naar 26.2.5 of 26.8.0. Versies vóór die releases zijn beïnvloed.
- Apache OpenOffice: CVE-2026-59265. Een fix is nog niet beschikbaar. Elke versie tot en met de actuele release 4.1.16 is volgens het project geraakt. Men verwacht een oplossing in 4.1.17, dat nog getest wordt.
Hoe voorkom je problemen in LibreOffice?
Voor gebruikers en beheerders van LibreOffice ligt de oplossing vooral in updaten. Als je versie onder de genoemde veilige releases valt, is het verstandig om direct te migreren naar 26.2.5 of 26.8.0.
Plan daarnaast kort de impact: controleer of je omgeving afhankelijk is van specifieke extensies of instellingen, zodat updates beheerst kunnen worden uitgerold. Zo verklein je de kans dat een securitypatch botst met interne automatiseringen.
Wat kun je doen als je OpenOffice gebruikt?
Omdat Apache OpenOffice (nog) niet gepatcht is, is het zaak om de aanval te blokkeren met configuratie- of gebruikersmaatregelen.
Concreet adviseren onderzoekers het volgende:
- Java uitzetten binnen de instellingen van OpenOffice.
- Niet-vertrouwde spreadsheets niet openen. Beperk dus het openen van bestanden die je niet kunt herleiden of beoordelen.
In een enterprise-omgeving betekent dit meestal: beperk het gebruik van Java in de kantoorapplicatie waar mogelijk en maak de omgang met externe bestanden strikter. Denk aan een proces voor veilig aanleveren en controleren van documenten.
Waarom dit extra relevant is voor security teams
Deze casus laat goed zien hoe beveiliging rond documenten kan worden omzeild door legitieme functies te combineren. In plaats van een macro die je herkent, wordt een pad gevolgd waarin downloads en drivers starten zonder dat het systeem je om toestemming vraagt.
Dat is een aandachtspunt dat breder past bij het thema “documenten als aanvalsvector”, zeker wanneer organisaties met open source kantoorsuites werken en veel extern ontvangen bestanden verwerken.
Wil je dit verder doortrekken naar jouw aanpak voor incidentpreventie en risicoinschatting, dan kan dit gerelateerd zijn aan andere soorten document- of access-incidenten binnen organisaties. Bijvoorbeeld over datalekken via toegangsmechanismen en externe koppelingen: CPR datalek via bedrijfstoegang: 8,8 miljoen geraakt.
Snelle checklist voor beheerders
Als je vandaag nog wilt handelen, kun je onderstaande stappen gebruiken:
- Inventariseer welke versies van LibreOffice en Apache OpenOffice er in gebruik zijn.
- Prioriteer updates voor LibreOffice naar minimaal 26.2.5 of 26.8.0.
- Zet Java uit in OpenOffice totdat versie 4.1.17 beschikbaar is.
- Maak afspraken over het openen van spreadsheets van buitenaf: alleen vertrouwde bronnen, en bij twijfel eerst scannen of blokkeren.
- Documenteer uitzonderingen: als gebruikers toch bestanden moeten openen, leg vast hoe je dan risico beheerst.
Zo voorkom je dat risico “verstopt” raakt in een gebruikelijke workflow.
Slotconclusie
Onderzoekers tonen aan dat LibreOffice OpenOffice code kan worden uitgevoerd via kwaadaardige spreadsheets zodra een bestand wordt geopend, zonder de macro-waarschuwingen die veel mensen als vangnet zien. LibreOffice heeft inmiddels een patch voor CVE-2026-63277; Apache OpenOffice heeft nog geen fix, maar Java uitschakelen en wantrouwig omgaan met niet-vertrouwde spreadsheets kan het risico aanzienlijk beperken.
Door snel te updaten of de juiste instellingen door te voeren, houd je kantoorfunctionaliteit én beveiliging beter in balans—en voorkom je dat een ogenschijnlijk onschuldig document alsnog code laat draaien.
Bron: https://thehackernews.com/2026/10/libreoffice-and-openoffice-flaws-let.html
