GitLab 10,0: kontrollera den egna servern
En kritisk sårbarhet i GitLab CE och EE kan möjliggöra kodkörning. Kontrollera version, uppdateringsväg och tecken på tidigare intrång.
Prioritera sårbara installationer, särskilt internetexponerade tjänster.
Det här är bekräftat
CVE-2026-97229 har CVSS 3.1-poängen 10,0. Felet gäller reguljära uttryck i CI/CD och kan under vissa förutsättningar möjliggöra kodkörning utan inloggning. CERT-SE uppger att sårbarheten lagts till i CISA KEV. [1, 2]
Versioner att kontrollera
GitLab anger 19.2 före 19.2.8, 19.3 före 19.3.5 och 19.4 före 19.4.2. Dessa är rättningsnivåer i meddelandet. Välj en aktuell stödd målversion och följ GitLabs uppgraderingsväg. Uppgifterna gäller GitLab CE/EE. [1]
Vår rekommenderade åtgärd
Hantera eventuell misstanke om intrång separat från uppdateringen.
- Bekräfta installerad version och hur tjänsten exponeras.
- Kontrollera backup och återställning för data och konfiguration.
- Följ den stödda uppgraderingsvägen och testa projektåtkomst och pipelines.
- Granska loggar och konton. Vid misstänkt intrång: bedöm exponerade hemligheter och rätt ordning för återställning och byte.
Efter uppdateringen: tre tester som gör skillnad
Vår rekommendation är att dokumentera testerna i ändringsärendet. Om något misslyckas: avbryt vidare utrullning och använd den planerade felsöknings- eller återställningsvägen.
- Kontrollera GitLabs rapporterade version och att avsedd rättningsnivå eller en verifierad senare rättad version körs.
- Testa en vanlig användarinloggning och åtkomst till ett avsett testprojekt.
- Testa ett ofarligt Git-arbetsflöde och en kontrollerad testpipeline, utan att starta en skarp produktionsdistribution.
Behöver du en gemensam arbetsgång?
Guiden ”Ett säkerhetshål har upptäckts – så tar du det till en färdig åtgärd” beskriver hur du kontrollerar om du berörs, förbereder återställning och verifierar resultatet.
Källor
Siffror i texten hänvisar till källorna ovan. Arbetsordningar och checklistor är bloggens praktiska rekommendationer.
