Ét Offentligt Projekt Er Det Eneste Krav
CVE-2026-85706 kræver næsten intet af en angriber for at fungere. Sårbarheden findes i GitLabs API til repository-commits, hvor mangelfuld sti-afgrænsning og en manglende autentificeringskontrol lader en uautoriseret bruger sende en forespørgsel med en filsti-parameter og læse vilkårlige filer tilbage fra serveren, uden krav om login. watchTowrs Jake Knott satte ord på adgangsbarrieren i én sætning: "Udnyttelse kræver kun ét krav, mindst ét offentligt projekt skal eksistere." De fleste selv-administrerede GitLab-installationer har mindst ét, uanset om ejeren tænker på det som offentligt tilgængeligt eller ej.
Sårbarheden har en CVSS-score på 10.0, det højeste skalaen tillader, og påvirker GitLab Community og Enterprise Edition version 18.7 til 19.1.7, 19.2 til 19.2.5 og 19.3 til 19.3.1. En server, der er eksponeret på denne måde, lækker ikke kun kildekode. API'et til commits ligger tæt nok på konfigurationsfiler, CI/CD-pipeline-definitioner og deployment-tokens til, at en vellykket læsning kan give en angriber de adgangsoplysninger, der skal til for at bevæge sig videre ind i alt det, den pågældende GitLab-installation bygger og udruller.
En Rettelse Fandtes Før Fristen Gjorde
| Dato | Begivenhed |
|---|---|
| 10. september | GitLab udsender rettelsen i versionerne 19.1.8, 19.2.6 og 19.3.2 |
| 11. september, kl. 06:00 UTC | watchTowrs honeypot-netværk registrerer de første forsøg i det fri |
| 11. september | CISA tilføjer CVE-2026-85706 til sit katalog over kendte udnyttede sårbarheder |
| 14. september | Frist for amerikanske føderale civile myndigheder til at have rettet fejlen |
Der gik under 24 timer fra rettelsen blev udsendt, til de første forsøg ramte watchTowrs honeypots. CISA's egen katalogpost fulgte inden for få timer derefter. watchTowrs vurdering er, at angriberne allerede havde reverse-engineeret og genskabt sårbarheden ud fra selve rettelsen, det samme mønster, der gør en offentliggørelse til et kapløb, i det øjeblik den bliver kendt. CISA's frist binder kun amerikanske føderale civile myndigheder, ikke en virksomhed i München eller Manchester, men det udnyttelsesforløb, den er en reaktion på, stopper ikke ved den grænse.
Den Tredje, Servola Har Fulgt Siden August
Dette er ikke GitLabs første kritiske sårbarhed i sommer, det er den tredje, der er blevet aktivt afprøvet inden for cirka fire uger. Servola dækkede en GitLab-sårbarhed, der blev udsendt sammen med kritiske fejl i Ray og Apple-software den 18. august, og derefter en GraphQL-kodeindsprøjtningsfejl i selve GitLab, CVE-2026-19478, den 24. august, en fejl som TheHackerNews' egen dækning af denne nye sårbarhed direkte kæder sammen med som det tidligere tilfælde af udnyttelse kort efter offentliggørelse. Tre kritiske CVE'er mod én udbredt selv-hostet platform på en måned er ikke en tilfældighed, man bare kan ryste af sig som uheld. Det er et signal om, at GitLabs angrebsflade og den hastighed, hvormed både forskere og angribere nu reverse-engineerer en rettelse, er løbet fra, hvor ofte de fleste selv-administrerede ejere selv tjekker for en.
Ingen af de tre sårbarheder har samme grundårsag. Det, de deler, er et komprimeret tidsvindue, hver af dem blev afprøvet eller udnyttet inden for dage efter, rettelsen blev udsendt, ikke uger. En ejer, der kun tjekkede for GitLab-opdateringer én gang om måneden, ville have overset det sikre vindue i alle tre tilfælde.
Hvad Det Ændrer For En Virksomhed, Der Kører Selv-Administreret GitLab
Det konkrete skridt er lille: bekræft, at din installation kører 19.1.8, 19.2.6 eller 19.3.2 eller nyere, og tjek derefter adgangslogs for POST-forespørgsler mod commits-endpointet for repositories med en filsti-parameter, det indikator, watchTowr anbefaler at holde øje med. Det større skridt er det, der reelt forhindrer en gentagelse. NIS2 kræver allerede, at EU-organisationer kan dokumentere, at en rettelse er nået ud til hvert eneste administrerede system, ikke blot at GitLab har udsendt én. En selv-hostet installation uden nogen udpeget til at overvåge CISA's KEV-katalog eller GitLabs egne sikkerhedsråd i realtid vil fortsat opdage kritiske sårbarheder gennem en nyhedsartikel i stedet for gennem en overvågningsalarm, en arbejdsgang mange nordiske it-afdelinger allerede har formaliseret.
En virksomhed, der behandler hver af disse som en isoleret brandøvelse, vil klare denne fint og overse den næste med samme hastighed. En virksomhed, der udpeger nogen til at eje GitLabs patch-rytme, ligesom den ejer sine firewall-regler, holder op med at være tre ud af tre på sen opdagelse.
Læs videre: Udnyttet Uger Før PaperCut Nåede At Patche | GitLab-fejl ramte self-hosted, ikke GitLab.com
