Kritisk sårbarhet i AI-ramverket Ray utnyttjas aktivt – CISA gav myndigheter tre dagar att patcha
Amerikanska cybersäkerhetsmyndigheten CISA har lagt till sårbarheten CVE-2025-62593 i sin katalog över kända, aktivt utnyttjade sårbarheter (KEV). Det handlar om en kritisk brist som tillåter fjärrkörning av kod i Ray –
Innehåll
Amerikanska cybersäkerhetsmyndigheten CISA har lagt till sårbarheten CVE-2025-62593 i sin katalog över kända, aktivt utnyttjade sårbarheter (KEV). Det handlar om en kritisk brist som tillåter fjärrkörning av kod i Ray – open source-ramverket som används för att skala maskininlärningsarbetslaster hos bland andra Amazon, Apple och OpenAI. Sårbarheten har fått CVSS-poängen 9.4, och federala myndigheter i USA fick enligt uppgift till den 20 augusti på sig att patcha, rapporterar AI News Today.
Att en sårbarhet hamnar i KEV-katalogen betyder en sak: den utnyttjas redan i verkliga attacker. Det är inte en teoretisk risk i en labbmiljö.
Vad Ray gör – och varför det är ett så attraktivt mål
Ray är ett distribuerat beräkningsramverk som används för att träna modeller, köra inferens och parallellisera tunga Python-jobb över många maskiner. Det sitter alltså mitt i AI-stacken, med tillgång till både beräkningsresurser, träningsdata och ofta molnkrediter.
Ett Ray-kluster är designat för att lita på sina egna noder. Får en angripare köra kod på klustret får hen i praktiken tillgång till hela beräkningsmiljön. Det gör AI-infrastruktur till ett eget angreppsmål, skilt från de klassiska webb- och databaslagren som säkerhetsteam är vana att bevaka.
Det här bör svenska team göra nu
Ray finns i fler svenska ML-stackar än många tror – hos scaleups som tränar egna modeller, hos konsultbolag som bygger kunddriftmiljöer och hos forskningsgrupper med egna GPU-kluster. Konkret checklista:
- Inventera. Vet du var Ray körs i din organisation? Sök igenom requirements-filer, container-images och Kubernetes-manifest.
- Kontrollera exponering. Ray-dashboarden och klientporten ska aldrig ligga öppet mot internet. Skanna dina publika IP-adresser och kontrollera säkerhetsgrupperna i molnet.
- Uppdatera. Läs Ray-projektets egen säkerhetsadvisory och installera den version som åtgärdar CVE-2025-62593.
- Segmentera. Lägg klustret i ett eget nätverkssegment med strikt utgående trafik. Ett komprometterat träningsjobb ska inte kunna nå produktionsdatabasen.
- Leta bakåt. Om klustret varit exponerat räcker det inte att patcha. Gå igenom loggar efter okända jobb, nya processer och avvikande utgående anslutningar.
Två saker vi inte kan bekräfta
Vi är transparenta med osäkerheten: uppgifterna ovan bygger på en enda rapportering, och tidsangivelsen med ett CVE-nummer från 2025 och en åtgärdsdeadline den 20 augusti går inte helt ihop utan mer information. Det kan handla om ett CVE som tilldelats i efterhand, eller om ett fel i rapporteringen.
Kontrollera därför alltid mot CISA:s egen KEV-katalog och mot Ray-projektets GitHub-advisory innan du agerar på detaljer som versionsnummer och datum. Grundbudskapet – patcha och stäng exponerade kluster – står sig oavsett.
Varför det här är en styrelsefråga, inte bara DevOps
AI-förordningen ställer krav på riskhantering, loggning och incidenthantering för system som klassas som högrisk. En komprometterad träningsmiljö är inte bara ett driftstopp – det kan vara en dataläcka, en manipulerad modell och ett regelbrott på samma gång.
Att en angripare kan modifiera träningsdata eller modellvikter utan att någon märker det är dessutom svårare att upptäcka än en vanlig dataläcka. Modellen fortsätter fungera. Den fungerar bara lite annorlunda än du tror.
Det här ligger i linje med varningarna från underrättelsealliansen Five Eyes om att AI-drivna cyberattacker snabbt blir vardag. Skillnaden är att här är det AI-infrastrukturen själv som är målet.
Open source är inte problemet – underhållet är det
Det är lätt att dra slutsatsen att öppna ramverk är osäkrare. Så enkelt är det inte. Öppen kod ger dig insyn, möjlighet att granska och en snabb patchcykel. Priset är att ansvaret för att faktiskt installera patchen ligger hos dig, inte hos en leverantör med SLA. Den avvägningen har vi gått igenom mer utförligt i vår genomgång av open source mot proprietära AI-modeller.
Samma logik gäller när AI-agenter börjar köra kod och anropa API:er i produktionsmiljöer – något allt fler svenska bolag gör, vilket vi beskrivit i AI-agenter i praktiken. Varje nytt lager i stacken är en ny angreppsyta.
Nästa steg
Kör en snabb inventering redan idag: vilka Ray-kluster har ni, vilka portar är öppna och vilken version kör ni? Går det inte att svara på inom en timme har ni hittat ert egentliga problem – och det är inte den här specifika sårbarheten.