Home   2026-10-22 19:56:51

←

NCSC waarschuwt voor actief misbruikte kwetsbaarheid in GitLab

Original article

GitLab bevat een kritieke kwetsbaarheid die cybercriminelen al actief misbruiken. Daarvoor waarschuwt het Nederlandse Nationaal Cyber Security Centrum (NCSC). De kwetsbaarheid zit in de Community Edition en de Enterprise Edition van GitLab. Het NCSC adviseert gebruikers om de beschikbare patches zo snel mogelijk te installeren.

GitLab logoDe kwetsbaarheid, CVE-2026-85706, draait om path traversal. Aanvallers kunnen zonder inloggegevens via internet speciaal gemaakte verzoeken naar een GitLab-server sturen. Zo kunnen ze bestanden op de server lezen en daarmee vertrouwelijke informatie stelen, waarschuwt het NCSC. Het gaat bijvoorbeeld om configuratiegegevens, maar mogelijk ook om wachtwoorden en toegangssleutels. Daarmee kunnen aanvallers toegang krijgen tot broncode, ontwikkelomgevingen of andere gekoppelde systemen.

Volgens het Common Vulnerability Scoring System (CVSS) heeft de kwetsbaarheid een score van 10.0, de hoogst mogelijke. Het NCSC schat zowel de kans op misbruik als de kans op schade als hoog in. Voor de kwetsbaarheid is bovendien al openbare exploitcode beschikbaar, waardoor de drempel voor misbruik laag is. Aanvallers maken dan ook al actief misbruik van het probleem.

Patches beschikbaar

GitLab bracht vorige week al patches uit die de kwetsbaarheid dichten. Gebruikers krijgen het advies om zelfbeheerde GitLab-installaties bij te werken naar versie 19.1.8, 19.2.6, 19.3.2 of een nieuwere versie. "Onderzoek bij internetbereikbare systemen ook de logbestanden op mogelijk misbruik en wijzig mogelijk buitgemaakte toegangsgegevens", zegt het NCSC.

GitLab.com is al bijgewerkt. Gebruikers van GitLab Dedicated hoeven volgens GitLab geen actie te ondernemen.

Door Eveline Meijer

Nieuwsredacteur

Feedback • 14-09-2026 12:27
22 • submitter: CriticalHit_NL

14-09-2026 • 12:27

22

Submitter: CriticalHit_NL

Reacties (22)

Ik heb begrepen dat er ook actief gescanned wordt of iets GitLab is, en 't probeert om deze vulnerability te misbruiken.

Draai zelf geen GitLab, maar wees gewaarschuwd!
stop daarom minstens je webapplicaties achter een proxy als je ze thuis hebt draaien.
Liefste natuurlijk een VPN naar je thuis netwerk.
Een proxy op zichzelf gaat je niet beschermen tenzij je iets als een Web Application Firewall in je proxy hebt zitten.

Afhankelijk van de applicatie kan het offloaden van je authenticatie naar je proxy ook een goede bescherming zijn, bijvoorbeeld basic auth of oauth.

Uiteindelijk gaat het om defence in depth. Dus meerdere beschermlagen toepassen omdat er altijd een laag tussen kan zitten met beveiligingsproblemen. Maar overdrijven gaat ook niet werken want dan ontstaat er teveel frictie en dan heb je ontevreden gebruikers.
Maar overdrijven gaat ook niet werken want dan ontstaat er teveel frictie en dan heb je ontevreden gebruikers.
Klopt, en vergeet ook niet dat zelfs zonder frictie iedere beveiligingslaag zelf een potentieel veiligheidsprobleem kan worden en bijgehouden moet worden.
Blij dat gitlab bij een klant van me achter firewall/VPN zit. Ben wekelijks dat ding aan het updaten en het updaten duurt ook wel even.
Tip: via cloudflare kun je gratis je applicatie achter ztna zetten waardoor je de app alleen kunt bereiken als je ingelogd bent middels SSO. Dus zonder ingelogd te zijn bereikt geen enkel http-request jouw (thuis)server überhaupt.
Tip:

Maak jezelf niet afhankelijk van Amerikaanse dienstverlening. Gebruik een reverse proxy (zoals Traefik of HAProxy) en scherm daarmee zonder inlog diensten af van het internet. Denk aan OIDC en een blokkade op de reverse proxy (zoals met Authelia), mTLS, etc.

Kort geleden omschreef ik hoe ik dit heb opgelost voor Home Assistant in de browser en met mobiele applicaties. Dergelijke oplossingen werken ook met veel andere diensten, waaronder GitLab en Forgejo.

[Reactie gewijzigd door The Zep Man op 14 september 2026 13:27]

Hou alles vooral ook gewoon lekker up-to-date.

Reverse proxy's zijn fantastisch maar op zichzelf ook weer dingen waar (security) issues in kunnen ontstaan.

[Reactie gewijzigd door Polderviking op 14 september 2026 13:35]

Hou alles vooral ook gewoon lekker up-to-date.
Met de steeds kortere periode tussen ontdekken en geautomatiseerd misbruiken van 0-days, laat staan het daarna beschikbaar zijn van updates om kwetsbaarheden op te lossen, is het niet voldoende om alleen hierop te vertrouwen.

[Reactie gewijzigd door The Zep Man op 14 september 2026 13:52]

Ik zeg nergens dat dat het enige is waar je op moet vertrouwen, maar je moet je met een reverse proxy achtige opstelling ook niet laten verlijden tot denken dat dat iets fundamenteels veranderd aan hoe je downstream met dingen als updates om moet gaan.

Uiteindelijk is het gewoon alleen maar een andere (web)server die evengoed aan internet hangt die evengoed een ingang zou kunnen zijn voor ellende.
Natuurlijk moet je je beveiligingsproducten ook actueel houden. Dat spreekt voor zich. ;)
Uiteraard, maar dat is geen magische oplossing, de patch hiervoor is pas vrijdag uitgekomen.
Of hang ModSecurity erachter en houd de ruleset up-to-date, samen met CrowdSec verlaagd dit de load enorm op mijn opstelling en je voorkomt een zeer significant deel van de exploits (waaronder deze).

Uiteraard altijd gewoon je software bij blijven werken, dit is een extra laag, geen totaal oplossing.
Of hang ModSecurity erachter en houd de ruleset up-to-date, samen met CrowdSec
Zie mijn andere reactie. Alleen reactieve beveiliging is niet voldoende, omdat die altijd achterloopt op de werkelijkheid. Hierom is (ook) pro-actief beveiligen belangrijk. Stop (de bulk van) ongewenste sessies bij de poort, niet op het stadsplein.

[Reactie gewijzigd door The Zep Man op 14 september 2026 13:55]

Een goede tip:

Ik gebruik gratis dienst X die zeer veilig is en bekend staat om de betrouwbaarheid, en bovendien super eenvoudig met een paar kliks instelbaar voor m'n thuisnetwerk.

Jouw reactie:

Tip: Maak jezelf niet afhankelijk van mensen met bruin haar! Ga zelf knutselen en hou alles bij en ga een hoop tijd spenderen aan instellen en dan maar hopen dat het goed zit. Ohja, denk daarbij aan X en Y en doe ook nog iets met A, B, etc.

You really don't see it? (< in het engels! Ohnee, die taal niet gebruiken, je maakt jezelf afhankelijk van mensen die engels spreken en die moet je sowieso niet vertrouwen!)
Er zijn wel beperkingen zoals de 100MB upload limit waar je tegen aan kan lopen.
Ik maak uit alle documentatie nu niet op of 18.x ook getroffen is? Er staat voor bepaalde 19 versies. Maar 18.11.11 is nog steeds de laatste op de 18 branch.
Is die niet gewoon out of support inmiddels?
Uit de release notes:
Impacted Versions: GitLab CE/EE: all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2
Gitlab onderhoudt alleen de laatste 3 minor versies (19.1, 19.2 en 19.3 op dit moment). Het eerste getal hogen ze jaarlijks op, dat heeft verder geen betekenis (meer).

Versie 18.11 is dus al sterk verouderd en gaat, gok ik, ook geen fix krijgen hiervoor.
Een maand terug, met de grote GraphQL bug, werd er nog wel een 18.11.x uitgebracht. Dus daarom ging ik er vanuit dat het nu weer ging gebeuren. Maar inmiddels zijn wij ook over naar 19.x. Vorige maand waren er nog issues met een gekke bug tijdens het upgraden, die is nu gelukkig opgelost.

Sowieso hangt onze Gitlab enkel intern, juist om dit soort grappen een beetje voor te zijn.
Build, test, package, and deploy on one platform, so you can move fast without losing control.
Grappig, gebruiken ze hun eigen product wel?
Ik heb net intern bij ons de upgrade uitgevoerd, docker based oplossing.
Ging vlekkeloos verder, ook maar ineens de runners ge-update.

Ik heb meldigen aan staan voor NCSC, maar die had ik blijkbaar toch gemist, bedankt om het nog eens extra onder de aandacht te brengen.

Om te kunnen reageren moet je ingelogd zijn