GitLab-lek met score 10: wie moet nu updaten?

Wie GitLab op een eigen server draait, moet de beveiligingsversie controleren. Een kritiek lek kan een aanvaller onder bepaalde omstandigheden eigen code laten uitvoeren zonder eerst in te loggen. Gebruik je alleen GitLab.com, dan hoef je deze serverupdate niet zelf te installeren: die omgeving is al bijgewerkt.

GitLab publiceerde de reparaties op 21 oktober. Het Nederlandse Nationaal Cyber Security Centrum waarschuwde op 22 oktober voor twaalf kwetsbaarheden in Community Edition (CE) en Enterprise Edition (EE). Het ernstigste lek, CVE-2026-110264, kreeg een ernstscore van 10 op 10. Volgens het NCSC is actief misbruik nog niet vastgesteld.

Eerst vaststellen: wie beheert jouw GitLab?

GitLab helpt teams samen software te ontwikkelen, broncode te bewaren en het bouwen en testen te automatiseren. De naam van het product alleen zegt niet wie de beveiligingsupdate uitvoert.

Voor Nederlandse ontwikkelteams en dienstverleners is dat onderscheid belangrijk. Een eigen GitLab-server vraagt ander handelen dan een account bij GitLab.com. Deze waarschuwing betekent niet dat iedere WordPress-beheerder of websitebezoeker iets moet installeren.

Zo controleer je de versie

Ben je ingelogd op een zelf beheerde of Dedicated-omgeving, open dan linksonder Help en kies opnieuw Help. Bovenaan die pagina staat het versienummer. GitLab beschrijft deze route in de officiële uitleg voor versiecontrole. Heb je geen beheerdersrol of wordt GitLab door een leverancier beheerd, stuur het versienummer dan niet op goed geluk door: vraag de verantwoordelijke partij expliciet of de reparatie voor CVE-2026-110264 is geïnstalleerd.

Welke versies dichten het kritieke lek?

De onderstaande grenzen gelden uitsluitend voor CVE-2026-110264. GitLab heeft de reparatie voor dit kritieke lek ook naar oudere versiereeksen teruggebracht.

Bron: de officiële GitLab-beveiligingsuitgave van 21 oktober 2026. Dit is geen garantie dat alle twaalf kwetsbaarheden in iedere oudere reparatieversie zijn opgelost: de overige lekken hebben eigen versiegrenzen. Controleer daarom het volledige beveiligingsbericht en de ondersteunde upgrade-route, inclusief eventuele verplichte tussenstappen. Spring niet zonder die controle van een oude hoofdversie naar de nieuwste.

Vier controles vóór de upgrade

GitLab adviseert beheerders om vóór een upgrade niet alleen een back-up te maken, maar ook een rollbackplan en de vereiste upgrade-stappen vast te leggen. De officiële handleiding noemt daarnaast gezondheidscontroles vóór en na de installatie. Praktisch betekent dat:

1. bepaal via de officiële upgrade-route of tussenstappen nodig zijn;
2. maak een actuele back-up van de installatie, configuratie en geheimen;
3. leg vast hoe je bij problemen naar de vorige werkende versie terugkeert;
4. controleer na de upgrade onder meer inloggen, projecten, repositories en CI/CD-taken.

De volledige voorbereiding staat in GitLabs handleiding vóór het upgraden. Deze checklist vervangt de instructies voor jouw installatievorm niet.

Ernstscore 10 betekent niet dat een aanval al vaststaat

Het kritieke lek zit in een onderdeel dat zoekpatronen verwerkt, zogenoemde reguliere expressies. Volgens GitLab kan daar bij een speciaal samengesteld patroon een rekenfout ontstaan, waardoor een aanvaller zonder account onder bepaalde omstandigheden code op de server kan uitvoeren.

Het NCSC beoordeelt de kans op misbruik als gemiddeld en de mogelijke schade als groot. Dat zijn andere beoordelingen dan de technische ernstscore. Een score van 10 is dus geen kanspercentage en geen bewijs dat jouw server al is overgenomen.

Bijwerken én controleren

GitLab verwijst naar twee detectieregels waarmee beheerders van eigen installaties kunnen zoeken naar mogelijke misbruikpogingen. Die verwijzingen staan in de officiële beveiligingsuitgave, naast de upgrade-instructies. Een beveiligingsupdate voorkomt niet dat eerder misbruik nog onderzoek kan vergen.

Houd bij de uitvoering rekening met de installatievorm. GitLab meldt dat de update bij een installatie op één server een onderbreking veroorzaakt doordat databasewijzigingen moeten worden uitgevoerd. Bij meerdere servers is bijwerken zonder onderbreking mogelijk als de juiste procedure wordt gevolgd. Stem dit af met de verantwoordelijke beheerder.

Lees de Nederlandse waarschuwing en het technische beveiligingsadvies NCSC-2026-0447 bij het NCSC. Bekijk daarnaast ons overzicht van Nederlandse cyberwaarschuwingen. De afzonderlijke PHP-waarschuwing voor websitebeheerders betreft andere software en vereist een eigen controle.