Nederlanders vinden onafhankelijk van elkaar zelfde lek in OpenOffice

Nederlandse beveiligingsonderzoekers hebben een lek ontdekt in Apache OpenOffice dat ertoe kan leiden dat een aanvaller een heel systeem kan overnemen. Een update die het lek verhelpt is onderweg en is nu een release candidate.

Fedora 10 -- Gnome -- OpenOffice.org 3
Fedora 10 -- Gnome -- OpenOffice.org 3

Alle versies van Apache OpenOffice tot en met 4.1.16 zijn kwetsbaar, blijkt uit de melding van Apache. Het gaat om CVE-2026-63277 en zit in de integratie van de Java-runtime van OpenOffice. Gebruikers die nog niet kunnen of willen updaten naar 4.1.17 kunnen die runtime uitzetten in de instellingen. Het is onbekend of het lek actief misbruikt wordt.

Twee van de drie ontdekkers van het lek zijn Nederlanders. Het gaat om Thomas Rinsma van Codean Labs, die samen met collega Edoardo Geraci het lek ontdekte, en om Rick de Jager van V12 Security. Volgens Apache ontdekten Rinsma en Geraci het lek onafhankelijk van De Jager.

Door Arnoud Wokke

Redacteur Tweakers

06-10-2026 • 14:55

15

Submitter: CriticalHit_NL

Reacties (15)

Sorteer op:

Weergave:

De melding van LibreOffice is wat duidelijker:
When linking spreadsheet cell ranges to external data sources in Calc, a document can specify an external Java database driver. By convincing a user to open a specially crafted document, a remote attacker can force the application to download and execute untrusted Java code from a remote location, resulting in arbitrary code execution.
Tja, als je een externe JDBC driver kunt opgeven die dan gedownload word en geinstalleerd word is het wel game-over ja. Klinkt als een feature die in de 00's een goed idee leek om er in te stoppen.
Het is nooit een goed idee geweest om code van derden zomaar uit te kunnen voeren, hoewel daar in rond de eeuwwisseling wel anders over gedacht werd.

Wat me vooral verbaast is dat er nog steeds software is die code van een arbitraire bron op kan halen en uitvoeren (met dezelfde rechten als de gebruiker), dat was al een slecht idee toen (denk aan de embedded code in Word/Excel e.d. en de ActiveX-controls in IE) en nu (denk aan de aanvallen op npm).

Maar als ik deze reactie goed begrijp zit de bug ook in LibreOffice, als dat zo is zou dit ook wel bij de titel van dit bericht mogen staan...
Toegegeven, ik ben beslist niet op de hoogte van technische details. Maar gezien OpenOffice origineel gebaseerd was op java-code en praktisch niet zonder kan, ga ik er voor het gemak van uit dat de java-koppelingen voor OpenOffice interne code is.

Bij LibreOffice hebben ze hun best gedaan om java uit de interne code te halen, dat java code dus altijd externe code is en een drempel over moet.

Daarmee zijn uitdagingen met java code bij OpenOffice eerder een probleem dan bij LibreOffice.
Ik kan het zo gauw niet vinden, maar geldt dit ook voor Linux?
Er staat in de CVE nergens dat het alleen voor Windows of MacOS is, dus ga er maar vanuit dat het probleem op alle platformen speelt.

Het scheelt wel dat OpenOffice niet zo populair meer is; LibreOffice wordt actiever onderhouden en meer standaard geleverd met Linux distributies. De vraag is alleen nog of LibreOffice niet ook hetzelfde lek bevat, aangezien ze een gedeelde geschiedenis hebben (en de bug mogelijk aanwezig was voor de LibreOffice fork).
De vraag is alleen nog of LibreOffice niet ook hetzelfde lek bevat, aangezien ze een gedeelde geschiedenis hebben (en de bug mogelijk aanwezig was voor de LibreOffice fork).
Het bevat hetzelfde lek, maar is ondertussen ook reeds gepatcht.

[Reactie gewijzigd door wamu op 6 oktober 2026 15:19]

OpenOffice is op sterven na dood. Er zijn ondertussen genoeg forks zoals LibreOffice die beter onderhouden worden. Dit betekent niet automatisch dat er minder lekken in zitten, maar wel dat ze sneller gedicht worden.
Zo te lezen heeft het ook betrekking op LibreOffice en daarmee op de meeste Linux-desktops. Je hebt er evenwel alleen last van als je Java in LibreOffice hebt ingeschakeld. Ik denk dat de meerderheid LibreOffice zonder Java gebruikt.
Het is de koppeling tussen OpenOffice (of LibreOffice) en de java-virutal-machine. Die zit in veel meer software die java-code kan uitvoeren voor add-ons en dergelijke.

Voor zover ik weet is dat onafhankelijk van het besturingssysteem. Maar wel kan LibreOffice zonder java, waar OpenOffice nog best wel afhankelijk is van java code waarmee de jvm daar niet zomaar uit kan.
Onafhankelijk van elkaar maar misschien wel dezelfde LLM gebruikt? Dat kan door de trainingset ook leiden tot gelijke conclusies.
Het is ook open Office en niet closed ms office. /s

Hoe oud is Java nu al niet? Toch gek dat dit soort lekken niet ondertussen al gevonden en gedicht zijn.
Het is zover ik begrijp ook geen lek in Java, maar in het uitvoeren van externe code die zomaar vertrouwd wordt.
Het is de verantwoordelijkheid van de applicatie die gebruik maakt van een JVM (Apache OpenOffice in dit geval) om er voor te zorgen dat de juiste afscherming gebruikt wordt.

Tegenwoordig hebben diverse OS'en sandbox technology waarmee het mogelijk is om de rechten van de uitgevoerde code sterk in te perken. In dit geval zou alleen netwerktoegang naar een bepaalde host toegestaan moeten zijn (in hoeverre de sandbox op dit niveau beperkingen kan opleggen weet ik niet overigens; maar toegang tot het lokale systeem kan wel sterk beperkt worden...)

Om te kunnen reageren moet je ingelogd zijn