De flesta säkerhetsberättelserna i det här nyhetsbrevet handlar om saker som händer dig direkt: ett nätfiskemeddelande, ett läckt lösenord, en falsk shoppingsajt. Den här är annorlunda. Incidenterna nedan drabbade utvecklare — personerna som skriver apparna och tjänsterna du använder varje dag. Men anledningen till att de hör hemma här är enkel: om någon förgiftar verktygen som används för att bygga programvara stannar giftet inte hos byggaren. Det levereras med produkten.
Två saker inträffade nyligen som illustrerar detta. Ingen av dem blev en lika stor nyhet som ett omfattande dataintrång, eftersom ingen av dem specifikt var ett intrång i dig. Båda är attacker mot den kedja som producerar programvaran du så småningom installerar, öppnar eller loggar in i.
Förfalskade tillägg utklädda till betrodda varumärken
Open VSX är en offentlig marknadsplats för kodredigerartillägg — små tillägg som utvecklare installerar för att få autokomplettering, lintning och integrationer för verktygen de använder dagligen (Visual Studio Code och flera av dess öppen källkod-baserade kusiner hämtar tillägg därifrån). Mellan den 26 juli och den 1 augusti 2026 hittade säkerhetsforskare vid Manifold Security 77 förfalskade tillägg i registret. Vart och ett kopierade namnet och namnrymden från ett äkta, betrott tillägg, men publicerades från ett konto som inte ägde originalet — ett klassiskt sätt att utge sig för någon annan, ibland kallat namnrymdskapning.
De kapade namnen var inte slumpmässiga. De lånade identiteterna från AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforces projekt med öppen källkod, en amerikansk federal myndighet och — med en sorts mörk ironi — själva tilläggsmarknadsplatsen. Alla de 77 paketen ringde hem till en enda domän som hade registrerats bara 11 dagar innan det första falska paketet dök upp, ett mönster som tyder på en samordnad, specialbyggd kampanj snarare än opportunistisk kopiering.
De flesta falska tilläggen gjorde något ganska anspråkslöst: de rapporterade i tysthet tillbaka ett värdnamn till angriparens server, vilket i sig kanske bara är en kontroll för att se vem som installerat betet. Men forskarna fann att ungefär en fjärdedel av de 77 — 19 paket — gick längre. Sekunder efter aktiveringen samlade de in värdnamnet, användarnamnet i operativsystemet, information om redigeraren och ett maskin-ID. Sedan läste de det projekt som utvecklaren hade öppet: git-fjärranslutningen (som avslöjar organisationen och värden för kodarkivet), domänen i commit-mejladressen, den aktuella grenen och den senaste committen. De hämtade också värden för kontinuerlig integration — autentiseringsuppgifterna och konfigurationen som låter automatiserade system bygga och distribuera kod utan att en människa behöver skriva in ett lösenord varje gång.
Inga av dessa data är användbara för att tömma någons bankkonto. De är användbara för något annat: att ta reda på vilka företag en utvecklare arbetar för, hur deras interna infrastruktur ser ut och hur man får fotfäste i den.
Ett fel med 9,8 av 10 i maskinen som bygger programvaran
Den andra incidenten gäller TeamCity, en plattform för kontinuerlig integration och kontinuerlig leverans (CI/CD) från JetBrains. Om en kodredigerare är platsen där utvecklare skriver programvara, är en CI/CD-plattform fabriksgolvet där koden automatiskt kompileras, testas och skickas ut i produktion — ofta utan att någon människa alls klickar på ”distribuera”. TeamCity är en central del av den maskinparken hos många företag.
En sårbarhet som spåras som CVE-2026-63077, med allvarlighetsgraden 9,8 av möjliga 10, offentliggjordes i TeamCitys lokala versioner. Det är ett deserialiseringsfel — en typ av fel där ett program litar tillräckligt mycket på inkommande data för att omvandla den direkt till körbar kod, utan att först kontrollera vad datan faktiskt är. I praktiken gjorde det att en angripare kunde skicka en begäran till en sårbar TeamCity-server, utan att behöva logga in, och köra godtyckliga kommandon med samma behörigheter som själva TeamCity-tjänsten. JetBrains släppte korrigeringar (versionerna 2025.11.7 och 2026.1.3 samt ett korrigeringsplugin för äldre installationer från 2017.1 och framåt), men USA:s myndighet för cybersäkerhet och infrastruktursäkerhet (CISA) har sedan varnat för att angripare aktivt utnyttjar system som inte har uppdaterats.
Den som kontrollerar ett företags byggserver kontrollerar vad företaget levererar. Det är inte hypotetiskt — det är bokstavligen verktygets funktion.
Samma spelbok, två olika dörrar
Det här är orelaterade incidenter från olika forskare, men de har samma form. Ingen av dem angriper en färdig produkt. Båda angriper ett tidigare steg — redigeraren som en utvecklare skriver kod i eller servern som omvandlar den koden till en levererad version. Det är det som kännetecknar en attack mot programvarans leveranskedja: i stället för att bryta sig in i ett mål komprometterar man något uppströms som många mål är beroende av och låter deras egen betrodda process föra åtkomsten vidare åt en.
Det är värt att vara ärlig om vad vi ännu inte vet. Ingen av rapporterna som kom fram den här veckan beskrev ett bekräftat fall där en app eller användare längre ned i kedjan komprometterats som ett direkt resultat — kampanjen med tilläggen ser ut att handla om kartläggning och insamling av åtkomst, och TeamCity-utnyttjandet beskrivs som aktivt men utan namngivna offer. Det är normalt; komprometteringar av leveranskedjan upptäcks ofta vid ingångspunkten långt innan (eller i stället för att) den slutliga effekten kan spåras.
Varför det här är ditt problem, inte bara deras
Du kommer förmodligen aldrig att installera ett kodningstillägg eller köra en CI/CD-server. Men du använder resultatet från hundratals sådana: din bankapp, din lösenordshanterare, ditt barns skolportal, webbläsaren du läser det här i. Allt passerade genom någon utvecklares redigerare och något företags byggpipeline innan det nådde din telefon. Om någon av dessa länkar i tysthet komprometteras kan den skadliga ändringen följa med en vanlig, rutinmässig programuppdatering — den sortens uppdatering du installerar eftersom du har fått höra att uppdatering är det säkra man ska göra.
Det är också därför råden i en rapport efter ett dataintrång ibland låter märkliga för icke-tekniska läsare: ett företag säger att dess system komprometterades via en byggserver, en stulen utvecklarinloggning eller ett skadligt beroende, och det kan låta abstrakt jämfört med ”någon gissade mitt lösenord”. Det är inte abstrakt. Det är samma resultat — dina data eller integriteten i din app har komprometterats — men via en dörr du aldrig visste fanns.
Vad som faktiskt hjälper
Du kan inte granska din banks CI/CD-pipeline, och det ska du inte behöva göra. Men några vanor minskar faktiskt din exponering för den här typen av risk:
Ha automatiska uppdateringar aktiverade, men behandla inte uppdateringar som automatiskt betrodda. Det är genom korrigeringar som sådana åtgärder som TeamCity-korrigeringen ovan når programvaran du kör — att hålla sig uppdaterad stänger fönster som angripare aktivt sonderar. Samtidigt är en uppdatering bara så bra som pipelinen som producerade den, vilket är precis det som angrips här; det finns inget perfekt individuellt försvar mot en verkligt förgiftad uppströmsversion, och därför är detta i grunden ett leverantörsansvarsproblem, inte ditt problem.
Om du arbetar med eller leder utvecklare finns det två konkreta saker som går att kontrollera: verifiera att alla kodredigerartillägg installeras från det faktiska verifierade utgivarkontot, inte bara från ett konto med matchande namn (Open VSX och liknande marknadsplatser visar utgivarens identitet — kontrollera den och lita inte enbart på ikonen och titeln); och om din organisation kör TeamCity lokalt, bekräfta i dag att det kör 2025.11.7, 2026.1.3 eller har korrigeringspluginet installerat, inte vid nästa underhållsfönster — CISA:s varning betyder att detta utnyttjas aktivt, inte att det bara är teoretiskt.
För alla andra är den användbara förändringen helt enkelt medvetenhet: när du läser om ett företags dataintrång som kan spåras tillbaka till ”ett komprometterat utvecklarverktyg” eller ”ett byggsystem” är det inte en nischad teknisk fotnot. Det är samma kategori av händelse som lösenordsintrången och nätfiskebedrägerierna som det här nyhetsbrevet oftare tar upp — den började bara ett lager längre uppströms, innan produkten någonsin nådde dig.
