Fyrtio minuter, 195 terabyte och 2 500 drabbade organisationer – så fungerar den nya tidens mjukvaruattacker

När ett enda verktyg räcker för att kompromissa tusentals system

I mars i år öppnades ett tidsfönster på precis fyrtio minuter. Det räckte. Under den korta perioden hann ett manipulerat paket spridas via det officiella Python-paketarkivet, leta sig in i hundratusentals driftsättningsmiljöer och skrapa arbetsminnet på drabbade datorer. Resultatet: en datafil på 195 terabyte med inloggningsuppgifter från mer än 2 500 organisationer och cirka 434 000 mjukvarumiljöer.

Det avslöjar säkerhetsföretagen CloudSEK och Hudson Rock i en ny rapport. Bland de drabbade återfinns Nvidia, Amazon Web Services, Samsung, Cisco, Salesforce, Siemens, Volkswagen, Deloitte och Londons fondbörs – en lista som läses som ett koncentrat av global teknisk och ekonomisk infrastruktur.

LiteLLM – ett populärt AI-verktyg som blev en bakdörr

Angreppsvägen är tekniskt elegant och därför extra oroande. I centrum står LiteLLM, ett välkänt öppen källkod-bibliotek som används flitigt inom AI-driven programvaruutveckling för att samordna anrop mot stora språkmodeller. Verktyget är populärt just för att det är smidigt och välunderhållet – egenskaper som gör att utvecklare litar på det och sällan ifrågasätter integriteten hos varje ny version.

Men LiteLLM var i sin tur ett offer. Angriparna hade dessförinnan lyckats kompromissa Trivy, ett etablerat säkerhetsskanningsverktyg som många organisationer använder för att just kontrollera att deras programvarukedjor är rena. Även verktygen KICS och Telnyx Python SDK drabbades i samma kampanj. Det är en nästan ironisk konstruktion: säkerhetsverktyget som skulle skydda blev vektorn för angreppet.

Tekniken kallas supply chain attack – på svenska ett angrepp mot mjukvaruförsörjningskedjan – och är en av de svåraste att försvara sig mot. Istället för att bryta sig in direkt i ett målsystems försvar, infiltrerar angriparna ett verktyg som målet redan litar på och använder dagligen.

Tonåringar bakom en attack av industriell skala

En grupp som kallar sig TeamPCP har tagit på sig ansvaret. Enligt rapporten från CloudSEK och Hudson Rock består gruppen till stor del av tonåringar. Det låter som en parentes, men är egentligen en viktig signal: den tekniska tröskel som krävs för att genomföra ett angrepp av den här skalan fortsätter att sjunka. Kompetens, verktyg och sårbar infrastruktur finns tillgängliga för allt yngre och mer lättrörliga aktörer.

Vad betyder det för svenska organisationer?

Det korta svaret: mer än vad många inser. Sverige har ett stort och växande ekosystem av mjukvarubolag, myndigheter och industrier som aktivt anammar AI-verktyg i sina utvecklingsflöden. LiteLLM är precis den typ av bibliotek som dyker upp i moderna AI-projekt – det är lättanvänt, väldokumenterat och minskar friktionen i arbetet.

Svenska företag som bygger med Python, integrerar stora språkmodeller eller använder containersäkerhetsverktyg som Trivy bör nu gå igenom sina beroenden och kontrollera vilka versioner de kört under mars månad. Det handlar inte om panik, utan om systematisk hygien.

Mer strukturellt pekar det här mot behovet av intern kontroll av mjukvaruberoenden – det som på engelska kallas software bill of materials (SBOM), ungefär en ingrediensförteckning för programvara. Flera EU-regelverk, däribland Cyber Resilience Act, driver redan på i den riktningen. Det här angreppet ger den diskussionen ny aktualitet.

Öppen källkod är inte problemet – men det kräver vaksamhet

Det vore fel att dra slutsatsen att öppen källkod i sig är farligt. Öppen källkod är och förblir en av de viktigaste grundpelarna i modern mjukvaruutveckling – transparent, granskningsbar och ofta mer robust än proprietära alternativ. Men öppenhet är inte detsamma som obevakad. Den här attacken utnyttjade det förtroende som vuxit fram kring välkända paket, och det är det förtroendet vi nu måste förvalta mer aktivt.

För den som bygger system är lärdomen tydlig: integrera automatiserad kontroll av paketintegritet i er leveransprocess, sätt upp varningar för oväntade versionsändringar och behandla uppdateringsprocessen med samma noggrannhet som ni lägger på er egen kod.