En forespørsel uten pålogging kunne lese filer fra GitLab-tjeneren

GitLab ga 10. september 2026 ut versjonene 19.3.2, 19.2.6 og 19.1.8 til Community Edition og Enterprise Edition. Blant rettingene sto CVE-2026-85706, en sårbarhet av typen path traversal i API-et som henter commits fra et kodelager. Leverandøren skriver at en bruker uten pålogging under visse forutsetninger kunne lese vilkårlige filer fra tjeneren, fordi API-et verken holdt forespørselen innenfor riktig katalog eller krevde autentisering. GitLab har satt scoren til 10,0, og det er selskapets egen vektor som står i NVD, oppført der som sekundær kilde. Vektoren sier at angrepet kan skje over nettet, med lav kompleksitet, uten rettigheter og uten at noen må gjøre noe.

Dagen etter førte CISA sårbarheten opp i katalogen over kjente utnyttede sårbarheter, med frist 14. september for amerikanske føderale etater. Oppføringen krever ikke bare oppdatering, men også at CISAs krav til forensisk triage følges, og den oppgir at bruk i løsepengeangrep er ukjent. watchTowr skrev samme dag at selskapet hadde reprodusert sårbarheten og at det registrerte sonderinger etter den i sitt globale honeypot-nett. Rådet derfra er å lete i loggene etter POST-forespørsler mot commits-API-et som inneholder parameteren file.path.

Den første rettingen dekket bare de tre nyeste versjonsgrenene, mens sårbare versjoner strekker seg tilbake til 18.7. Rettingen for 19.0.9 og 18.11.12 kom først 23. september. GitLab.com kjørte etter leverandørens opplysning alt en rettet versjon, og kunder på GitLab Dedicated trenger ikke gjøre noe. For installasjoner virksomheter drifter selv ga leverandøren i tillegg ut tre deteksjoner for forsøk på å lese filer gjennom hullet, én av dem for forsøk på å hente konfigurasjonsfilen gitlab.yml.

Hva det betyr for deg som drifter GitLab selv

Spørsmålet som avgjør hvor utsatt du er, er hvilken versjonsgren installasjonen står på. Er du på 19.1, 19.2 eller 19.3, fikk du en rettet versjon 10. september og kan lukke saken med en oppgradering. Ligger installasjonen på 18.7 til 18.11 eller på 19.0, kom det ingen rettet versjon under 19.1.8 før 23. september, da GitLab tilbakeførte rettingen til 19.0.9 og 18.11.12. Fristen i KEV-katalogen gikk ut 14. september, altså ni dager før rettingen nådde de eldre grenene. Fra 10. september lå rettingen bare lenger opp, altså et sprang ut av egen gren. Vår vurdering er at et slikt gap ikke lar seg dekke av oppdateringsrutiner alene. Det som virker i mellomtiden, er å ta tjeneren av det åpne internettet eller sette en sperre foran den, og noen må ta den beslutningen mens gapet står åpent.

Så er det spørsmålet om noe alt har skjedd. CISA ba om forensisk triage og ikke bare om oppdatering, og det rådet gjelder deg selv om ingen amerikanske direktiver binder deg. En feil som gir lesetilgang uten pålogging etterlater seg lite annet enn linjer i en logg, og filene den kunne nå, kan være de samme filene som inneholder hemmelighetene i byggekjeden. Klarer du ikke å utelukke at noen har hentet gitlab.yml eller tilsvarende, er det nøklene som må skiftes, ikke bare versjonsnummeret.

Berigo anbefaler

• Finn alle GitLab-installasjoner virksomheten drifter selv, og skriv ned det nøyaktige versjonsnummeret på hver av dem.
• Oppgrader til 19.3.2, 19.2.6, 19.1.8, 19.0.9 eller 18.11.12, avhengig av hvilken gren installasjonen står på.
• Ta GitLab av det åpne internettet der tjenesten ikke må nås derfra, og sett pålogging eller VPN foran resten.
• Gå gjennom loggene for commits-API-et fra tiden før du oppgraderte, og ta i bruk de tre deteksjonene GitLab ga ut.
• Bytt hemmeligheter som lå lesbart på tjeneren, altså nøkler i oppsettet og variabler i byggekjeden, hvis du ikke kan utelukke at de er lest.