De fleste sikkerhedshistorier i dette nyhedsbrev handler om ting, der sker direkte for dig: en phishing-sms, en lækket adgangskode, en falsk shoppingside. Denne er anderledes. Hændelserne nedenfor skete for udviklere — de mennesker, der skriver de apps og tjenester, du bruger hver dag. Men grunden til, at de hører hjemme her, er enkel: Hvis nogen forgifter de værktøjer, der bruges til at bygge software, bliver giften ikke hos udvikleren. Den følger med produktet.
Der skete for nylig to ting, der illustrerer dette. Ingen af dem skabte overskrifter på samme måde som et stort databrud, fordi ingen af dem specifikt var et brud på dig. Begge er angreb på den pipeline, der producerer den software, du senere installerer, åbner eller logger ind på.
Forfalskede udvidelser udgivet under betroede mærker
Open VSX er en offentlig markedsplads for udvidelser til kodeeditorer — de små tilføjelser, udviklere installerer for at få autofuldførelse, linting og integrationer til de værktøjer, de bruger dagligt (Visual Studio Code og flere af dens open source-søskende henter udvidelser derfra). Mellem 26. juli og 1. august 2026 fandt sikkerhedsforskere hos Manifold Security 77 forfalskede udvidelser i registret. Hver af dem kopierede navnet og namespace'et fra en ægte, betroet udvidelse, men var udgivet fra en konto, der ikke ejede originalen — et klassisk forsøg på at udgive sig for en anden, sommetider kaldet namespace-squatting.
De kaprede navne var ikke tilfældige. De lånte identiteter fra AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforces open source-projekter, et amerikansk føderalt agentur og — med en vis mørk ironi — selve markedspladsen for udvidelser. Alle 77 pakker ringede hjem til ét domæne, der var blevet registreret blot 11 dage før den første falske pakke dukkede op, et mønster, der tyder på en koordineret, målrettet kampagne snarere end opportunistisk kopiering.
De fleste af de falske udvidelser gjorde noget beskedent: De rapporterede stille et værtsnavn tilbage til angriberens server, hvilket i sig selv måske blot var en kontrol af, hvem der havde installeret lokkemaden. Men forskerne fandt, at omtrent en fjerdedel af de 77 — 19 pakker — gik videre. Sekunder efter aktivering indsamlede de værtsnavnet, brugernavnet til operativsystemet, oplysninger om editoren og et maskin-id. Derefter læste de det projekt, udvikleren havde åbent: git-fjernlageret (som afslører organisationen og lagerets vært), domænet i commit-mailadressen, den aktuelle gren og den seneste commit. De hentede også værdier fra continuous integration — de legitimationsoplysninger og den konfiguration, der lader automatiserede systemer bygge og udrulle kode, uden at et menneske skal skrive en adgangskode hver gang.
Ingen af disse data er nyttige til at tømme nogens bankkonto. De er nyttige til noget andet: at finde ud af, hvilke virksomheder en udvikler arbejder for, hvordan deres interne infrastruktur ser ud, og hvordan man får fodfæste i den.
En fejl med en score på 9,8 ud af 10 i den maskine, der bygger softwaren
Den anden hændelse involverer TeamCity, en platform til continuous integration og continuous delivery (CI/CD) fremstillet af JetBrains. Hvis en kodeeditor er det sted, hvor udviklere skriver software, er en CI/CD-platform det automatiserede fabriksgulv, hvor koden kompileres, testes og sendes i produktion — ofte uden at et menneske overhovedet klikker på »deploy«. TeamCity er en central del af det maskineri hos mange virksomheder.
En sårbarhed, der spores som CVE-2026-63077, med en alvorlighedsscore på 9,8 ud af højst 10, blev offentliggjort i TeamCitys on-premises-versioner. Det er en deserialiseringsfejl — en klasse af fejl, hvor et program stoler så meget på indgående data, at det omdanner dem direkte til kørende kode uden først at kontrollere, hvad dataene faktisk er. I praksis gjorde den det muligt for en angriber at sende en forespørgsel til en sårbar TeamCity-server uden login og køre vilkårlige kommandoer med de samme rettigheder som selve TeamCity-tjenesten. JetBrains udsendte patches (version 2025.11.7 og 2026.1.3 samt et patch-plugin til ældre installationer fra 2017.1 og frem), men det amerikanske Cybersecurity and Infrastructure Security Agency (CISA) har siden advaret om, at angribere aktivt udnytter systemer, der ikke er blevet patchet.
Den, der kontrollerer en virksomheds build-server, kontrollerer, hvad virksomheden sender ud. Det er ikke hypotetisk — det er bogstaveligt talt værktøjets funktion.
Samme drejebog, to forskellige indgange
Det er uafhængige hændelser undersøgt af forskellige forskere, men de har samme form. Ingen af dem angriber et færdigt produkt. Begge angriber et tidligere trin — den editor, en udvikler skriver kode i, eller serveren, der omdanner koden til en udgivet version. Det er det definerende træk ved et angreb på softwareforsyningskæden: I stedet for at bryde ind i ét mål kompromitterer man noget længere oppe i kæden, som mange mål er afhængige af, og lader deres egen betroede proces føre adgangen videre for en.
Det er værd at være ærlig om, hvad vi endnu ikke ved. Ingen af de rapporter, der kom frem i denne uge, beskrev et bekræftet tilfælde, hvor en downstream-app eller -bruger var blevet kompromitteret som et direkte resultat — kampagnen med udvidelserne ligner rekognoscering og indsamling af adgang, og TeamCity-udnyttelsen beskrives som aktiv, men uden navngivne ofre. Det er normalt; kompromitteringer af forsyningskæden opdages ofte ved indgangspunktet længe før (eller i stedet for), at det endelige udbytte kan spores.
Hvorfor dette er dit problem, ikke kun deres
Du installerer sandsynligvis aldrig en kodeudvidelse eller driver en CI/CD-server. Men du bruger resultatet fra hundredvis af dem: din bankapp, din adgangskodeadministrator, dit barns skoleportal, browseren, du læser dette i. Alt passerede gennem en udviklers editor og en virksomheds build-pipeline, før det nåede din telefon. Hvis et af disse led i al stilhed bliver kompromitteret, kan den skadelige ændring følge med en almindelig, rutinemæssig softwareopdatering — den slags, du installerer, fordi du har fået at vide, at opdatering er det sikre valg.
Det er også derfor, at rådene i en analyse efter et databrud nogle gange virker mærkelige for ikke-tekniske læsere: En virksomhed siger, at dens systemer blev kompromitteret via en build-server, en stjålet udviklerlegitimation eller en skadelig afhængighed, og det kan lyde abstrakt sammenlignet med »nogen gættede min adgangskode«. Det er ikke abstrakt. Det er det samme resultat — dine data eller integriteten af din app er kompromitteret — blot nået gennem en dør, du ikke vidste eksisterede.
Hvad der faktisk hjælper
Du kan ikke revidere din banks CI/CD-pipeline, og det bør du heller ikke være nødt til. Men nogle få vaner reducerer reelt din eksponering for denne risikokategori:
Lad automatiske opdateringer være slået til, men betragt ikke opdateringer som automatisk troværdige. Patches er den måde, rettelser som TeamCity-rettelsen ovenfor når frem til den software, du kører — ved at holde dig opdateret lukker du vinduer, som angribere aktivt undersøger. Samtidig er en opdatering kun så god som den pipeline, der producerede den, hvilket netop er det, der angribes her; der findes intet perfekt individuelt forsvar mod en upstream-udgivelse, der reelt er blevet forgiftet, og derfor er dette grundlæggende et leverandøransvarsproblem, ikke dit problem.
Hvis du arbejder med eller leder udviklere, er der to konkrete ting, du kan kontrollere: Bekræft, at enhver kodeeditorudvidelse er installeret fra den faktiske verificerede udgiverkonto og ikke blot har et matchende navn (Open VSX og lignende markedspladser viser en udgiveridentitet — kontrollér den, og stol ikke alene på ikonet og titlen); og hvis din organisation kører TeamCity on-premises, så bekræft i dag, at den er på 2025.11.7, 2026.1.3 eller har patch-pluginet installeret — ikke ved næste vedligeholdelsesvindue. CISAs advarsel betyder, at dette bliver aktivt udnyttet, ikke at det blot er teoretisk.
For alle andre er det nyttige skift blot at være opmærksom: Når du læser om et virksomhedsdatabrud, der kan spores tilbage til »et kompromitteret udviklerværktøj« eller »et build-system«, er det ikke en snæver teknisk fodnote. Det er den samme kategori af hændelse som adgangskodebruddene og phishing-svindlerne, dette nyhedsbrev oftere dækker — den begyndte bare et lag længere oppe i kæden, før produktet overhovedet nåede frem til dig.
