CVE-2026-5917: Kommandoindsprøjtning i libgit2 via SSH
Fejl i biblioteket libgit2 gør det muligt at indsprøjte systemkommandoer via en ondsindet undermodul-URL ved rekursiv kloning over SSH. Opdatér libgit2.
Hvad er det?
CVE-2026-5917 er en fejl i libgit2, et softwarebibliotek som mange udviklerværktøjer bruger til at arbejde med git-repositorier under motorhjelmen, blandt andet til at klone og opdatere kode. Fejlen er en kommandoindsprøjtning (CWE-78), hvor et program uden at ville det kommer til at udføre systemkommandoer fra en angriber. Når libgit2 er bygget med SSH-modulet libssh2 og henter en undermodul (en reference til et andet git-repository) via SSH, sætter funktionen gen_proto() stien til repositoriet direkte ind i en kommandostreng uden at fjerne særtegn som semikolon eller anførselstegn. En angriber kan derfor lægge en forberedt sti i filen .gitmodules, som udløser ekstra kommandoer på SSH-serveren, når en anden bruger kloner repositoriet rekursivt.
Hvem rammer det?
Det rammer alle programmer og systemer, der bruger libgit2 version v0.27.0 til og med v1.9.0, bygget med SSH-backenden libssh2 (USE_SSH=libssh2). Det gælder blandt andet udviklerværktøjer, byggesystemer og automatiserede CI/CD-pipelines, der kloner git-repositorier rekursivt, herunder undermoduler fra tredjepart. Danske virksomheder med eget udviklingsteam, egne CI/CD-servere eller internt udviklede værktøjer, der bruger libgit2, bør se nærmere på deres afhængigheder.
Hvad kan ske?
Hvis en medarbejder eller en automatiseret proces kloner et repository rekursivt, og repositoriet indeholder en ondsindet undermodul-URL, kan angriberens kommandoer blive udført på den SSH-server, som klonings-processen kontakter, under den ramte brugers eget SSH-login. I praksis kan det betyde, at en angriber får adgang til byggeservere, interne kodebaser, adgangskoder gemt i miljøet eller mulighed for at plante bagdøre i softwareleverancer, hvilket kan sprede sig videre til kunder eller andre systemer.
Hvor alvorligt er det?
CVSS-scoren er 9,6 ud af 10, hvilket er kritisk. Angrebet kræver ikke login og kan udføres over netværket med lav kompleksitet, men det kræver brugerhandling: nogen skal aktivt klone repositoriet rekursivt, før fejlen udløses. Konsekvensen er høj på alle tre parametre, fortrolighed, integritet og tilgængelighed, fordi angriberen kan køre vilkårlige kommandoer. Der er ikke oplyst kendt aktiv udnyttelse af sårbarheden på offentliggørelsestidspunktet.
Hvad gør jeg nu?
Følgende trin lukker hullet og begrænser risikoen, mens I opdaterer.
- Opdatér libgit2 i alle systemer og applikationer, der bruger biblioteket, til en version nyere end v1.9.0, hvor fejlen er rettet.
- Lav en oversigt over hvilke interne værktøjer, byggeservere og CI/CD-pipelines der bruger libgit2 med libssh2-backenden, så I ved præcis hvor opdateringen skal ud.
- Undgå rekursiv kloning (–recursive) af repositorier fra ukendte eller ikke-verificerede kilder, indtil opdateringen er gennemført.
- Overvej midlertidigt at skifte til HTTPS-backenden i stedet for libssh2, hvis en opdatering ikke kan gennemføres med det samme.
- Gennemgå logs på SSH-servere, der modtager kloninger, for uventede kommandoer i den relevante periode.
- Hent hjælp udefra, hvis I ikke kan identificere alle interne systemer, der bruger libgit2, eller hvis I finder tegn på udnyttelse.
Opdatér inden for en uge
Vi anbefaler, at I opdaterer libgit2 i alle interne og eksterne værktøjer inden for en uge, med højeste prioritet på byggeservere og CI/CD-systemer, der kloner eksterne repositorier automatisk. Det er acceptabelt at vente få dage, hvis I i mellemtiden undgår rekursiv kloning af ukendte repositorier eller bruger HTTPS-backenden. Vent ikke længere end nødvendigt, da fejlen kan ramme byggeprocesser, som mange andre systemer er afhængige af.
Tidslinje
Konkrete eksempler
Ondsindet undermodul i en byggepipeline
En dansk softwarevirksomhed henter et open source-bibliotek som en git-undermodul i deres byggepipeline. Biblioteket er blevet manipuleret, så .gitmodules-filen indeholder en forberedt SSH-sti. Når CI-serveren kloner repositoriet rekursivt med libgit2 og libssh2, udføres angriberens kommandoer på den interne SSH-server under byggetjenestens eget login, hvilket giver angriberen adgang til byggemiljøet og eventuelt til kode og hemmeligheder, der ligger der.
Ofte stillede spørgsmål
Er vi ramt af CVE-2026-5917?
I er ramt, hvis I bruger libgit2 mellem version v0.27.0 og v1.9.0, bygget med SSH-backenden libssh2, i egne værktøjer, byggesystemer eller CI/CD-pipelines. Brug tredjepartsapplikationer, som selv bygger på libgit2, uden at I selv kompilerer det, bør I kontakte leverandøren for status.
Hvordan tjekker vi, om vores systemer bruger libgit2 med libssh2?
Gennemgå afhængighedslister i jeres byggeværktøjer og CI/CD-konfigurationer for libgit2, og undersøg om det er kompileret med USE_SSH=libssh2. It-afdelingen eller udviklerteamet kan finde dette i byggelogs eller pakkefiler.
Kan vi vente til weekenden med at opdatere?
Ja, hvis I i mellemtiden undgår rekursiv kloning af repositorier fra eksterne eller ukendte kilder, og ingen automatiserede processer kloner sådanne repositorier ubevogtet. Er det tilfældet, bør opdateringen ske hurtigere.
Skal vi anmelde hændelsen, hvis vi bliver ramt?
Hvis I finder tegn på, at sårbarheden er udnyttet, og persondata eller kritiske systemer er berørt, skal I vurdere anmeldelsespligt efter databeskyttelsesforordningen og eventuelt kontakte Center for Cybersikkerhed. Kontakt gerne en sikkerhedsrådgiver for at vurdere omfanget først.
Er det nok at undgå --recursive ved kloning?
Det reducerer risikoen betydeligt, men er ikke en permanent løsning, da automatiserede processer og andre værktøjer kan udføre rekursiv kloning uden manuel indgriben. Opdatering af libgit2 er den eneste varige løsning.
Hvad hvis vi bruger en tredjepartsapplikation, der indeholder libgit2?
Kontakt leverandøren og spørg, om deres produkt bruger den sårbare version af libgit2 med libssh2-backenden, og hvornår en opdateret version forventes.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
libgit2 versions v0.27.0 through v1.9.0 built with the libssh2 SSH backend (USE_SSH=libssh2) contain a shell command injection vulnerability that allows remote attackers to execute arbitrary commands on an SSH server by supplying a repository path containing unescaped shell metacharacters such as single quotes, semicolons, or pipes. The gen_proto() function in ssh_libssh2.c inserts the repository path directly into a shell command string without escaping special characters before passing it to libssh2_channel_exec(), enabling an attacker to craft a malicious submodule URL in a .gitmodules file that, when processed during a recursive clone, causes the remote server’s shell to interpret injected commands under the victim’s SSH user account.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.