En simpel indstilling i Git har i september 2026 vist sig at være en åben dør ind til nogle af verdens mest brugte AI-kodeagenter. Sikkerhedsfirmaet Manifold Security offentliggjorde den 1. september en sårbarhedsklasse ved navn “GitSpawn”, der rammer syv kommandolinje-baserede AI-kodeagenter med otte separate fejl. Samme uge kom en kritisk fejl i DeepSeek Harness (CVE-2026-82533, CVSS 9,4), en RCE-svaghed i Claude Codes bash-validator og en sårbarhed i Google Gemini CLI, som ifølge CIRCLs sårbarhedsdatabase og relaterede kilder blev vurderet til den maksimale CVSS-score på 10,0. Tilsammen tegner ugerne et billede af en branche, der har bygget kraftfulde AI-agenter oven på infrastruktur, som aldrig var designet til at håndtere fjendtlige repositories.
For danske og nordiske udviklingsteams, der i stigende grad lader AI-agenter håndtere git-operationer, kodegennemgang og deployment, er sagen ikke akademisk. Ifølge Manifold Securitys egen rapport kræver GitSpawn-angrebet intet mere end at agenten åbner en mappe med et fjendtligt repository. Der skal ikke klikkes på noget, og i flere af de dokumenterede tilfælde vises der end ikke en godkendelsesprompt, før koden kører med brugerens fulde rettigheder.
Hvad er GitSpawn, og hvorfor virker angrebet på tværs af syv agenter
Kernen i GitSpawn er en gammel og i sig selv legitim Git-funktion kaldet core.fsmonitor. Indstillingen fortæller Git, hvilket eksternt hjælpeprogram der skal bruges til at opdage ændrede filer hurtigere, en ren ydelsesoptimering, der har eksisteret i årevis. Problemet opstår, fordi indstillingen gemmes i .git/config inde i selve repositoriet, hvilket betyder, at den som udgangspunkt styres af den, der har oprettet repositoriet, ikke af udvikleren, der klonede det.
Moderne AI-kodeagenter kører rutinemæssigt kommandoer som git status --porcelain=2 --branch eller git diff --name-only HEAD i baggrunden for at opbygge kontekst til, hvad de skal foreslå eller rette. Ifølge Manifold Securitys tekniske gennemgang respekterer Git core.fsmonitor, hver gang disse baggrundskald køres, og hvis et angriberkontrolleret repository har sat indstillingen til en ondsindet kommando, eksekveres den kommando med brugerens fulde værtsrettigheder, uden for agentens sandkasse og før nogen tillidsprompt overhovedet vises.
Cloud Security Alliance beskriver konsekvensen præcist i sin daglige briefing fra 4. september: et repository kan konfigureres til at eksekvere angriberleveret kode på en udviklers maskine, i det øjeblik en AI-kodeagent åbner det, uden prompt, uden godkendelse af værktøjskald, og i flere dokumenterede tilfælde før agenten overhovedet har vist en tillidsprompt eller brugeren har autentificeret en session.
Manifold Security fandt otte separate sårbarheder fordelt på syv forskellige agenter: Claude Code fra Anthropic, OpenAI’s Codex CLI, Cursor, Blocks Goose, Alibabas Qwen Code, xAI’s Grok Build og Hermes Agent. Det brede omfang skyldes ikke, at de syv virksomheder kopierede hinandens fejl bevidst, men at de uafhængigt af hinanden implementerede den samme antagelse: at baggrundskald til Git er harmløse, fordi de “bare” læser status. Den antagelse holder ikke, når repositoriet selv er fjendtligt.
Patch-status: hvem har rettet, og hvem er stadig sårbar
Patch-billedet er ujævnt, og det er noget af det mest håndgribelige ved sagen for it-afdelinger, der skal beslutte, om de kan stole på deres værktøjer i dag. Ifølge de tilgængelige kilder er Goose rettet i version 1.44.0, Codex CLI i version 0.131.0 med tilhørende desktop-builds, og Cursor har også sendt en rettelse. Claude Code fik lukket sin core.fsmonitor-sti i version 2.1.196, men Cloud Security Alliances noter peger på, at en separat, urelateret konfigurationssti i Claude Code fortsat var sårbar efter den opdatering.
Qwen Code, Grok Build og Hermes Agent stod ifølge CSA’s briefinger fra begyndelsen af september fortsat uden rettelse. Det betyder, at organisationer, der bruger disse tre agenter til at arbejde med eksterne eller offentlige repositories, i praksis kører med en kendt, offentliggjort svaghed, indtil leverandørerne lukker den.
| AI-kodeagent | Leverandør | Status pr. medio september 2026 | Rettet i version |
|---|---|---|---|
| Claude Code | Anthropic | Delvist rettet (én sti lukket, én stadig åben) | 2.1.196 (fsmonitor-stien) |
| Codex CLI | OpenAI | Rettet | 0.131.0 |
| Cursor | Cursor / Anysphere | Rettet | Ikke offentliggjort i detaljer |
| Goose | Block | Rettet | 1.44.0 |
| Qwen Code | Alibaba | Uafklaret/sårbar | Ingen rettelse fundet |
| Grok Build | xAI | Uafklaret/sårbar | Ingen rettelse fundet |
| Hermes Agent | Uafhængig leverandør | Uafklaret/sårbar | Ingen rettelse fundet |
Manifold Security anbefaler i mellemtiden en konkret, midlertidig afhjælpning for leverandører, der endnu ikke har rettet fejlen: agenter bør eksplicit deaktivere core.fsmonitor, når de indsamler git-kontekst i baggrunden.
git -c core.fsmonitor=false status
git -c core.fsmonitor=false diff --name-only HEADKommandoen tvinger Git til at ignorere den repository-styrede indstilling for netop det ene kald, hvilket lukker angrebsvejen uden at kræve en fuld ny udgivelse. Det er en midlertidig plaster, ikke en løsning, men den er billig at implementere og bør ifølge sikkerhedsforskerne rulles ud med det samme i alle agenter, der endnu mangler en permanent rettelse.
DeepSeek Harness: CVE-2026-82533 og en Host-header, ingen skulle stole på
Mens GitSpawn handlede om Git-konfiguration, er CVE-2026-82533 i DeepSeek Harness en klassisk fejl i, hvordan software beslutter, hvem den kan stole på. DeepSeek Harness er en open source-baseret AI-agent-runtime, der ifølge tidligere research samlede omkring 215.000 GitHub-stjerner i løbet af få uger efter lanceringen i august 2026, hvilket gør den til et af de hurtigst voksende agent-frameworks i år.
Ifølge beskrivelsen i Miggos sårbarhedsdatabase kører DeepSeek Harness som standard en lokal HTTP-styringsflade (en “control-plane API”) på loopback-adressen, altså kun tilgængelig fra selve maskinen. Problemet er, at API’en ikke validerer, hvor en forbindelse faktisk kommer fra. I stedet stoler den på en klientleveret Host-header, for eksempel en header, der påstår at komme fra 127.0.0.1, uden at bekræfte den reelle TCP-forbindelses oprindelse. Det er en fejltype, der er katalogiseret som CWE-807, altså tillid til ubetroede input i en sikkerhedsbeslutning.
Konsekvensen er alvorlig i to scenarier. I standardopsætningen kan en proces, som agenten selv har startet i en afgrænset sandkasse (for eksempel et værktøj, brugeren har bedt agenten køre), spoofe Host-headeren og derved eskalere fra afgrænset til fuldt ubegrænset udførelse, uden at nogen godkendelsesprompt bliver vist. Hvis porten desuden er eksternt tilgængelig, for eksempel via en SSH-tunnel eller en videresendt udviklingsport, kan en helt ekstern angriber uden loginoplysninger oprette sessioner, køre vilkårlige kommandoer og hente gemte samtaletransskripter og kontekstdata ud af agenten.
Fejlen er rettet i version 0.1.2-alpha.1, som ifølge CIRCLs vulnerability lookup er den første version, der ikke længere er sårbar. CVSS-scoren på 9,4 placerer sagen i den kritiske kategori, og NVD’s opslag for sårbarheden blev senest opdateret 16. september 2026, hvilket viser, at klassificeringsarbejdet stadig er i gang, mens flere detaljer bliver bekræftet.
Claude Codes bash-validator: når en flag snyder en filter
En tredje sag, rapporteret af sikkerhedsfirmaet Adversa, rammer Claude Codes bash-validator, altså den mekanisme, der skal forhindre agenten i at køre farlige shell-kommandoer uden godkendelse. Ifølge Adversas gennemgang strippede validatoren indhold i enkelte anførselstegn, før den inspicerede kommandoen for farlige mønstre. Det betød, at et flag som git push --receive-pack=... kunne fremstå tomt for validatoren, selvom det reelt indeholdt en kommando, der efterfølgende blev eksekveret.
Resultatet var fjernudførelse af kode samt tyveri af API-nøgle og GitHub-token, og ifølge Adversa krævede det tre runder af patch og efterfølgende omgåelse, før hullet var lukket for alvor. Det mønster, tre forsøg på at lappe den samme klasse af fejl, er i sig selv interessant: det viser, at simple streng-baserede filtre er svære at gøre vandtætte, når input kommer fra en potentielt fjendtlig kilde som et repository eller en prompt, en agent fortolker.
Samme uge rapporterede sikkerhedsforskere en beslægtet svaghed i Google Gemini CLI. Her var problemet, at en markering, der skulle begrænse, hvilke værktøjer agenten måtte køre, reelt var dekorativ og ikke blev håndhævet af selve kørselstiden. Fejlen gjorde det muligt at læse indhold fra /proc/$PPID/environ i et delt PID-namespace, hvilket kunne afsløre miljøvariabler, herunder hemmeligheder, fra forældreprocessen. Ifølge sikkerhedsanalytikeren Adversas offentliggjorte materiale blev sagen af Google vurderet til den maksimale CVSS-score på 10,0.
| Sårbarhed | Produkt | CVSS-score | Angrebstype |
|---|---|---|---|
| GitSpawn (8 fejl) | 7 CLI-agenter | Ikke enkeltvis publiceret, kritisk klasse | Kommandoeksekvering via .git/config |
| CVE-2026-82533 | DeepSeek Harness | 9,4 | Autentificeringsomgåelse via Host-header |
| Bash-validator RCE | Claude Code | Ikke offentliggjort CVE-nummer | Flag-injektion i git push |
| Værktøjsbegrænsning bypass | Google Gemini CLI | 10,0 | Læsning af /proc/$PPID/environ |
Markedet for AI-kodeagenter: hvor mange bruger dem reelt
Sårbarhederne rammer et marked, der er vokset markant på kort tid. Ifølge Stack Overflows udviklerundersøgelse fra 2025, som stadig er den nyeste af sin art, brugte eller planlagde 84 procent af udviklerne at bruge AI-kodeværktøjer i 2026, op fra 76 procent i 2024. Men der er stor forskel på at bruge en autofuldførelsesassistent og at give en autonom agent adgang til at køre kommandoer på egen hånd.
Ser man specifikt på autonome agenter, viser undersøgelsen, at 14,1 procent af de adspurgte bruger AI-agenter dagligt på arbejdet, 9 procent bruger dem ugentligt, og 7,8 procent bruger dem månedligt eller sjældnere. Samlet betyder det, at omkring en tredjedel af udviklerne overhovedet rører ved autonome agenter, mens resten enten slet ikke bruger dem eller ikke har planer om det. Samtidig peger analyser baseret på samme datasæt på, at tilliden til AI-genereret output fortsat er lav, med enkelte kilder, der estimerer så lidt som få procent af udviklerne har høj tillid til, at output er korrekt uden efterprøvning.
Det er præcis den kombination, der gør GitSpawn og de tilstødende fejl interessante ud over den tekniske detalje: en tredjedel af udviklerne lader allerede agenter køre kommandoer selvstændigt, mens tilliden til, at agenten selv opdager, når noget er galt, er lav. Når en angriber kan udnytte den mekanisme, agenten bruger til at orientere sig i koden, uden at brugeren nogensinde bliver spurgt, forsvinder den sidste kontrolmekanisme, mange organisationer regnede med at have.
Historisk kontekst: fra prompt injection til infrastruktur-angreb
GitSpawn er ikke det første sikkerhedsproblem, der rammer AI-kodeagenter i 2026, men det markerer et skift i, hvor angrebene sidder. Tidligere på året handlede de fleste sikkerhedsfund om prompt injection, altså at få en agent til at fortolke ondsindet tekst i en fil eller kommentar som en instruks. GhostSplice-angrebet, som blev dokumenteret tidligere i 2026, viste, at MCP-baserede angreb kunne lække nøgler i op mod 82 procent af testede scenarier ved netop at manipulere agentens prompt-kontekst.
GitSpawn og DeepSeek Harness-fejlen er af en anden karakter. De udnytter ikke sprogmodellens fortolkning af tekst, men den kedelige, klassiske infrastruktur omkring agenten: Git-konfiguration, HTTP-headere og procesmiljøer. Det er samme type sårbarheder, sikkerhedsbranchen har kæmpet med i webapplikationer i årtier, blot genopstået i et nyt lag af værktøjer, der bliver rullet ud hurtigere, end de bliver sikkerhedstestet. Cloud Security Alliance har da også i samme periode dokumenteret separate sager som en MCP Gateway-autentificeringsomgåelse, der kunne kædes sammen med en kommandoinjektion, samt en kritisk fjernudførelsesfejl i IBM Langflow med en CVSS-score på 9,8, hvilket underbygger, at problemet ikke er isoleret til én leverandør eller ét produkt.
Mønstret minder om den tidlige containersikkerhed for et årti siden, hvor Docker og Kubernetes voksede hurtigere end de sikkerhedsmodeller, der skulle beskytte dem, og hvor det tog flere år, før standarder som sandboxing, non-root-brugere og netværkssegmentering blev normen. AI-agenter ser ud til at gennemgå samme modningsproces, blot i et langt hurtigere tempo, fordi konkurrencen om markedsandele presser leverandørerne til at shippe funktioner, før sikkerhedsarkitekturen er færdigtænkt.
Konkurrencesammenligning: hvordan har de enkelte leverandører reageret
De syv berørte GitSpawn-leverandører har reageret med markant forskellig hastighed. Block, der står bag Goose, og OpenAI, der står bag Codex CLI, fik begge rettelser ud relativt hurtigt, i henholdsvis version 1.44.0 og 0.131.0. Anthropic lukkede den primære sti i Claude Code, men efterlod ifølge Cloud Security Alliance en sekundær konfigurationssti åben, hvilket rejser spørgsmålet om, hvor grundigt den interne sårbarhedsanalyse blev udført, før patchen blev udsendt.
Alibabas Qwen Code, xAI’s Grok Build og Hermes Agent har, ifølge de tilgængelige kilder fra begyndelsen af september, endnu ikke offentliggjort rettelser. Det er værd at bemærke, at disse tre produkter typisk har mindre etablerede sikkerhedsteams og færre ressourcer afsat til koordineret sårbarhedshåndtering end de store, børsnoterede eller velfinansierede konkurrenter, hvilket kan forklare, men ikke undskylde, forsinkelsen.
DeepSeek har med sin hurtige udgivelse af version 0.1.2-alpha.1 vist en forholdsvis kort reaktionstid for et projekt, der stadig er i alpha-fase, mens Google endnu ikke har offentliggjort et fuldt teknisk skriv om Gemini CLI-fejlen ud over den bekræftede CVSS-score på 10,0. Cursor, som konkurrerer direkte med GitHub Copilot om udviklere, der ønsker dybere agent-integration i deres editor, fik lukket sin del af GitSpawn uden større forsinkelse, hvilket kan blive et konkurrenceparameter, efterhånden som virksomheder begynder at stille sikkerhedskrav til deres udviklerværktøjer på linje med funktionalitet og pris.
Hvad betyder det for danske og nordiske virksomheder
For danske it-afdelinger, der arbejder under NIS2-direktivet, er sagen ikke kun en teknisk detalje for sikkerhedsteamet. NIS2 stiller krav om, at virksomheder i en lang række sektorer aktivt styrer risici i deres forsyningskæde af software, hvilket i praksis omfatter de udviklerværktøjer, medarbejderne bruger dagligt. En sårbarhed, der giver fjernudførelse af kode blot ved at åbne en mappe, rammer direkte ned i den type risiko, direktivet er designet til at adressere.
Praktisk betyder det, at it-sikkerhedsansvarlige bør kortlægge, hvilke AI-kodeagenter der reelt er i brug i organisationen, inklusive dem udviklere selv har installeret uden om en central it-politik, en situation der er langt fra ualmindelig. Dernæst bør de sammenholde den liste med patch-status i tabellen ovenfor og som minimum sikre, at ingen team arbejder med eksterne eller ukendte repositories i Qwen Code, Grok Build eller Hermes Agent, før disse tre får en officiel rettelse.
Det er også værd at bemærke, at flere danske virksomheder allerede har adopteret Claude Code og GitHub Copilot i stor skala. Det betyder, at den delvise patch-status i Claude Code, hvor kun én af flere kendte stier er lukket, bør udløse en konkret handling: opdatere til nyeste version med det samme, og indtil videre undgå at lade agenten arbejde uovervåget med repositories fra ukendte eksterne bidragydere.
Sådan beskytter udviklingsteams sig i praksis
Den mest håndgribelige beskyttelse lige nu er at opdatere til de patchede versioner: Claude Code 2.1.196 eller nyere, Codex CLI 0.131.0 eller nyere, og Goose 1.44.0 eller nyere. For agenter uden officiel rettelse anbefaler Manifold Security, at teams selv tilføjer flaget -c core.fsmonitor=false til enhver baggrundskørsel af git-kommandoer, hvis det er muligt at konfigurere agentens opførsel på det niveau.
Herudover bør organisationer overveje at køre AI-kodeagenter i isolerede, ikke-privilegerede brugerkonti eller containere, adskilt fra udviklerens hovedmiljø med SSH-nøgler, cloud-adgangstokens og produktionsadgang. Det lyder som en selvfølge, men ifølge flere af de citerede sikkerhedsrapporter kører de fleste installationer i dag agenten med den samme brugerkonto og de samme rettigheder som udvikleren selv, hvilket gør enhver eksekveringsfejl til en fuld kompromittering af udviklerens session.
For DeepSeek Harness-brugere er anbefalingen entydig: opdater til 0.1.2-alpha.1 eller nyere, og undlad at videresende control-plane-porten til eksterne netværk, uanset hvor bekvemt det virker under fjernarbejde. For Gemini CLI-brugere bør organisationer afvente en officiel patch fra Google og i mellemtiden undgå at lade agenten køre værktøjer, der ikke er strengt nødvendige, da værktøjsbegrænsningen ifølge de foreliggende oplysninger reelt ikke blev håndhævet.
Analyse: hvorfor samme fejltype rammer så mange leverandører samtidig
Det mest slående ved GitSpawn er ikke den enkelte tekniske fejl, men at otte uafhængige implementeringer fra syv forskellige virksomheder alle indeholdt variationer af den samme grundlæggende svaghed. Det tyder på en strukturel årsag frem for individuel skødesløshed: AI-kodeagenter er bygget oven på et økosystem af værktøjer, git, shell, HTTP, der historisk er designet til at blive brugt af en betroet, menneskelig operatør, ikke af en autonom proces, der fortolker ubetroet indhold og handler på det uden mellemliggende godkendelse.
Når en agent skal “føles” hurtig og reagere øjeblikkeligt på en ny mappe, er det fristende at lade den hente kontekst i baggrunden, før brugeren overhovedet har stillet et spørgsmål. Det er præcis det designvalg, der åbnede døren for GitSpawn. Samme logik går igen i DeepSeek Harness-fejlen, hvor bekvemmeligheden ved en lokal API uden kompleks autentificering blev prioriteret over streng validering af, hvor kald reelt kom fra. Mønsteret peger på, at flere sårbarheder af samme type sandsynligvis vil dukke op i de kommende måneder, efterhånden som flere sikkerhedsforskere begynder systematisk at lede efter dem i det voksende antal agent-frameworks.
Fremtidsudsigter: fem forudsigelser for AI-agent-sikkerhed
- Flere leverandører vil indføre eksplicit sandboxing som standard. Efter GitSpawn og DeepSeek Harness-sagen er det sandsynligt, at flere agent-leverandører fremover kører værktøjskald i isolerede containere eller virtuelle maskiner som standardopsætning frem for en valgfri sikkerhedsfunktion.
- Sikkerhedsrevisioner af agent-infrastruktur bliver et konkurrenceparameter. Ligesom no-logs-audits blev afgørende for VPN-udbydere, vil uafhængige sikkerhedsrevisioner af agenters kommandohåndtering sandsynligvis blive et salgsargument, virksomheder som Cursor og Anthropic fremhæver over for erhvervskunder.
- Flere CVE’er i samme kategori inden årets udgang. Givet at otte fejl allerede er fundet på tværs af syv agenter med samme grundlæggende antagelse, er det sandsynligt, at yderligere sårbarheder i git-kontekstindsamling og lokale control-plane-API’er offentliggøres i løbet af fjerde kvartal 2026.
- Regulatorisk pres vil stige i EU. Med NIS2 og Cyber Resilience Act allerede i kraft er det sandsynligt, at tilsynsmyndigheder i Danmark og resten af EU i stigende grad vil stille konkrete krav til, hvordan virksomheder styrer risici forbundet med AI-udviklerværktøjer i deres forsyningskæde.
- Mindre, mindre velfinansierede agent-projekter risikerer at blive fravalgt. Virksomheder, der endnu ikke har rettet GitSpawn efter flere uger, som Qwen Code, Grok Build og Hermes Agent, risikerer at miste tillid hos virksomhedskunder, der i stigende grad screener leverandører for sikkerhedsrespons, ikke kun funktionalitet.
Markedspåvirkning: tillid som ny valuta i agent-økosystemet
Sikkerhedsfund som GitSpawn ændrer sjældent adoptionskurven for AI-kodeagenter markant på kort sigt, men de ændrer, hvilke spørgsmål indkøbsansvarlige stiller, før de underskriver en enterprise-aftale. Hvor samtalen for et år siden primært handlede om, hvilken model der leverede den bedste kodekvalitet målt på benchmarks som SWE-bench, handler den i stigende grad om, hvordan leverandøren håndterer sikkerhedsrapporter, hvor hurtigt de patcher, og hvor gennemsigtige de er om resterende risici.
Det giver isoleret set en fordel til de store, velfinansierede aktører som Anthropic, OpenAI og Google, der har ressourcer til dedikerede sikkerhedsteams og koordineret sårbarhedshåndtering, selv når deres første rettelse er ufuldstændig, som det var tilfældet med Claude Code. Mindre og nyere projekter som Hermes Agent og Qwen Code, der endnu mangler en synlig sikkerhedsproces, risikerer at blive holdt uden for større virksomheders godkendte værktøjslister, uanset hvor god deres kodegenerering i øvrigt er.
Ofte stillede spørgsmål om GitSpawn og de nye AI-agent-sårbarheder
Hvad er GitSpawn helt konkret?
GitSpawn er navnet, Manifold Security har givet en klasse af otte sårbarheder, der udnytter Git-indstillingen core.fsmonitor i .git/config til at få AI-kodeagenter til at eksekvere angriberkontrolleret kode, blot ved at agenten åbner et fjendtligt repository og kører en rutinemæssig baggrundskommando som git status.
Hvilke AI-kodeagenter er berørt af GitSpawn?
Syv agenter er dokumenteret berørt: Claude Code, OpenAI’s Codex CLI, Cursor, Blocks Goose, Alibabas Qwen Code, xAI’s Grok Build og Hermes Agent. Claude Code, Codex CLI, Goose og Cursor har fået rettelser, mens Qwen Code, Grok Build og Hermes Agent ifølge de senest tilgængelige oplysninger fortsat mangler en officiel patch.
Er min version af Claude Code sikker efter opdateringen til 2.1.196?
Delvist. Version 2.1.196 lukker den oprindeligt rapporterede fsmonitor-sti, men Cloud Security Alliance har noteret, at en separat konfigurationssti fortsat kan være sårbar. Følg Anthropics kommende sikkerhedsopdateringer tæt.
Hvad skal jeg gøre, hvis jeg bruger DeepSeek Harness?
Opdater til version 0.1.2-alpha.1 eller nyere med det samme, da denne version lukker CVE-2026-82533. Sørg desuden for, at den lokale control-plane-port aldrig videresendes til et eksternt tilgængeligt netværk.
Kan angrebet ramme mig, hvis jeg kun arbejder med interne, betroede repositories?
Risikoen er markant lavere, men ikke nul. GitSpawn kræver, at repositoriet indeholder en ondsindet fsmonitor-indstilling, hvilket typisk kræver, at en angriber kan bidrage til eller kompromittere repositoriet. Åbning af eksterne, open source- eller ukendte repositories udgør den klart største risiko.
Er dette relateret til tidligere sikkerhedsfund som GhostSplice?
Nej, ikke direkte. GhostSplice udnyttede prompt injection via MCP-protokollen til at lække nøgler, mens GitSpawn og DeepSeek Harness-fejlen udnytter klassisk infrastruktur som Git-konfiguration og HTTP-headere. De to sagstyper viser dog samme underliggende problem: AI-agenter, der handler autonomt på ubetroet input.
Hvor mange udviklere bruger overhovedet autonome AI-agenter?
Ifølge Stack Overflows udviklerundersøgelse fra 2025 bruger 14,1 procent af udviklerne AI-agenter dagligt på arbejdet, 9 procent ugentligt og 7,8 procent månedligt eller sjældnere, hvilket samlet svarer til omkring en tredjedel af de adspurgte.
Hvilken CVSS-score har den alvorligste af de nye sårbarheder?
Den sårbarhed, der er rapporteret i Google Gemini CLI, blev ifølge sikkerhedsanalytikeren Adversas materiale vurderet til den maksimale CVSS-score på 10,0, mens DeepSeek Harness-fejlen CVE-2026-82533 fik en CVSS-score på 9,4.
