Aanvallers misbruiken lek in ingebouwde Collabora-app van Nextcloud

Beheerders van zelfgehoste Nextcloud-servers moeten deze week even in hun app-lijst kijken. Aanvallers misbruiken actief een lek in de Collabora Online Built-in CODE Server-app, de optionele app die een complete Collabora-kantoorsuite meelevert zodat je documenten in Nextcloud kunt bewerken zonder een aparte server op te tuigen. Het lek heeft sinds 14 oktober een nummer: CVE-2026-110447. De aanvallen begonnen volgens BleepingComputer al medio september.

Wat er precies misgaat

Het advies van Collabora beschrijft een OS command injection in proxy.php, het onderdeel waarmee de app de meegeleverde CODE-server opstart. Een speciaal opgebouwd verzoek laat een commando uitvoeren onder het account van de webserver. Er is geen inlog en geen actie van een gebruiker nodig.

Er zit één voorwaarde aan: de ingebouwde CODE-server moet op dat moment níet draaien. Dat is minder beschermend dan het klinkt, want dat gebeurt bij elke herstart van de container, bij elke upgrade en na elke crash.

Belangrijk is ook wat er niet geraakt wordt. Volgens Collabora zijn losstaande Collabora Online-servers niet kwetsbaar, en ook Docker-, RPM- en DEB-installaties en Nextcloud All-in-One blijven buiten schot. Het gaat uitsluitend om de ingebouwde variant, het pakket dat in de appstore richdocumentscode heet.

Bijwerken, of weghalen

Het lek is verholpen in richdocumentscode 26.4.303. Alles daarvoor is kwetsbaar. De leverancier waarschuwt expliciet dat het uitschakelen van de app niet genoeg is: je moet bijwerken naar 26.4.303 of nieuwer, of de app verwijderen als je hem niet gebruikt.

Dat is geen theoretisch advies. Beheerders melden aanvallen op meerdere endpoints die teruggaan tot 10 september. Volgens die meldingen plaatsten de aanvallers PHP-webshells en gingen ze daarmee op zoek naar wachtwoorddatabases, resten van wachtwoordmanagers en cryptowallets. Er zijn ook meldingen dat ransomware-groepen het lek gebruiken, maar BleepingComputer kon dat niet zelf vaststellen. Wie een kwetsbare versie heeft gedraaid, doet er goed aan niet alleen bij te werken maar ook te controleren op onbekende PHP-bestanden en uitgaande verbindingen.

Een maand tussen fix en waarschuwing

De tijdlijn is het interessantste deel van dit verhaal. De fix werd op 9 september ingecheckt, versie 26.4.303 kwam op 11 september uit, en het officiële advies plus het CVE-nummer volgden pas op 14 oktober. Ruim vier weken lang stond de oplossing dus publiek in de broncode zonder dat er een nummer aan hing waarop beheerders konden filteren. Een communitywaarschuwing op 3 oktober riep al op direct bij te werken.

Dat gat is geen incident. Beveiligingsbedrijf Second Security onderzocht open source-lekken en kwam uit op een mediaan van 39 dagen tussen een publieke fix en de CVE-publicatie in augustus, tegen 5,1 dagen in januari. In veel gevallen stond er werkende exploitcode online binnen enkele uren na de fix, dagen voordat het CVE verscheen. De onderzoekers wijzen op de groeiende stroom AI-geassisteerde kwetsbaarheidsvondsten die het CVE-proces verstopt, en op AI-tooling waarmee aanvallers snel een exploit uit een publieke commit kunnen bouwen.

Voor wie thuis of op kantoor zelf hostet, betekent dat iets praktisch: wachten op een CVE-nummer in je scanner is geen betrouwbaar signaal meer. Changelogs van de apps die je echt gebruikt zijn dat eerder.