CVE-2026-75913: Kritisk fejl i CodeWhale git_show
CodeWhale version 0.8.41 til 0.8.63 kan snydes til at overskrive filer som SSH-nøgler. Opdatér til 0.8.64.
Hvad er det?
CVE-2026-75913 er en sårbarhed i AI-udviklingsværktøjet CodeWhale (også kaldet codewhale-tui). Værktøjets git_show-funktion, der bruges til at vise indholdet af filer i et git-repository, sender en parameter kaldet rev direkte videre til git uden at kontrollere indholdet. En værdi der begynder med –output= bliver derfor tolket som et kommandoflag i stedet for almindelig tekst. Dette kaldes argument injection (argumentinjektion): et sted hvor forventet dataindhold i stedet misbruges som et styringskommando. Fordi git_show er sat til automatisk at blive godkendt og markeret som en sikker, læsende funktion, kan et AI-agentsystem udføre kommandoen uden at spørge brugeren først, hvilket giver angriberen mulighed for at skrive filer på brugerens vegne.
Hvem rammer det?
Sårbarheden rammer organisationer, der bruger CodeWhale eller codewhale-tui i version 0.8.41 til og med 0.8.63. Det gælder typisk softwarevirksomheder, it-afdelinger og konsulenthuse i Danmark, hvor udviklere bruger AI-agenter til at læse, gennemgå eller arbejde med kode fra git-repositories, herunder eksterne eller open source-repositories.
Hvad kan ske?
En angriber, der kombinerer et ondsindet repository med prompt injection (skjulte instruktioner gemt i tekst, som narrer AI-modellen), kan få CodeWhale til at skrive vilkårlige filer med den kørende brugers rettigheder. I praksis kan filen ~/.ssh/authorized_keys overskrives med angriberens egen nøgle, hvilket giver fjernadgang via SSH. Filer som ~/.bashrc eller ~/.gitconfig kan også ændres, så skadelig kode køres, næste gang udvikleren logger ind eller bruger git.
Hvor alvorligt er det?
CVSS-scoren er 9,3 ud af 10, kritisk. Angrebet kræver ingen rettigheder i systemet og kan gennemføres over netværk, fordi det sker via et git-repository, der kan hostes hvor som helst. Det kræver dog en brugerhandling: udvikleren skal bruge CodeWhale på det ondsindede repository. Der er ingen påvirkning af fortrolighed, men høj påvirkning af integritet og tilgængelighed, fordi filskrivningen kan ændre eller ødelægge systemfiler og give angriberen adgang. Der er ikke rapporteret aktiv udnyttelse i skarpe angreb pr. offentliggørelsesdatoen, men mekanismen er beskrevet konkret nok til at kunne udnyttes.
Hvad gør jeg nu?
Følgende trin lukker hullet og reducerer risikoen, mens I opdaterer.
- Opdatér CodeWhale eller codewhale-tui til version 0.8.64 eller nyere på alle maskiner, hvor værktøjet er installeret.
- Gennemgå hvilke værktøjer i CodeWhale, der er sat til automatisk godkendelse, og fjern denne for git_show og lignende funktioner, indtil opdateringen er udrullet.
- Tjek ~/.ssh/authorized_keys, ~/.bashrc og ~/.gitconfig på udviklermaskiner for uventede ændringer.
- Informer udviklere om ikke at bruge CodeWhale på ikke-betroede eller eksterne repositories, før opdateringen er på plads.
- Find I tegn på uautoriseret adgang, eller kan I ikke selv verificere om systemerne er kompromitterede, kontakt en sikkerhedsrådgiver.
Opdatér inden for 24 timer
Vi anbefaler at opdatere CodeWhale til version 0.8.64 eller nyere så hurtigt som muligt, især hvis værktøjet bruges mod eksterne eller ikke-betroede repositories. Det er kun forsvarligt at vente kort tid, hvis CodeWhale udelukkende bruges internt på fuldt betroet kode, hvor ingen ekstern tekst kan påvirke AI-agenten. Vi anbefaler samtidig at gennemgå, hvilke værktøjer der er sat til automatisk godkendelse i jeres AI-agentopsætning generelt.
Tidslinje
Konkrete eksempler
Ondsindet afhængighed i udviklingsmiljø
En dansk softwarevirksomhed bruger CodeWhale til at gennemgå kode, når udviklere trækker afhængigheder ind fra offentlige repositories. En pakke indeholder en skjult instruktion i en README-fil, der narrer CodeWhale til at bruge git_show med et ondsindet rev-argument. Fordi værktøjet er sat til automatisk at godkende læsehandlinger, overskrives udviklerens ~/.ssh/authorized_keys med angriberens nøgle, som derefter får fjernadgang til maskinen.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
Kun hvis I bruger CodeWhale eller codewhale-tui i version 0.8.41 til og med 0.8.63. Tjek versionen med kommandoen codewhale –version eller i jeres pakkeopsætning.
Hvordan tjekker vi, om vi er blevet udnyttet?
Se efter uventede ændringer i ~/.ssh/authorized_keys, ~/.bashrc og ~/.gitconfig på maskiner, hvor CodeWhale har kørt. Sammenlign filerne med backup eller versionsstyring, og kig efter ukendte SSH-nøgler.
Kan vi vente til weekenden med at opdatere?
Det afhænger af, om CodeWhale bruges mod eksterne repositories. Bruges det kun internt på betroet kode, kan det vente kort tid, men med en CVSS-score på 9,3 anbefaler vi ikke at udskyde opdateringen længere end nødvendigt.
Skal vi anmelde dette til Datatilsynet?
Sårbarheden i sig selv giver ikke direkte adgang til persondata, da fortrolighed ikke er påvirket. Fører den til yderligere kompromittering, for eksempel adgang via en overskrevet SSH-nøgle, skal I vurdere hændelsen efter GDPR, som ved enhver anden systemadgang.
Hvad er prompt injection, og hvorfor gør det sårbarheden farlig?
Prompt injection er skjulte instruktioner i tekst, for eksempel i en fil i et repository, som narrer en AI-model til at udføre handlinger, brugeren ikke har bedt om. Fordi git_show her er sat til automatisk godkendelse, kan AI-agenten udføre den skadelige handling uden at spørge brugeren først.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
CodeWhale (codewhale / codewhale-tui) versions >= 0.8.41 and < 0.8.64 contain an argument injection vulnerability in the git_show tool. The model-supplied rev parameter is passed unvalidated into the git show argv without an –end-of-options sentinel, so a value beginning with –output= is interpreted as a git flag. Because the tool is registered as auto-approved and advertised as read-only, an attacker (via a malicious repository combined with prompt injection) can cause an unprompted arbitrary file write at the privilege of the invoking user, targeting sensitive files such as ~/.ssh/authorized_keys, ~/.bashrc, or ~/.gitconfig. Fixed in 0.8.64 by adding rev validation.
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.