Ett Offentligt Projekt Är Det Enda Kravet
CVE-2026-85706 kräver nästan ingenting av en angripare för att fungera. Sårbarheten finns i GitLabs API för repository-commits, där bristfällig sökvägsbegränsning och en saknad autentiseringskontroll gör att en oautentiserad användare kan skicka en förfrågan med en filsökvägsparameter och läsa tillbaka godtyckliga filer från servern, helt utan inloggning. watchTowrs Jake Knott sammanfattade tröskeln för utnyttjande i en enda mening: "Utnyttjande kräver bara ett krav, minst ett offentligt projekt måste finnas." De flesta självförvaltade GitLab-installationer har åtminstone ett, oavsett om ägaren tänker på det som utåtriktat eller inte.
Sårbarheten har ett CVSS-betyg på 10.0, det högsta skalan tillåter, och påverkar GitLab Community och Enterprise Edition version 18.7 till 19.1.7, 19.2 till 19.2.5 och 19.3 till 19.3.1. En server som exponeras på det här sättet läcker inte bara källkod. API:et för commits ligger tillräckligt nära konfigurationsfiler, CI/CD-pipelinedefinitioner och driftsättningstoken för att en lyckad läsning ska kunna ge en angripare de uppgifter som krävs för att ta sig vidare in i allt den aktuella GitLab-installationen bygger och driftsätter.
En Patch Fanns Innan Fristen Gjorde
| Datum | Händelse |
|---|---|
| 10 september | GitLab levererar rättelsen i versionerna 19.1.8, 19.2.6 och 19.3.2 |
| 11 september, kl. 06:00 UTC | watchTowrs honeypot-nätverk upptäcker de första försöken i verkligheten |
| 11 september | CISA lägger till CVE-2026-85706 i sin katalog över kända utnyttjade sårbarheter |
| 14 september | Frist för amerikanska federala civila myndigheter att ha patchat |
Mindre än 24 timmar gick mellan att rättelsen levererades och att de första försöken nådde watchTowrs honeypots. CISA:s egen katalogpost följde bara några timmar senare. watchTowrs bedömning är att angriparna redan hade reverse-engineerat och återskapat sårbarheten utifrån själva patchen, samma mönster som gör en offentliggjord sårbarhet till en kapplöpning i samma stund som den blir känd. CISA:s frist binder bara amerikanska federala civila myndigheter, inte ett företag i München eller Manchester, men utnyttjandeförloppet den svarar på stannar inte vid den gränsen.
Den Tredje Servola Har Följt Sedan Augusti
Det här är inte GitLabs första kritiska sårbarhet i sommar, det är den tredje som aktivt utnyttjats inom loppet av ungefär fyra veckor. Servola rapporterade om en GitLab-sårbarhet som paketerades med kritiska brister i Ray och Apple-programvara den 18 augusti, och därefter en GraphQL-kodinjektionsbrist i själva GitLab, CVE-2026-19478, den 24 augusti, en bugg som TheHackerNews egen rapportering om denna nya sårbarhet uttryckligen kopplar till som det tidigare fallet av utnyttjande strax efter offentliggörande. Tre kritiska CVE:er mot en och samma allmänt självhostade plattform på en månad är ingen slump att avfärda som otur. Det är ett tecken på att GitLabs attackyta, och hastigheten med vilken både forskare och angripare nu reverse-engineerar en patch, har sprungit ifrån hur ofta de flesta självförvaltade ägare kontrollerar om det finns en.
Ingen av de tre sårbarheterna delar grundorsak. Det de delar är ett kort tidsfönster, var och en utnyttjades eller undersöktes inom några dagar efter att patchen levererades, inte veckor. En ägare som kontrollerade GitLab-uppdateringar en gång i månaden hade missat det säkra fönstret i alla tre fallen.
Vad Som Förändras För Ett Företag Som Kör Självhostad GitLab
Det konkreta steget är litet: bekräfta att din installation kör 19.1.8, 19.2.6 eller 19.3.2 eller senare, och kontrollera sedan åtkomstloggarna efter POST-förfrågningar mot commits-endpointen för repository med en filsökvägsparameter, den indikator watchTowr rekommenderar att man letar efter. Det större steget är det som faktiskt förhindrar en upprepning. NIS2 kräver redan att EU-organisationer kan visa att de kan verifiera att en patch nått varje förvaltat system, inte bara att GitLab har publicerat en. En självhostad installation utan någon utsedd att bevaka CISA:s KEV-katalog eller GitLabs egna säkerhetsrekommendationer i realtid kommer att fortsätta upptäcka kritiska sårbarheter via en nyhetsartikel istället för via ett övervakningslarm, en arbetsprocess flera nordiska it-avdelningar redan har infört som standard.
Ett företag som behandlar var och en av dessa som en isolerad brandövning klarar den här bra men missar nästa i samma takt. Ett företag som utser någon att äga GitLabs patchtakt på samma sätt som det äger sina brandväggsregler slutar vara tre av tre på sen upptäckt.
Läs vidare: Utnyttjad Veckor Innan PaperCut Patchade | GitLab-brist träffade self-hosted, inte GitLab.com
