U vCenter bez lozinke, pa odatle na sve virtuelne mašine
Broadcom je izdao hitne zakrpe za pet propusta u VMware proizvodima, a dva najteža otvaraju vCenter — mesto sa kojeg se upravlja svim virtuelnim serverima jedne firme. CVE-2026-59309 sedi u servisu koji vCenter koristi za identitete, pa napadač koji mrežno dosegne sistem prolazi prijavu bez ijednog kredencijala. CVE-2026-59310 je propust u vCenter Syslog serveru kroz koji se izvršava proizvoljan kod. Oba nose 9,8 od 10, i za oba nema zaobilaznog rešenja — ili zakrpa, ili glineni golub. Ko uđe u vCenter, ne provaljuje dalje ni u jednu mašinu: nasleđuje ih sve, zajedno sa nalozima, mrežama i skladištima. Treći propust, CVE-2026-47876, ocenjen sa 9,3, probija zid između virtuelne mašine i fizičkog servera na kojem ona radi. Napadaču za to treba administratorsko pravo unutar same virtuelne mašine, ali odatle stiže na host i do svega ostalog što na njemu živi. Ažuriranje VMware Toolsa unutar mašine tu ne pomaže, jer ranjivi deo stoji na strani hosta. Preostala dva propusta su lakša, ali jedan od njih znači da ESX neće zabeležiti pojedine radnje administratora — što posle otežava istragu. Broadcom navodi da za sada nema podataka o zloupotrebi ni objavljenih indikatora napada. Propuste su prijavili Phil Brass i Matt South iz kompanije Atredis Partners. vSphere 7.0 je takođe pogođen, ali je van redovne podrške od oktobra 2025, a verzije 6.5 i 6.7 treba smatrati ranjivim jer se više i ne proveravaju.
U našim firmama se preko iste VMware infrastrukture obično vrte poslovne baze, domen kontroleri, pošta, ERP i rezervne kopije — sistemi koji spolja izgledaju odvojeno, a dele isti upravljački sloj. Zato je vCenter vrednija meta od bilo kog pojedinačnog servera: ne treba ga provaljivati deset puta, dovoljno je jednom. Izloženost ka internetu pogoršava stvar, ali ni interni vCenter nije bezbedan sam po sebi; napadaču koji je već zauzeo jednu radnu stanicu ili VPN nalog ovo je prečica do upravljačkog segmenta. Ako su i backup mašine u istom klasteru, jedan probijeni sloj odnosi i plan B. Prozor za zakrpu je pritom nezgodan, ali podnošljiv: nadogradnja vCentera nakratko obara samo upravljački interfejs, dok virtuelne mašine nastavljaju da rade. Hostovi traže restart, pa se u klasteru mašine sele s jednog na drugi dok se zakrpe ređaju. To je jedno popodne posla naspram scenarija u kojem neko drugi drži sve konce u rukama. A verzije 6.5, 6.7 i 7.0 koje i dalje negde rade nemaju taj izbor — one su prepuštene same sebi.
- Podigni vCenter na 9.1.0.0300, 9.0.2.0100 ili 8.0 U3k; za Cloud Foundation 5.x ide asinhrona zakrpa na 8.0 U3k, a za Telco Cloud postupak iz KB449886
- Hostove podigni na ESXi 9.1.0.0200 (build 25557999), 9.0.2.0100 (build 25595025) ili 8.0 U3k (build 25595708) — ažuriranje VMware Toolsa unutar mašina ne zatvara izlazak iz virtuelne mašine
- Proveri odakle je vCenter uopšte mrežno dostupan i svedi pristup na administratorske stanice ili poseban upravljački segment; to ne uklanja propust, ali smanjuje broj onih koji mogu da ga dodirnu
- Na sistemima koji su bili dostupni iz nepouzdanih segmenata pregledaj nove i izmenjene administratorske naloge, neuobičajene prijave, promene konfiguracije i mrežne veze samog vCentera
- Za grane 7.0, 6.7 i 6.5 planiraj prelazak na podržanu verziju — a dok traje, ne oslanjaj se samo na ESX evidenciju, jer jedan od zakrpljenih propusta pokazuje da ona ne beleži baš sve