Kritiek lek in GitLab (CVSS 10.0) binnen één dag al actief misbruikt

GitLab heeft op 10 september een noodpatch uitgebracht voor een kritiek beveiligingslek waarmee een onbevoegde aanvaller, zonder in te loggen, bestanden van de server kon lezen. Het lek kreeg de identifier CVE-2026-85706 en de maximale CVSS-score van 10.0 op een schaal tot 10. Dat maakt het een van de ernstigste kwetsbaarheden van dit jaar. Onderzoeksbureau watchTowr meldt dat de eerste actieve scans naar het lek al rond 06:00 UTC op 11 september binnenkwamen, nog geen etmaal na de bekendmaking.

Wat er misging

Het probleem zat in de repository commits API van GitLab, het onderdeel waarmee de software wijzigingen (commits) in broncode opvraagt en toont. Door een fout in de padcontrole ("path traversal") in combinatie met een ontbrekende authenticatiecheck kon een aanvaller die API zo aanroepen dat GitLab willekeurige bestanden van het eigen serverbestandssysteem teruggaf, zonder dat daar een account of wachtwoord voor nodig was. Volgens de technische analyse van watchTowr en berichtgeving van The Hacker News en SecurityWeek volstond in de praktijk één goed samengestelde HTTP-aanvraag om gevoelige bestanden binnen te halen.

Het lek werd gemeld via het bug bounty-programma van GitLab op HackerOne door een onderzoeker die opereert onder de naam "s3ntago". Getroffen zijn zelf gehoste (self-managed) installaties van GitLab Community Edition en Enterprise Edition vanaf versie 18.7 tot 19.1.8, de 19.2-reeks vóór 19.2.6, en de 19.3-reeks vóór 19.3.2. GitLab.com, de eigen cloudversie van het bedrijf, viel volgens de patch-aankondiging van GitLab zelf niet onder het risico omdat die al bijgewerkt was voordat het lek bekend werd.

Vrijwel meteen misbruikt

GitLab bracht op 10 september de reparatieversies 19.1.8, 19.2.6 en 19.3.2 uit en riep klanten met een zelf gehoste installatie op direct te updaten, zonder te wachten op een geplande onderhoudsronde. Dat advies bleek geen overdreven voorzichtigheid. watchTowr zette na de bekendmaking het eigen honeypot-netwerk in, reproduceerde het lek en zag daarna al binnen ongeveer een dag concrete pogingen tot misbruik langskomen. Ook CISA, het Amerikaanse cyberagentschap, bevestigde actief misbruik en zette CVE-2026-85706 op 11 september op de KEV-lijst (Known Exploited Vulnerabilities), de lijst met kwetsbaarheden waarvan vaststaat dat ze in de praktijk worden gebruikt.

Voor wie wil nagaan of de eigen GitLab-server al doelwit is geweest, adviseert watchTowr de logbestanden te doorzoeken op HTTP POST-aanvragen naar adressen die beginnen met /api/v4/projects/[id]/repository/commits/ en die een parameter met de naam file.path bevatten. Dat patroon wijst op een poging om het lek te misbruiken.

Wat dit betekent voor jouw bedrijf

GitLab wordt veel gebruikt door softwareontwikkelaars en webbureaus om broncode van websites en webshops in te beheren, vaak inclusief configuratiebestanden met wachtwoorden, API-sleutels en toegang tot servers. Draait jouw eigen bedrijf, of de partij die jouw website onderhoudt, een zelf gehoste GitLab-server, dan is dit een lek om serieus te nemen. Kun je zelf niet meteen updaten, beperk dan tijdelijk de netwerktoegang tot de commits-API of zet de server achter een proxy die eerst om inloggegevens vraagt. Controleer daarnaast de logs vanaf 10 september op verdachte verzoeken, en ververs uit voorzorg wachtwoorden, deploy-tokens, SSH-sleutels en CI/CD-geheimen als je iets afwijkends aantreft.

Dit incident laat opnieuw zien dat ook de tools achter de schermen, die zelf nooit door bezoekers worden gezien, een zwakke plek in de beveiliging van je website kunnen vormen als ze niet worden bijgehouden. Wil je dat iemand dat soort software structureel in de gaten houdt voor jouw bedrijf, dan neemt de dienst website-onderhoud en beheer van Infotrends dat uit handen. Meer beveiligingsnieuws voor ondernemers lees je op onze nieuwspagina.

Bronnen: watchTowr, The Hacker News en SecurityWeek.