Hosting en security
Patchen zonder op de CVE te wachten
Het Collabora-lek in Nextcloud werd al misbruikt een maand voordat de CVE verscheen. Update wat aan internet hangt op een vast ritme, niet pas na een advisory.
Een kritiek lek in de ingebouwde Collabora-server voor Nextcloud werd vanaf 10 september misbruikt, terwijl de CVE pas op 14 oktober verscheen. Beheerders die op een advisory wachtten, liepen dus een maand achter. Mijn advies is om alles wat je zelf host en aan internet hangt op een vast ritme te updaten, ook als er geen CVE is.
Wat er gebeurde
Het lek zit in de Nextcloud-app Built-in CODE Server van Collabora Online, met de technische naam richdocumentscode. Via een verzoek aan proxy.php kon iemand zonder in te loggen een commando uitvoeren als de gebruiker van de webserver. Collabora geeft het een CVSS-score van 9,2 en het nummer CVE-2026-110447.
Er zit wel een voorwaarde aan. De aanval werkt alleen als de ingebouwde CODE-server niet draait, bijvoorbeeld na een herstart van de container, een upgrade of een crash.
De tijdlijn laat het probleem zien. De fix stond volgens BleepingComputer op 9 september in de code en versie 26.4.303 kwam op 11 september uit. In het GitHub-issue van het project melden beheerders vanaf 10 en 11 september de eerste aanvallen. De advisory en de CVE volgden op 14 oktober.
Wat de aanvallers deden
De aanvallers zetten PHP-bestanden met namen als shx*.php in de map van de app. Dat zijn webshells: kleine scripts waarmee ze daarna elk commando konden uitvoeren. Op één server zochten ze met die webshell naar databases van wachtwoordmanagers en cryptowallets.
De beheerders in het issue trokken de juiste conclusie. Alles waar de webservergebruiker bij kan, moet je als gelekt beschouwen. Op een Nextcloud-server is dat veel: bestanden van gebruikers en de configuratie van Nextcloud zelf.
Waarom de CVE zo laat kwam
Collabora wijt de vertraging vooral aan GitHub. De tijd om daar een CVE aan te vragen en te publiceren groeide dit jaar volgens Collabora van ongeveer een dag naar vele weken. Collabora zelf kreeg veel beveiligingsrapporten uit AI-tools, van wisselende kwaliteit, en vraagt nu aan om zelf CVE's te mogen uitgeven.
Het probleem is breder dan Collabora. Second Security keek naar 18.594 open source CVE's uit januari tot en met augustus 2026 en mat de tijd tussen de eerste openbare fix in de code en de CVE. In januari was de mediaan 5,1 dagen, in augustus 39,2 dagen. De snelste tiende van de publieke exploits verscheen 1,8 dagen na de fix.
Wie een fix in een openbare repository ziet, kan er een exploit van maken. Een aanvaller hoeft dus niet op de CVE te wachten, en jij kunt dat ook niet meer.
Wat dit betekent voor je team
Een scanner die op CVE's let, ziet zo'n lek pas als de CVE er is. Bij Collabora was dat een maand na de eerste aanvallen. Draai je zelf Nextcloud, GitLab, een wiki of een ander pakket met plugins, dan heb je een ritme nodig dat niet van die feed afhangt.
Bij de update van 26.4.303 vroegen beheerders in het issue nog wat er nu precies gerepareerd was, omdat de release notes geen beveiligingsfix noemden. Op release notes kun je dus ook niet varen. Update omdat er een nieuwe versie is, niet omdat er een reden bij staat.
Zo zou ik beginnen
Maak eerst een lijst van alles wat je zelf host en wat van buitenaf bereikbaar is, inclusief de apps en plugins die erin draaien. Het lek bij Collabora zat in een optionele app, niet in Nextcloud zelf.
Zet daarna een vast updatemoment in de planning, bijvoorbeeld wekelijks voor alles wat aan internet hangt. Automatische updates voor apps en plugins zijn bij een pakket als Nextcloud vaak verstandiger dan wachten tot iemand tijd heeft.
Verwijder wat je niet gebruikt. Bij dit lek was uitschakelen van de app volgens Collabora niet genoeg; alleen updaten of verwijderen hielp. Een app die er niet staat, kan ook niet lekken.
Kies waar het kan de installatievorm die de leverancier aanraadt. De ingebouwde CODE-server is volgens Collabora niet de aanbevolen manier, en de Docker-images en pakketten waren niet kwetsbaar.
Beperk ten slotte waar de webservergebruiker bij kan. Geen wachtwoordkluizen, sleutels of back-ups op dezelfde server, en geen tokens met meer rechten dan nodig. Hoe je back-ups apart houdt, schreef ik in backups en disaster recovery.
Als je de app had draaien
Update naar 26.4.303 of hoger, of verwijder de app. Draai je Nextcloud 29 of ouder, dan noemt de advisory alleen een upgrade van Nextcloud of het verwijderen van de app.
Kijk daarna of er onbekende PHP-bestanden in de map van richdocumentscode staan, zoals shx*.php, en zoek in je logs naar verzoeken aan proxy.php. Eén beheerder in het issue vond het eerste spoor via de integriteitscontrole van Nextcloud, die een onbekend PHP-bestand meldde.
Vind je iets, behandel de server dan als gecompromitteerd. Vervang wachtwoorden en tokens die erop stonden en bouw de server bij voorkeur opnieuw op vanaf een schone basis. Wat andere grote incidenten ons hierover leren, staat in wat we leren van bekende hacks. Twijfel je of je zelf moet hosten, lees dan ook Vercel of zelf hosten.
Bronnen
Veelgestelde vragen
Welke Nextcloud-installaties zijn kwetsbaar voor CVE-2026-110447?
Alleen installaties met de app Built-in CODE Server van Collabora Online (richdocumentscode) onder versie 26.4.303. Losse Collabora-servers, de Docker-images, RPM- en DEB-pakketten en Nextcloud All-in-One zijn volgens Collabora niet kwetsbaar.
Is het genoeg om de app uit te schakelen?
Nee. Volgens de advisory van Collabora helpt uitschakelen niet. Update naar 26.4.303 of hoger, of verwijder de app. Draai je Nextcloud 29 of ouder, dan moet je Nextcloud upgraden of de app verwijderen.
Waarom kun je niet op de CVE wachten?
De tijd tussen een openbare fix en de CVE groeit. Second Security mat een mediaan van 5,1 dagen in januari 2026 en 39,2 dagen in augustus, terwijl de snelste publieke exploits binnen twee dagen na de fix verschenen.
Over de auteur
Aleksa
Tech lead, Belgrado
Aleksa is tech lead in Belgrado. Hij stuurt het developmentteam aan, bewaakt de architectuur en rapporteert aan Erik.
Meer van Aleksa
