CVE-2026-59310: VMware vCenter-kampanjen visar varför en patch inte räcker

Broadcom har släppt korrigerade versioner men ingen workaround. Att installera de uppdateringar som anges av leverantören är därför den officiella åtgärden för sårbara system.

Tidslinjen: patchen kom först – exploateringen fem dagar senare

Broadcom offentliggjorde CVE-2026-59310 och släppte patchar den 29 juli. QUIRSO rapporterade tecken på aktiv exploatering från och med den 3 augusti, varefter kampanjen växte snabbt.

Tidslinjen är viktig för incidenthanteringen. Ett system som patchades efter den 3 augusti kan inte anses vara rent bara för att uppdateringen lyckades. Organisationer måste skilja mellan att åtgärda sårbarheten och att utreda en möjlig kompromettering: installera patchen, men undersök därefter om angriparen redan hade etablerat åtkomst.

Kampanjens omfattning

Forskare kopplade aktiviteten till 361 observerade offer-IP-adresser i 47 länder. Tyskland, USA, Turkiet, Iran och Frankrike stod enligt rapporteringen för mer än hälften av de observerade adresserna.

Siffran måste tolkas med viss försiktighet. En IP-adress motsvarar inte nödvändigtvis en organisation, så ”361 offer” betyder inte automatiskt 361 separata företag eller myndigheter. Den tillgängliga rapporteringen visar däremot på en bred kampanj mot internetåtkomliga eller på annat sätt nätverksexponerade vCenter-system.

Varför forskare ser en möjlig Kina-koppling

QUIRSO bedömde kampanjens koppling till Kina med måttlig säkerhet. De rapporterade indikatorerna omfattar kinesiska språkspår, verktyg och offentligt återanvänd material, aktivitet som stämmer med arbetstider i tidszonen UTC+08:00 samt en offerbild där fastlandskina tycks saknas.

Ledtrådarna stöder en regional eller språklig bedömning, men identifierar ingen namngiven kinesisk statsaktör och bevisar inte att en regering ligger bakom operationen. Attribution som bygger på skadeprogram, tidsmönster och målval kan förändras när nya bevis kommer fram. Den mest försiktiga beskrivningen är därför ”misstänkt Kina-kopplad aktör”, inte en bekräftat statsstödd operation.

Den rapporterade attackkedjan

Kampanjen tycks ha använt CVE-2026-59310 för det första intrånget och därefter lagt till flera lager av beständighet och åtkomst:

1. Katalogtraversering: Specialutformade anrop till Syslog-tjänsten användes för att lämna den avsedda sökvägen och skriva angriparkontrollerat innehåll.
2. Beständighet via cron: Angriparna uppges ha skapat felaktigt formaterade cron-poster som kunde starta efterföljande kommandon.
3. Leverans av bakdörr: curl eller wget hämtade enligt rapporteringen bakdörren linuxFile, som använder WebSocket och XOR-baserad fördunkling.
4. Reverse SSH: Verktyg för reverse SSH installerades för att skapa utgående åtkomst tillbaka till angriparnas infrastruktur. Shadowserver rapporterade att denna beständighetsmekanism fanns på samtliga offer i den särskilda rapporten.
5. Missbruk av konton och inloggningsuppgifter: Utredare rapporterade obehöriga vCenter- och ESXi-administratörskonton samt missbruk av autentiseringsuppgifter i VMware Directory Service.
6. Ransomware: Åtminstone en del av rapporteringen kopplar aktiviteten till en Babuk-baserad ransomwarevariant som lägger till filändelsen .babyk.

Fyndet av reverse SSH är särskilt betydelsefullt. Shadowservers slutsats är att system där mekanismen har installerats ska behandlas som helt komprometterade. Att bara ta bort en binärfil eller radera ett cron-jobb räcker inte; organisationen måste återupprätta förtroendet för appliance-systemet och byta privilegierade autentiseringsuppgifter.

Ransomware kan ha använts för att dölja spår

Den rapporterade .babyk-aktiviteten beskriver inte nödvändigtvis en traditionell ransomwarekampanj vars huvudmål är bred kryptering och utpressning. Analytiker har föreslagit att selektiv kryptering av ESXi-loggar kan ha varit avsedd att försvåra utredningen och dölja bevis.

Detta är fortfarande en slutsats från analytikerna, inte ett bekräftat uttalande om angriparnas avsikt. Försvarare bör ändå utreda båda möjligheterna: ransomwarepåverkan på virtuella maskiner och avsiktlig manipulation av loggar för att försvåra analysen.

GitHub-repository dolde reverse-SSH-verktyg

Rapporteringen kopplade också operationen till ett GitHub-repository som presenterade binärer för reverse SSH som ett Linuxverktyg för rensning av temporära filer. Att maskera ett verktyg för beständighet som ett administrations- eller städverktyg kan göra det enklare att distribuera och mindre uppseendeväckande vid rutinmässiga kontroller. Det tillgängliga materialet fastställer dock inte oberoende vem som drev repositoryt, så dess existens ska inte ses som bevis för attribution.

Vad incidenten betyder för Broadcom

Broadcom-aktien föll omkring 5–6 procent den 14 augusti när rapporter om aktiv exploatering av VMware nådde investerare. En rapport beskrev en nedgång från 417,82 till 392,99 dollar under handelsdagen.

Säkerhetsrapporterna var en faktor bakom nedgången, men sannolikt inte den enda. Samtida rapportering tog även upp bredare farhågor, bland annat skuldsättning kopplad till AI-satsningar. Det går därför inte att tillskriva hela kursrörelsen eller ett exakt förlorat börsvärde till CVE-2026-59310.

Det finns inte tillräckligt med belägg för att slå fast att kampanjen redan har lett till en mätbar intäktsminskning för VMware. De mest stödjande kortsiktiga affärseffekterna är kostnader för kundernas åtgärder, risk för driftstörningar och ökat anseendetryck. Eventuella långsiktiga intäktseffekter kräver bolagsuppgifter eller ytterligare finansiella bevis.

Rekommenderad åtgärd för vCenter-administratörer

Patchning är första steget, inte det sista. Organisationer bör:

1. Installera Broadcoms korrigerade versioner omedelbart på alla berörda vCenter-instanser. Prioritera internetexponerade system och appliance-system som kan nås från breda interna nätverk. Broadcom anger ingen workaround.
2. Utgå från att system är komprometterade när indikatorer finns, till exempel oväntade cron-förändringar, reverse-SSH-spår, linuxFile, oförklarliga nedladdningar via curl eller wget, okända vCenter- eller ESXi-administratörer och avvikande aktivitet i VMware Directory Service.
3. Isolera misstänkta appliance-system och säkra diskavbildningar, loggar och flyktiga bevis innan ominstallation, när det är praktiskt möjligt.
4. Byt alla privilegierade autentiseringsuppgifter, inklusive för vCenter SSO, VMware Directory Service, ESXi eller root, API:er, tjänstekonton och länkade administratörskonton. Ogiltigförklara aktiva sessioner och granska federerade åtkomstvägar.
5. Bygg om system i stället för att bara ”städa” dem när beständighet har bekräftats. Ta bort obehöriga konton, cron-jobb, binärer, SSH-nycklar och tunnlar som en del av en dokumenterad incidenthantering.
6. Jaga efter tecken i hela den virtuella infrastrukturen, bland annat .babyk-aktivitet, oväntade utgående SSH- eller WebSocket-anslutningar, falska konton och tecken på manipulation av ESXi-loggar.
7. Återställ betrodd telemetri och data från kända, rena och oföränderliga säkerhetskopior när loggar eller konfigurationer har ändrats.
8. Minska framtida exponering genom att begränsa vCenter-administration till segmenterade administrationsnät och övervaka utgående anslutningar från vCenter och ESXi-värdar.

Den operativa slutsatsen är enkel: uppdatera alla sårbara vCenter-system, men likställ inte en lyckad patchning med en ren miljö. Kombinationen av snabb exploatering, beständig reverse SSH och rapporterat missbruk av autentiseringsuppgifter innebär att exponerade appliance-system bör utredas som potentiellt helt komprometterade.