vCenter és la sala de control de la teva virtualització: des d'allà s'encén, s'apaga, es mou, es clona i s'esborra tot. El 29 de juliol Broadcom va publicar VMSA-2026-0006 i, entre les cinc fallades que corregeix, n'hi ha dues de CVSS 9,8 que permeten entrar en aquesta sala sense credencials i una de 9,3 que permet saltar des de dins d'una màquina virtual cap al servidor que l'executa. La resposta del mateix avís a «hi ha workarounds?» és d'una sola paraula: no.
Operem VMware i Proxmox en producció, hem migrat empreses de VMware a Proxmox i també hem recomanat quedar-se on eren quan tenia sentit. No som resellers de cap de les dues ni venem llicències, així que aquest post no va d'aprofitar l'ensurt. Va de quatre coses concretes: què hi ha dins de l'avís, en quin ordre s'aplica —que ha canviat—, on són els pedaços si et vas quedar amb llicència perpètua i sense suport, i la cinquena fallada de la llista, aquella que no sortirà a cap titular perquè amb prou feines puntua.
Les cinc fallades, sense adorns
Un apunt de precisió, perquè importa: l'avís diu que les puntuacions del lot van de 2,7 a 9,8 amb CVSS 3.1, i confirma explícitament el 2,7 de
Abans de discutir la finestra de manteniment
La conversa d'aquesta setmana a moltes empreses serà la de sempre: «no tinc finestra». Val la pena separar les dues meitats de la feina, perquè no costen el mateix ni de bon tros.
- vCenter no atura les teves càrregues. Ho diu el mateix document de preguntes i respostes: actualitzar vCenter no afecta les màquines virtuals ni els contenidors en marxa; perds el vSphere Client —i la resta de vies de gestió— una estona. És a dir, la part on hi ha els dos 9,8 és la barata.
- ESX sí que exigeix reiniciar l'amfitrió. Aquí hi ha la feina de debò: vMotion per buidar cada host, reinici escalonat («rolling reboot») pel clúster i apagada de les màquines que no puguin migrar en calent. Si tens un clúster sense marge de recursos, aquest és el teu coll d'ampolla real, no el pedaç.
- Live Patch serveix aquí. Aquestes actualitzacions d'ESX són compatibles amb Live Patch si el teu entorn ho admet —està disponible des d'ESX 8.0.3, convé confirmar-ho a les notes de versió i compte amb els amfitrions que usen TPM: només són elegibles a partir de VCF 9.1—, cosa que segons Broadcom pot fer el procés «diversos ordres de magnitud» més ràpid. El Quick Patch de vCenter, en canvi, no està disponible per a aquests pedaços: aquí toca el mètode tradicional o RDU si el tens muntat.
Traduït: la finestra que necessites per tapar les dues fallades més greus és molt més petita del que suposarà el comitè que l'ha d'aprovar. Val la pena dir-ho en aquests termes abans que la reunió derivi.
L'ordre que et sabies ja no és l'únic
Aquí hi ha la part de l'avís que gairebé no s'ha explicat. La regla clàssica era vCenter primer, amfitrions després. Broadcom reconeix ara que aquell requisit ha anat evolucionant i que sovint es pot actualitzar ESX abans que vCenter sense problemes; la comprovació es fa a la matriu d'interoperabilitat de producte, creuant la teva versió de vCenter amb la d'ESX (i amb vSAN, si l'uses).
Les dues estratègies que planteja el mateix avís:
· Si tens molts amfitrions: declara canvi d'emergència, actualitza vCenter primer i després pedaça clústers en paral·lel sense interrupció.
· Si no pots reiniciar vCenter fins al cap de setmana: comença ja pels amfitrions ESX, que són compatibles amb un vCenter en versió anterior. Això sí, acaba o atura el pedaçat d'amfitrions abans de tocar i reiniciar vCenter.
El que és valuós d'aquestes dues frases no és l'ordre en si: és que deixen sense argument qui pensava aparcar l'avís fins al setembre. Els pedaços, a més, són acumulatius i no requereixen aplicar res previ, així que no hi ha una cadena de prerequisits per negociar.
Una advertència que sí que convé llegir sencera si estàs a mig projecte: aquestes actualitzacions de vSphere 8.0 i 9.0 provoquen una restricció «back in time» que bloqueja l'actualització a VMware Cloud Foundation 9.x. Si tenies aquella migració en marxa, cal decidir amb calendari a la mà; la compatibilitat es restableix en versions posteriors, com en restriccions anteriors del mateix tipus.
La fuga de VM i una temptació que convé evitar
La temptació, per a qui no pot pedaçar ja, és canviar l'adaptador virtual: les VM amb un altre tipus de targeta no estan afectades per aquella fallada. L'avís ho desaconsella amb dues raons que compartim: els adaptadors no paravirtualitzats com
La fallada que ningú no mirarà
El cinquè de la llista és
El CVSS puntua l'impacte sobre la confidencialitat, la integritat i la disponibilitat del sistema. No puntua —perquè no és la seva feina— la teva capacitat de reconstruir després què va passar. Una fallada de registre no et tira res a terra: et treu el testimoni. I encadenada amb les altres quatre canvia de mida. Si algú entra per un dels 9,8 i acaba operant com a administrador, aquest 2,7 decideix si el teu informe posterior diu «això és el que va fer» o «això és el que creiem que va fer».
Ja en vam escriure fa poc a propòsit d'un altre fabricant: aplicar el pedaç no fa fora qui ja era a dins. Aquí hi ha una volta més, perquè el que es degrada no és el sistema sinó la prova. I les proves ja no són un assumpte intern: quan toca notificar un incident sota NIS2, o quan el client gran envia el seu qüestionari de proveïdor, el que et demanen són fets amb hora, no impressions.
La nostra regla quan un avís inclou una fallada de registre és curta: pedaçar, marcar el període de registres anterior al pedaç com a poc fiable i no acceptar un «no s'hi veu res estrany» d'aquell període com si fos una revisió neta. Un registre incomplet no és un registre tranquil·litzador; és un registre incomplet.
Si el teu vSphere és antic, o ja no pagues suport
És la situació de molta gent després dels canvis de llicenciament dels últims dos anys, i és on l'avís té la informació més útil:
- vSphere 6.5 i 6.7: Broadcom no avalua productes passada la data de fi de suport general, així que no apareixen a la matriu. La instrucció és assumir que estan afectats.
- vSphere 7: afectat. Va arribar a fi de suport general el 2 d'octubre del 2025; si tens contracte de suport estès, els pedaços es demanen per aquella via.
- vSphere 8: les actualitzacions de seguretat es construeixen sobre Update 3. No és imprescindible ser a U3 per rebre el pedaç, però és la versió sobre la qual Broadcom recomana estar.
- Llicència perpètua i contracte de suport caducat: tens dret al pedaç igualment. Des del compromís publicat el 15 d'abril del 2024, tots els clients —inclosos els que tenen el suport vençut— accedeixen als pedaços de les alertes crítiques de seguretat de versions suportades de vSphere. Cal crear-se un compte gratuït al portal de suport. És el punt que més gent es perd i justament el que més falta fa a qui es va quedar amb llicències perpètues.
- Sistemes integrats de tercers (VxRail, SimpliVity i similars): no apliquis el pedaç de vSphere pel teu compte. Aquests fabricants controlen el nivell de pedaçat com a part de la seva qualificació; la guia te l'han de donar ells.
Per comprovar en quina versió ets sense barallar-te amb la interfície, la via ràpida és PowerCLI:
El que aquest avís no és
No és un argument per migrar. Ho diem nosaltres, que fa mesos que escrivim sobre l'èxode de VMware que no va acabar de ser-ho i que fem migracions a Proxmox per a qui les necessita. Proxmox publica els seus propis avisos de seguretat i també s'ha de pedaçar, amb els seus reinicis i les seves finestres. Canviar d'hipervisor per un avís de juliol és canviar la feina de lloc, no eliminar-la.
La decisió de plataforma es pren amb un full de càlcul, un inventari i un calendari de renovació al davant, i de vegades la resposta correcta és quedar-se. El que sí que diu aquest avís, sense marge d'interpretació, és més simple: si tens vSphere, aquesta setmana tens feina.
Fonts (verificades): els cinc CVE amb el seu component i el seu efecte, l'absència de workarounds, el caràcter acumulatiu dels pedaços, l'impacte d'actualitzar vCenter i ESX, la compatibilitat amb Live Patch i la no disponibilitat de Quick Patch, el canvi de criteri sobre l'ordre vCenter/ESX amb la matriu d'interoperabilitat, la restricció «back in time» cap a VCF 9.x, el consell de no canviar a e1000 (amb el fins a 40 % de millora d'E/S dels adaptadors paravirtualitzats), la no necessitat d'actualitzar VMware Tools, l'estat de vSphere 6.5/6.7/7/8, l'accés a pedaços crítics per a clients sense suport vigent des del 15 d'abril del 2024 i les ordres de PowerCLI — document oficial «VMSA-2026-0006: Questions & Answers» de Broadcom (29 de juliol del 2026) i l'avís VMSA-2026-0006. Puntuacions CVSS de 9,8 (CVE-2026-59309 i CVE-2026-59310) i 9,3 (CVE-2026-47876), i desglossament per CVE: The Hacker News i SecurityOnline (29 de juliol del 2026); la forquilla 2,7–9,8 del lot i el 2,7 de CVE-2026-41703 a Workstation i Fusion són al document oficial. La lectura de per què una fallada de registre se subestima en ordenar per CVSS, la regla de marcar com a poc fiable el període de registres anterior al pedaç i el criteri sobre la finestra de manteniment són nostres. Imatge: sala de control de missions restaurada (Wikimedia Commons, domini públic).
Qui decideix a la teva empresa què es pedaça primer?
A everyWAN mantenim infraestructura d'altres i portem la part de seguretat d'aquests entorns, així que un avís com aquest no es despatxa reenviant el butlletí del fabricant: és saber quines versions tens, decidir l'ordre amb criteri i deixar per escrit què es va aplicar, quan i què va quedar pendent —que és justament el que et demanaran en un incident o en una auditoria de continuïtat. Operem VMware i Proxmox, i no venem llicències de cap dels dos. Si vols una opinió sense comissió al darrere, explica'ns què tens muntat.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN