Eén openbaar project is de enige vereiste
CVE-2026-85706 vraagt bijna niets van een aanvaller. Het lek zit in de commits-API van GitLab-repositories, waar een gebrekkige padbeperking en een ontbrekende authenticatiecontrole een niet-ingelogde gebruiker toestaan een verzoek met een bestandspadparameter te sturen en willekeurige bestanden van de server terug te lezen, zonder in te loggen. Jake Knott van watchTowr vatte de drempel samen in een zin: "Misbruik vereist maar één voorwaarde, er moet minstens één openbaar project bestaan." De meeste zelfgehoste GitLab-instanties hebben er minstens een, of de beheerder dat nu als publiek toegankelijk beschouwt of niet.
Het lek heeft een CVSS-score van 10.0, het maximum op de schaal, en treft GitLab Community en Enterprise Edition in de versies 18.7 tot en met 19.1.7, 19.2 tot en met 19.2.5 en 19.3 tot en met 19.3.1. Een op deze manier blootgestelde server lekt niet alleen broncode. De commits-API ligt dicht genoeg bij configuratiebestanden, CI/CD-pipelinedefinities en deploymenttokens dat een geslaagde leesactie een aanvaller de inloggegevens kan geven om dieper door te dringen in wat die GitLab-instantie bouwt en uitrolt.
Er bestond al een patch voor de deadline
| Datum | Gebeurtenis |
|---|---|
| 10 september | GitLab brengt de fix uit in de versies 19.1.8, 19.2.6 en 19.3.2 |
| 11 september, 06:00 UTC | Het honeypotnetwerk van watchTowr registreert de eerste pogingen in het wild |
| 11 september | CISA voegt CVE-2026-85706 toe aan zijn catalogus van bekende, actief misbruikte kwetsbaarheden |
| 14 september | Deadline voor Amerikaanse federale civiele instanties om te hebben gepatcht |
Er zat minder dan 24 uur tussen het uitbrengen van de fix en de eerste pogingen die opdoken op de honeypots van watchTowr. De eigen catalogusvermelding van CISA volgde binnen enkele uren daarna. Volgens watchTowr hadden aanvallers de kwetsbaarheid al gereverse-engineerd en nagebouwd op basis van de patch zelf, hetzelfde patroon dat een openbaarmaking op het moment dat ze publiek wordt meteen in een race verandert. De deadline van CISA bindt alleen Amerikaanse federale instanties, niet een bedrijf in München of Manchester, maar de misbruiktijdlijn waarop die deadline reageert, stopt niet bij die grens.
Het derde lek dat Servola sinds augustus volgt
Dit is niet GitLabs eerste kritieke lek van deze zomer: het is het derde dat binnen ongeveer vier weken actief wordt onderzocht. Servola berichtte op 18 augustus over een GitLab-lek dat samen met kritieke problemen in Ray en Apple-software naar buiten kwam, daarna op 24 augustus over een GraphQL-code-injectielek in GitLab zelf, CVE-2026-19478, een bug waar de eigen berichtgeving van TheHackerNews over dit nieuwe lek expliciet naar terugverwijst als eerder geval van misbruik kort na openbaarmaking. Drie kritieke CVE's tegen een platform dat op grote schaal zelf wordt gehost, binnen een maand, is geen toeval om als pech af te doen. Het is een signaal dat het aanvalsoppervlak van GitLab en de snelheid waarmee onderzoekers en aanvallers een patch tegenwoordig terugbouwen, sneller zijn gegroeid dan het tempo waarin de meeste zelfgehoste beheerders controleren.
Geen van de drie lekken deelt dezelfde oorzaak. Wat ze wel gemeen hebben, is een kort tijdvenster: elk werd binnen dagen na het uitbrengen van de patch onderzocht of misbruikt, niet pas na weken. Een beheerder die maandelijks controleerde op GitLab-updates, zou bij alle drie het veilige venster hebben gemist.
Wat er verandert voor een bedrijf met zelfgehost GitLab
De concrete stap is klein: controleer of uw instantie op 19.1.8, 19.2.6 of 19.3.2 of nieuwer draait, en doorzoek dan de toegangslogs op POST-verzoeken naar het commits-endpoint van de repository met een bestandspadparameter, de indicator waar watchTowr op aanraadt te controleren. De grotere stap is degene die herhaling daadwerkelijk voorkomt. NIS2 vraagt EU-organisaties nu al om aan te tonen dat ze kunnen verifiëren dat een patch elk beheerd systeem heeft bereikt, niet alleen dat GitLab er een heeft uitgebracht. Een zelfgehoste instantie waar niemand is aangewezen om de KEV-catalogus van CISA of de eigen beveiligingsadviezen van GitLab in real time te volgen, blijft kritieke lekken ontdekken via een nieuwsartikel in plaats van via een monitoringmelding. In Nederland verwacht het NCSC-NL van organisaties precies zo'n structurele opvolging van patches.
Een bedrijf dat elk van deze gevallen behandelt als een op zichzelf staande brandoefening, komt deze keer goed weg en mist de volgende op dezelfde snelheid. Een bedrijf dat iemand de verantwoordelijkheid geeft voor het patchritme van GitLab, zoals het dat ook doet voor zijn firewallregels, is niet langer drie keer op rij de laatste die het ontdekt.
Lees hierna: Uitgebuit Weken Voordat PaperCut Patchte | GitLab-lek trof self-hosted, GitLab.com bleef veilig
