GitLab CE/EE (CVE-2026-85706)

Op donderdag 10 september 2026 bracht GitLab een kritieke patchrelease uit. Volgens watchTowr zochten aanvallers de volgende ochtend vanaf 06:00 UTC al gericht naar de fout die daarmee werd verholpen. Voor organisaties die GitLab zelf beheren zaten er dus uren, geen weken, tussen het advies en de eerste pogingen.

Wat is CVE-2026-85706

GitLab omschrijft het zo: onder bepaalde omstandigheden kon een niet-ingelogde gebruiker willekeurige bestanden van de GitLab-server lezen, door onvoldoende afbakening van bestandspaden en ontbrekende authenticatie in de repository commits API. Er faalden dus twee controles tegelijk. De API controleerde niet wie de vraag stelde, en hield het opgevraagde pad niet binnen de plek waar het hoorde. Samen is dat een path traversal die openstaat voor iedereen die de server kan bereiken.

GitLab geeft de fout een score van 10.0 volgens CVSS v3.1. Per 1 oktober 2026 vermeldt NVD de score van GitLab en heeft het geen eigen score gepubliceerd. Kwetsbaar zijn GitLab CE en EE vanaf 18.7 tot de gepatchte versies. GitLab.com en GitLab Dedicated zijn volgens GitLab al bijgewerkt.

Wat de aanvallers deden

watchTowr zag de eerste aftastpogingen in zijn honeypotnetwerk vanaf 06:00 UTC op 11 september 2026, en het Amerikaanse CISA zette de fout dezelfde dag op zijn lijst van actief misbruikte kwetsbaarheden (KEV). In een update aan The Hacker News meldde watchTowr dat aanvallers van aftasten waren overgegaan op geslaagd misbruik: ze haalden configuratiebestanden met geheimen binnen, samen met de SSH-configuratie van het systeem. Volgens watchTowr kan een aanvaller met die combinatie wachtwoorden achterhalen en onder de juiste omstandigheden inloggen op de server zelf.

Dit was een n-day, geen zero-day: eerst kwam de patch, daarna de aanvallen. Het NCSC waarschuwde op 12 september dat de kwetsbaarheid actief werd misbruikt en dat er openbare exploitcode beschikbaar was. Het Duitse BSI volgde op 14 september met een beveiligingswaarschuwing. Per 1 oktober 2026 heeft geen overheid of beveiligingsleverancier publiek een actor achter de aanvallen genoemd.

Waarom het lezen van een bestand bij GitLab zo zwaar weegt

Bij een gewone webserver levert het lezen van een bestand een bestand op. Op een GitLab-server staan de broncode, de pipelines die die code bouwen en uitrollen, en de inloggegevens die die pipelines gebruiken. watchTowr zegt het onomwonden: toegang tot GitLab geeft een aanvaller broncode, CI/CD-geheimen, inloggegevens en de mogelijkheid om code in buildpipelines te injecteren, waarmee alles wat daarna komt besmet kan raken. Het NCSC waarschuwt dat de buitgemaakte gegevens kunnen worden gebruikt om toegang te krijgen tot broncode, ontwikkelomgevingen of andere gekoppelde systemen.

Daarmee gaat het om meer dan het uitlezen van bestanden: dit is een ketenrisico. En net als bij CVE-2018-13379 overleeft de schade de patch: een token of wachtwoord dat in september is gelezen, blijft werken tot iemand het vervangt.

Wat u nu moet doen

• Werk zelfbeheerde GitLab-installaties bij naar 19.3.2, 19.2.6 of 19.1.8, of op oudere reeksen naar 19.0.9 of 18.11.12. Volgens Rapid7 bevatten de patchreleases databasemigraties, dus houd rekening met downtime bij installaties op één server.
• Hing de installatie na 10 september 2026 ongepatcht aan het internet, ga er dan van uit dat er bestanden zijn gelezen. Vervang de wachtwoorden en sleutels in de GitLab-configuratie, de CI/CD-variabelen en tokens waarmee uw pipelines uitrollen, en de SSH-inloggegevens van de server.
• Doorzoek uw logs op POST-verzoeken naar /api/v4/projects/{id}/repository/commits/ met file.path-parameters, het patroon waarop watchTowr adviseert te zoeken. Rapid7 raadt aan ook na de update naar sporen van een inbraak te zoeken.
• Zet GitLab niet zonder reden aan het open internet, ga na of openbare projecten echt nodig zijn, en neem het platform op in de scope van uw penetratietest.