Den 10 september 2026 släppte GitLab en nödpatch för Community Edition och Enterprise Edition. Dagen efter hamnade en av bristarna, CVE-2026-85706, på CISA:s lista över aktivt utnyttjade sårbarheter. Poängen är maximal: CVSS 10,0. Enligt säkerhetsfirman Censys finns över 86 000 GitLab-servrar exponerade mot internet, och hotforskare vid watchTowr Labs såg redan innan patchen hunnit spridas att angripare testade sig fram mot sårbara installationer. För organisationer i Sverige och övriga Norden som kör GitLab i egen regi, från kommuner till fintech-bolag, är det en påminnelse om hur snabbt ett utvecklarverktyg kan bli en väg rakt in i källkod, hemligheter och byggpipelines.
Vad är CVE-2026-85706?
CVE-2026-85706 är en sökvägstraverseringsbrist (CWE-22) i commits-API:et för repositories i GitLab. Enligt GitLabs egen säkerhetsbulletin, publicerad den 10 september 2026, kunde en oautentiserad användare under vissa förutsättningar läsa godtyckliga filer från en drabbad GitLab-server. Orsaken är en kombination av bristfällig sökvägsbegränsning och saknad autentiseringskontroll i just detta API-anrop. I praktiken betyder det att en angripare, utan att logga in, kunde skicka en särskilt utformad förfrågan och få tillbaka innehållet i filer som aldrig var tänkta att exponeras, till exempel konfigurationsfiler med lösenord, API-nycklar eller andra hemligheter som lagras på servern.
Sårbarheten upptäcktes genom GitLabs egna bug bounty-program på HackerOne, vilket är den vanligaste vägen bolaget använder för att hitta allvarliga fel innan de hittas av någon annan. Den här gången hann dock verkligheten ikapp forskningen. Redan dagen efter att patchen publicerades rapporterade hotforskningsfirman watchTowr att man observerade sonderande trafik mot internetexponerade GitLab-instanser, ett tecken på att angripare aktivt letade efter servrar som ännu inte hade uppdaterats.
CVSS 10,0: vad den högsta poängen faktiskt betyder
CVSS-skalan går från 0 till 10, och en poäng på 10,0 är reserverad för fall där attacken kräver minimal ansträngning men ger maximal skada. Enligt CVSS-vektorn för CVE-2026-85706 krävs ingen autentisering, ingen användarinteraktion och attacken kan genomföras över nätverket med låg komplexitet. Konsekvensen landar på hög sekretesspåverkan, eftersom en angripare kan läsa filer den aldrig skulle haft tillgång till. Det är samma kombination av faktorer som gjort andra 2026-sårbarheter som SAP OVERPASS och Cisco ISE till rubriker under året, låg tröskel för angriparen och stor potentiell skada för offret.
För en organisation som kör en egen GitLab-instans, kallat “self-managed” i GitLabs terminologi, ligger själva servern och dess filsystem i kundens egen infrastruktur. Det är alltså kunden, inte GitLab, som bär den direkta risken om en instans inte patchas i tid. GitLab.com, alltså SaaS-versionen som GitLab själva driftar, var redan uppdaterad när sårbarheten offentliggjordes, och kunder på GitLab Dedicated behövde inte vidta några egna åtgärder.
Så fungerar attacken i praktiken
Bristen sitter i hur GitLabs commits-API hanterar filsökvägar. Normalt ska en förfrågan mot repository-commits bara kunna läsa filer som faktiskt tillhör det angivna projektet. På grund av den bristfälliga sökvägsbegränsningen kunde en manipulerad parameter i förfrågan “hoppa ut” ur det avsedda repositoryt och peka mot filer på servern i övrigt. watchTowr beskrev i sin rapport att tekniken gör det möjligt att läsa lokala filer och konfigurationer för att komma över inloggningsuppgifter, hemligheter och annan känslig information, allt via en enda HTTP-förfrågan.
Forskarna pekade specifikt ut vilka loggmönster försvarare bör leta efter. Anrop av typen POST mot sökvägen /api/v4/projects/{id}/repository/commits/ som innehåller en parameter kallad file.path är ett tydligt tecken på att någon försöker utnyttja bristen. Det gör det möjligt för säkerhetsteam att gå igenom historiska webbserverloggar och avgöra om en instans redan varit måltavla, även efter att patchen installerats.
grep "POST /api/v4/projects/" access.log \
| grep "repository/commits" \
| grep "file.path=" \
| awk '{print $1, $4, $7}'Det är inte ett exploateringsverktyg, bara ett enkelt sätt att grovsortera loggar efter det mönster som watchTowr och andra forskare kopplat till aktiv exploatering av CVE-2026-85706. Träffar bör alltid följas upp manuellt innan man drar slutsatser.
Den andra kritiska bristen: CVE-2026-87719
Samma patchsläpp åtgärdade en till kritisk sårbarhet, CVE-2026-87719, en osäker deserialisering (CWE-502) i GraphQL-prenumerationsserialiseraren i GitLab Enterprise Edition, med en CVSS-poäng på 9,9. Till skillnad från CVE-2026-85706 krävde den här bristen att angriparen redan var autentiserad och hade tillgång till funktionen Duo Chat. Med ett särskilt utformat GraphQL-prenumerationsargument kunde en sådan användare komma åt konfigurationer för Advanced Search-instansen, inklusive känsliga autentiseringsuppgifter. Vid tidpunkten för publiceringen hade GitLab inte sett några tecken på att CVE-2026-87719 utnyttjades aktivt, till skillnad från CVE-2026-85706.
Totalt täppte patchsläppet till 18 sårbarheter, varav två klassades som kritiska. Resterande 16 var av lägre allvarlighetsgrad, men det understryker en poäng som ofta glöms bort i rapporteringen kring enskilda CVE-nummer: ett enda patchfönster kan innehålla en hel bukett av fel, och det är sällan bara den mest uppmärksammade bristen som är värd att åtgärda.
Drabbade versioner och hur du patchar
GitLab publicerade tre fixade versioner samma dag: 19.3.2, 19.2.6 och 19.1.8. Alla självhanterade installationer påverkas, oavsett om de körs som Omnibus-paket, byggs från källkod eller distribueras via Helm chart i Kubernetes. Uppgraderingen innehåller databasmigreringar, vilket betyder att enkelnods-installationer får räkna med driftstopp under uppdateringen, medan multinodsmiljöer kan använda GitLabs process för nolltidsuppgradering. Endast version 19.3.2 innehåller migreringar som körs efter driftsättning, vilket är värt att känna till vid planeringen av uppgraderingsfönstret.
| Spår | Drabbade versioner | Fixad version | Driftstopp vid uppgradering |
|---|---|---|---|
| 19.1.x | 18.7 till före 19.1.8 | 19.1.8 | Ja, enkelnod |
| 19.2.x | 19.2 till före 19.2.6 | 19.2.6 | Ja, enkelnod |
| 19.3.x | 19.3 till före 19.3.2 | 19.3.2 | Ja, inkl. efterdriftsatta migreringar |
| GitLab.com (SaaS) | Ej berörd | Redan patchad | Nej |
| GitLab Dedicated | Ej berörd | Hanteras av GitLab | Nej |
CVE-2026-85706 mot CVE-2026-87719: en jämförelse
De två kritiska bristarna i samma patchsläpp skiljer sig åt på flera avgörande punkter, framför allt kring vem som kan utnyttja dem och vad angriparen kommer åt. Tabellen nedan ställer dem sida vid sida.
| Egenskap | CVE-2026-85706 | CVE-2026-87719 |
|---|---|---|
| CVSS 3.1-poäng | 10,0 | 9,9 |
| Svaghetstyp (CWE) | CWE-22, sökvägstraversering | CWE-502, osäker deserialisering |
| Komponent | Repository commits-API | GraphQL-prenumerationsserialiserare |
| Kräver autentisering | Nej | Ja, plus åtkomst till Duo Chat |
| Berört GitLab-läge | CE och EE | Endast EE |
| Aktiv exploatering vid publicering | Ja, bekräftad av watchTowr och CISA | Nej, inte känt vid publicering |
CISA:s KEV-katalog och den snäva tidsfristen
Den 11 september 2026, bara en dag efter GitLabs patch, lade den amerikanska cybersäkerhetsmyndigheten CISA till CVE-2026-85706 i sin katalog över kända, aktivt utnyttjade sårbarheter (Known Exploited Vulnerabilities, KEV). Inkludering i KEV-katalogen är CISA:s sätt att signalera att en brist inte längre är teoretisk utan faktiskt missbrukas i verkligheten. För federala amerikanska myndigheter satte CISA en åtgärdsfrist redan till den 14 september 2026, alltså tre dagar, med hänvisning till det bindande operativa direktivet BOD 26-04. Den korta fristen är ovanligt snäv även för KEV-listan, som normalt ger organisationer några veckor på sig.
KEV-katalogen är formellt bara bindande för amerikanska federala myndigheter, men i praktiken har den blivit ett globalt riktmärke för prioritering. Många säkerhetsteam, inklusive i svenska organisationer, använder listan som en snabb signal om vilka sårbarheter som ska patchas först, oavsett jurisdiktion. Det är också därför CVE-2026-85706 spred sig så snabbt i säkerhetsnyheter utanför USA redan samma vecka som den lades till.
Reaktionerna: Hongkong, Rapid7 och threat intel-branschen
Enligt Cybersecurity Dive gick Hongkongs myndighet för it-nödsituationer, HKCERT, ut med en egen varning samma måndag som CISA satte sin frist, och beskrev bristen som aktivt utnyttjad. Säkerhetsföretaget Rapid7 publicerade en egen analys och lade till ett kontrollmoment för CVE-2026-85706 i sitt innehållssläpp den 15 september 2026, tillgängligt för kunder av Exposure Command, InsightVM och Nexpose. Rapid7 rekommenderade organisationer att leta efter tecken på intrång även efter att patchen installerats, eftersom en angripare som redan kommit över hemligheter innan uppdateringen fortfarande kan använda dem.
Mönstret som växer fram är tydligt: från att GitLab publicerar en patch till att den blir ett aktivt mål för angripare tog det mindre än en vecka, och de första sonderingarna sågs redan inom det första dygnet. Det är i linje med en trend som säkerhetsbranschen sett hela 2026, där tiden mellan offentliggörande och massexploatering krympt kraftigt för sårbarheter i utvecklarverktyg och internetexponerad infrastruktur.
Läget i Sverige och Norden
CERT-SE:s varning
Det svenska nationella CERT-SE publicerade en egen bulletin, “GitLab rättar kritiska sårbarheter”, den 16 september 2026. Där upprepade myndigheten kärnfakta: CVSS-poängen 10,0, att sårbarheten drabbar både Community Edition och Enterprise Edition, samt vilka versioner som är berörda. Frågan togs även upp i CERT-SE:s ordinarie veckobrev för vecka 38, publicerat den 18 september, som en del av en bredare genomgång av september månads patchcykel bland stora leverantörer.
Exakta siffror för hur många internetexponerade GitLab-instanser som finns i Sverige, Norge, Danmark och Finland specifikt saknas i den publika rapporteringen. Det globala Censys-baserade måttet på drygt 86 000 exponerade värdar ger en fingervisning om skalan, men bör inte brytas ner till nationella uppskattningar utan tillgång till den underliggande skanningsdatan. Det är en påminnelse om att svenska organisationer själva behöver inventera sina GitLab-installationer snarare än att förlita sig på globala aggregat.
Kopplingen till NIS2 och cybersäkerhetslagen
En sårbar GitLab-installation utlöser inte automatiskt en rapporteringsplikt enligt den svenska implementeringen av NIS2-direktivet. Det avgörande är i stället om ett faktiskt intrång, eller en välgrundad misstanke om ett sådant, påverkar konfidentialitet, integritet eller tillgänglighet hos tjänster som ett anmälningspliktigt bolag levererar. För organisationer som klassas som väsentliga eller viktiga enheter enligt lagen betyder det att en bekräftad exploatering av CVE-2026-85706, där till exempel källkod eller driftshemligheter läckt, kan behöva utredas enligt bolagets ordinarie process för incidentrapportering. Ett osäkert eller opatchat system är i sig en riskindikator, men det är exploateringen och dess konsekvenser som avgör om anmälningsplikten faktiskt utlöses.
Ett mönster: GitLabs tredje kritiska sårbarhet under 2026
CVE-2026-85706 är inte GitLabs första kritiska säkerhetshändelse i år. Bolaget offentliggjorde en kritisk sårbarhet redan i april 2026, och ytterligare en kritisk brist i augusti 2026 som angripare började utnyttja inom bara några dagar efter offentliggörandet. Att samma produkt får tre separata kritiska sårbarhetscykler under ett och samma år säger något om trycket som utvecklarplattformar står under. GitLab hanterar inte bara källkod, det orkestrerar hela mjukvaruleveranskedjan: CI/CD-pipelines, byggartefakter, driftshemligheter och åtkomstnycklar till produktionsmiljöer. Det gör plattformen till ett särskilt attraktivt mål jämfört med en enskild applikationsserver, eftersom ett lyckat intrång kan ge angriparen vidare tillgång långt bortom själva GitLab-instansen.
Det här är samma logik som drivit flera av årets stora leveranskedjeincidenter, från attacken mot Ceva Logistics till de upprepade fynden i verktygskedjan kring containerskanning och hemlighetshantering. När en angripare kan kompromettera verktyget som bygger och distribuerar mjukvara, behöver den inte längre bryta sig in i varje enskild kundmiljö separat.
Marknadspåverkan för GitLab och konkurrenterna
GitLab är ett börsnoterat bolag (Nasdaq: GTLB) och konkurrerar med GitHub, som ägs av Microsoft, om företagskunder inom DevOps och CI/CD. Enligt uppgifter som TechRadar hänvisar till har GitLab över 50 miljoner registrerade användare, och ungefär hälften av Fortune 100-bolagen använder plattformen i någon form. En upprepad följd av kritiska sårbarheter riskerar inte i första hand att skrämma bort enskilda utvecklare, utan att bli ett argument i säkerhetsgranskningar och upphandlingar där GitLab jämförs mot GitHub eller molnbaserade alternativ. Ingen bekräftad kursrörelse i GTLB-aktien kopplad specifikt till denna sårbarhet gick att belägga i tillgänglig rapportering vid publiceringstillfället, men återkommande KEV-listningar tenderar historiskt att synas i säkerhetsteamens interna riskbedömningar av leverantörer snarare än i aktiekursen på kort sikt.
För konkurrenter som GitHub, Bitbucket och molnleverantörernas egna CI/CD-tjänster blir varje sådan händelse indirekt ett säljargument, även om ingen av dem är immun mot liknande brister i sina egna plattformar. Skillnaden ligger snarare i hur snabbt och transparent leverantören hanterar upptäckten, ett område där GitLabs egen hantering, från bug bounty-fynd till patch inom rimlig tid, ändå framstår som strukturerad jämfört med flera av årets andra kritiska sårbarhetshändelser.
Historisk kontext: utvecklarverktyg som attackyta
Utvecklarplattformar har gått från att vara ett internt IT-verktyg till att bli en del av den kritiska infrastrukturen för de flesta mjukvaruföretag. Den förändringen har gjort dem till ett mål på samma nivå som brandväggar och VPN-lösningar, kategorier som redan dominerat årets sårbarhetsrubriker med bolag som Cisco, Check Point, Citrix och SonicWall. Skillnaden är att en trasig VPN-brist ofta ger en angripare fotfäste i ett nätverk, medan en trasig utvecklarplattform kan ge direkt tillgång till själva produkten: källkoden, byggprocessen och de hemligheter som styr driftsättningen. Det är den kombinationen som gör sårbarheter som CVE-2026-85706 särskilt allvarliga att bedöma, även när den tekniska bristen i sig, en sökvägstraversering, är en av de äldsta och mest välkända sårbarhetstyperna som finns.
Så skyddar du organisationen just nu
Den första och viktigaste åtgärden är att identifiera varje självhanterad GitLab-installation i organisationen, inklusive testmiljöer och instanser som drivs av enskilda team utan central IT-koll. Många intrång i den här typen av sårbarheter drabbar just de “bortglömda” instanserna som ingen längre ansvarar aktivt för. Därefter gäller det att fastställa exakt version och jämföra mot de fixade versionerna 19.1.8, 19.2.6 och 19.3.2.
- Inventera alla självhanterade GitLab CE- och EE-instanser, inklusive skugg-IT och testmiljöer.
- Uppgradera till 19.1.8, 19.2.6 eller 19.3.2 beroende på vilket spår ni följer, och planera driftstopp för enkelnodsmiljöer.
- Genomsök webbserverloggar efter POST-anrop mot commits-API:et med parametern file.path, enligt mönstret watchTowr flaggat.
- Rotera alla hemligheter, API-nycklar och driftsuppgifter som legat lagrade på servern, oavsett om ni hittar tecken på intrång.
- Begränsa vilka GitLab-instanser som är direkt exponerade mot internet, och lägg dem bakom VPN eller IP-filtrering där det är möjligt.
- Dokumentera åtgärderna, i synnerhet om organisationen omfattas av NIS2 eller den svenska cybersäkerhetslagen och kan behöva visa på efterlevnad vid en granskning.
Prognoser: vad händer härnäst
Baserat på hur liknande KEV-listade sårbarheter i internetexponerad infrastruktur brukar utvecklas går det att peka ut några rimliga scenarier för de kommande veckorna och månaderna.
- Andelen opatchade GitLab-instanser kommer sannolikt att sjunka snabbt bland stora organisationer under de första två veckorna, men en lång svans av mindre bolag och glömda testmiljöer riskerar att förbli exponerade i månader.
- Fler säkerhetsforskare och penetrationstestare lär publicera detaljerade tekniska genomgångar av exploateringskedjan under hösten, vilket sänker tröskeln ytterligare för mindre sofistikerade angripare.
- GitLab kommer sannolikt att skärpa sin interna granskning av API-lager som hanterar filsökvägar, ett mönster som setts hos andra leverantörer efter liknande KEV-listningar.
- Svenska myndigheter och branschorganisationer väntas fortsätta använda CISA:s KEV-katalog som ett de facto prioriteringsverktyg, även utan någon egen bindande motsvarighet i Sverige.
- Ytterligare kritiska sårbarheter i CI/CD-plattformar generellt är att vänta under resten av 2026, i takt med att fler säkerhetsforskare riktar in sig specifikt på utvecklarverktygens attackyta snarare än traditionella nätverksprodukter.
Vanliga frågor om CVE-2026-85706
Vad är CVE-2026-85706?
Det är en kritisk sökvägstraverseringssårbarhet i GitLabs commits-API, med CVSS-poängen 10,0, som gjorde det möjligt för en oautentiserad angripare att läsa godtyckliga filer på en drabbad server.
Vilka GitLab-versioner är drabbade?
Självhanterade installationer av GitLab CE och EE från version 18.7 och framåt, fram till de fixade versionerna 19.1.8, 19.2.6 och 19.3.2. GitLab.com och GitLab Dedicated påverkas inte.
Är sårbarheten aktivt utnyttjad?
Ja. CISA lade till CVE-2026-85706 i sin KEV-katalog den 11 september 2026 med hänvisning till bekräftad exploatering, och hotforskningsfirman watchTowr rapporterade sonderande trafik mot sårbara servrar redan innan dess.
Vad är skillnaden mot CVE-2026-87719?
CVE-2026-87719 är en separat kritisk brist i samma patchsläpp, en osäker deserialisering i GraphQL-lagret med CVSS 9,9. Den kräver dock att angriparen redan är autentiserad och har tillgång till funktionen Duo Chat, till skillnad från CVE-2026-85706 som inte kräver inloggning alls.
Måste svenska organisationer rapportera detta enligt NIS2?
Inte automatiskt. Rapporteringsplikten enligt den svenska cybersäkerhetslagen, som implementerar NIS2, beror på om en faktisk incident inträffat och påverkat tjänster hos ett anmälningspliktigt bolag, inte enbart på att en sårbar version funnits installerad.
Hur vet jag om min GitLab-instans redan utnyttjats?
Sök igenom webbserverloggarna efter POST-förfrågningar mot repository-commits-API:et som innehåller parametern file.path. Det mönstret har hotforskare kopplat till försök att utnyttja CVE-2026-85706. Träffar bör alltid utredas manuellt.
Räcker det att bara patcha, eller behöver jag göra mer?
Rapid7 rekommenderar att organisationer letar efter tecken på tidigare intrång även efter patchning, eftersom hemligheter som redan lästs av en angripare innan uppdateringen fortfarande kan missbrukas. Rotera känsliga nycklar och autentiseringsuppgifter som legat på den drabbade servern.
Hur många GitLab-servrar är exponerade globalt?
Enligt skanningsdata från Censys fanns över 86 000 internetexponerade GitLab-värdar vid tidpunkten för rapporteringen. Exakta siffror uppdelat per land, inklusive Sverige och övriga Norden, finns inte publikt tillgängliga.
