Si administrás VMware ESX, hay un número de compilación que importa más que el puntaje de esta falla, y conviene empezar por ahí: en la rama 8.0 la versión que corrige es ESXi80U3j-25429389. Y acá está la trampa: otra falla del mismo aviso, puntuada 7,6, se corrige en ESXi80U3i-25205845, que es anterior. Quien en agosto parcheó por severidad y se quedó en la U3i dejó esta abierta.
Lo que hace la falla no es dar acceso. Es, en palabras de Broadcom, que "un administrador malicioso podría explotar este problema para realizar ciertas operaciones sin que queden registradas".
Y lo que la vuelve noticia: Broadcom la evaluó en el rango de severidad baja, con un CVSS 2,7 sobre 10, y CISA la sumó al catálogo de vulnerabilidades explotadas el 28 de octubre, 90 días después de que se publicara el CVE. Un 2,7 es exactamente el tipo de número que ningún proceso de priorización atiende.
Las cinco fallas del aviso VMSA-2026-0006, y cuáles terminaron explotadas
El aviso VMSA-2026-0006 se publicó el 29 de julio de 2026 —hace 92 días— y se actualizó el 19 de agosto. Cubre cinco CVE con un rango de puntajes de 2,7 a 9,8, y Broadcom le pone severidad global "crítica" por el extremo de arriba.
De esas cinco, dos terminaron en el catálogo de explotadas: CVE-2026-59310, un 9,8 en vCenter que además está marcada como usada en campañas de ransomware, y CVE-2026-41709, el 2,7 del registro. Las otras tres, incluido el otro 9,8 y un 9,3, no están. Entre un alta y la otra pasaron 71 días: la del 9,8 entró el 18 de agosto y la del 2,7 el 28 de octubre.
Y CISA también diferenció al fijar los plazos: a la del 9,8 le dio 3 días para parchear y a esta le dio 14. O sea que el catálogo trata las dos como explotadas pero no como igual de urgentes, lo cual es razonable y conviene tener presente al leer un plazo.
No saco de esto que el puntaje no sirva. Saco algo más chico y más útil: el puntaje ordena el daño que hace una falla sola, y no predice cuáles va a usar un atacante. Es el mismo encuadre que la medición del lunes sobre quién calcula los puntajes, visto desde el otro lado.
Por qué un 2,7 termina en el catálogo de fallas explotadas
El vector que publicó Broadcom explica el número: AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N. Lo que más pesa es el PR:H, privilegios altos requeridos, y el C:N, sin impacto en confidencialidad. Visto como falla aislada, es correcto: no da acceso, no roba datos, y hace falta ser administrador para usarla.
El problema es que "hace falta ser administrador" no es una barrera cuando el atacante ya es administrador. Y en ESX hay varias maneras de llegar a eso, incluidas otras entradas del mismo catálogo. Para alguien que ya entró, esta falla no suma acceso: suma silencio.
Ahí está la razón de que un 2,7 sea valioso para un atacante y casi invisible para un proceso de priorización. CVSS mide el daño de la falla; esta falla no hace daño, tapa el daño de otra cosa.
Un dato que ubica lo inusual del caso: de las 1762 entradas del catálogo, solo 102 mencionan "admin" en su descripción, un 5,8%. La mayoría de lo que CISA cataloga son cosas que te dan la entrada, no cosas que usás después.
En la rama 8.0, el parche del 7,6 deja la falla del 2,7 abierta
Esto es lo más concreto de la nota y lo que puede ahorrarle una sorpresa a alguien. En las ramas 9.0 y 9.1, la misma compilación corrige las dos fallas y no hay nada que pensar. En la rama 8.0 y en Cloud Foundation 5.x, no:
- La lectura fuera de rango de 7,6 se corrige en ESXi80U3i-25205845 y en 5.2.3.
- El registro insuficiente de 2,7 se corrige en ESXi80U3j-25429389 y en 5.2.4.
Es decir que la falla de puntaje bajo pide una compilación posterior. Un equipo que en agosto leyó el aviso, ordenó por severidad y aplicó lo necesario para el 7,6 quedó cubierto de esa y expuesto a la que CISA considera explotada. No es un error de nadie: es lo que pasa cuando el orden de trabajo lo fija el puntaje.
Es el mismo patrón que encontré con los tres parches sucesivos del orquestador de Arista, donde cada versión correctora quedaba por debajo de la siguiente. Broadcom aclara además dos cosas: los parches son acumulativos, y para esta falla no hay solución alternativa.
CVE-2026-41709, la única entrada del catálogo con una falla de registro
Medí el catálogo completo para ubicar el caso, y el resultado es más interesante de lo que esperaba. De las 1762 entradas, CVE-2026-41709 es la única con CWE-778, la clase que describe el registro insuficiente. Y las clases vecinas de la misma familia están en cero: CWE-223, CWE-117 y CWE-779 no tienen ninguna entrada.
Hay dos entradas con CWE-532, información sensible en archivos de registro —una de Windows en marzo de 2025 y una de Samsung en 2023—, pero esa es la falla opuesta: ahí el problema es que el registro guarda demasiado, no que no guarde nada.
Ahora, la honestidad obliga a dos aclaraciones que le bajan el tono al "única":
- En el catálogo hay 195 clases de debilidad distintas y 80 de ellas tienen exactamente una entrada, o sea el 41%. Ser la única de su clase no es, por sí mismo, una rareza estadística.
- Hay 175 entradas sin ninguna clase asignada. Mi conteo es sobre las que sí la tienen, así que no puedo descartar que entre esas 175 haya otro caso de registro.
Lo que sí queda en pie, y es el punto, no es la estadística sino la categoría: el catálogo está lleno de maneras de entrar, y esta es la única anotada cuya debilidad es no ser visto.
El contexto de ESXi: 4 de 7 entradas previas están marcadas por ransomware
Esto importa porque explica para qué sirve una falla de registro. El catálogo tiene 7 entradas de ESX o ESXi, y 4 están marcadas como usadas en campañas de ransomware: las dos de 2021, la de julio de 2024 y una de las tres de marzo de 2025. Es el 57%, contra el 20,5% del catálogo completo —361 de 1762—, o sea unas 2,8 veces la tasa general.
Con 7 entradas la muestra es chiquita y la comparación es un indicio, no una conclusión; lo digo porque con números así es fácil exagerar. Pero la dirección coincide con lo que ya sabe cualquiera que haya visto un incidente: el hipervisor es el objetivo, porque cifrar ahí apaga todas las máquinas virtuales de una vez. El caso de la banda que usó un asistente de IA para planear intrusiones y el de las cuatro fallas críticas que incluyeron vCenter van en la misma línea.
En una plataforma así, una falla que impide que queden registradas ciertas operaciones de administrador no es un detalle de cumplimiento: es la diferencia entre reconstruir lo que pasó y no poder.
¿A quién afecta CVE-2026-41709?
Si tenés ESXi en la rama 8.0, sos el caso que más conviene revisar, porque es donde la compilación correctora es distinta de la del resto del aviso.
Si tenés ESXi 9.0 o 9.1, la misma compilación que cubre lo demás cubre esto, así que probablemente ya estés bien si parcheaste en agosto. Verificá el número igual.
Si tenés VMware Cloud Foundation 5.x, la versión es la 5.2.4, una por encima de la que corrige el 7,6.
Si tenés Telco Cloud Platform con ESX 5.0.x o 5.1.x, Broadcom remite a un artículo de su base de conocimiento, el KB449886, en lugar de dar un número de versión.
Si tercerizás la virtualización, no te toca parchear pero sí preguntar, y la pregunta útil es la compilación exacta: no "¿están al día con el VMSA de julio?" sino "¿en qué build de ESXi estamos?". Cómo se piden esas respuestas por escrito está en cómo responder un cuestionario de seguridad de un cliente.
Si no tenés VMware, esto no te toca, y el párrafo que sí te sirve es el de por qué un 2,7 puede ser importante: aplica a cualquier catálogo de parches que ordenes por puntaje.
¿Quién puede ignorar el plazo del 11 de noviembre?
El plazo del 11 de noviembre —14 días desde el alta— obliga a las agencias federales civiles de Estados Unidos por la directiva que cita el catálogo, y no a una PyME de la región.
Quien no tenga ESX en ninguna versión puede cerrar la página. Y quien ya esté en las compilaciones de arriba, también.
Lo que no corresponde concluir es que un atacante use esto para entrar: no sirve para eso, y decirlo sería exagerar el aviso. La falla pide privilegios de administrador. Lo que corresponde concluir es lo otro, que es más incómodo: si CISA la cataloga como explotada, hay alguien que ya tenía esos privilegios y la usó para no dejar rastro.
¿Cómo sé en qué compilación de ESXi estoy?
El número que importa es la build, no la versión mayor:
- En la interfaz web del host, la pantalla de resumen muestra la versión y el número de compilación.
- Por línea de comandos en el host:
vmware -vdevuelve versión y build. - Desde vCenter, la columna de versión del inventario de hosts lo muestra para todos juntos, que es la forma práctica si tenés más de un par.
Compará ese número contra la tabla de arriba, no contra la memoria de la última ventana de mantenimiento.
Y una consecuencia para la respuesta a incidentes que conviene tener presente: si el host estuvo en una compilación anterior, el registro de ese período no es una fuente confiable para descartar actividad. No prueba que algo pasó, pero deja de servir como prueba de que no pasó. Es la diferencia entre registrar y detectar, y está desarrollada en cuándo se justifica un EDR en una PyME y en la categoría de antivirus y EDR.
¿Qué hago si tengo ESXi en una compilación anterior?
En este orden:
- Mirá la build exacta de cada host y comparala con la tabla. En 8.0 el objetivo es ESXi80U3j-25429389.
- Aplicá el parche. Broadcom dice que no hay solución alternativa para esta falla, así que no hay un ajuste de configuración que la tape mientras tanto.
- Aprovechá que los parches son acumulativos: la compilación que corrige esto trae también lo anterior del mismo aviso, incluidas las dos de 9,8 en vCenter si te corresponden.
- Revisá quién tiene credenciales de administrador en los hosts y sacá las que no se usan. Es la precondición de la falla, y es lo único que la limita.
- Si tenés sospecha de compromiso previo, no uses solo el log del host para descartarlo. Cruzá con lo que vea la red y con los registros de vCenter, que son otro sistema.
El encuadre general de qué pedirle a la infraestructura de una PyME está en la guía de ciberseguridad para PyMEs de LATAM.
Una aclaración sobre las fuentes y sobre los límites de lo que medí. Lo que sí pude leer: el aviso VMSA-2026-0006 de Broadcom en su revisión .2, del 19 de agosto, publicado inicialmente el 29 de julio, de donde salen las cinco CVE, los puntajes, las descripciones, la matriz de respuesta con las compilaciones correctoras, la ausencia de solución alternativa, el carácter acumulativo de los parches y el crédito del reporte, que es de Ian Barton, de CrowdStrike; la ficha de la API de NVD de CVE-2026-41709, con el puntaje 2,7 y su vector atribuidos a security@vmware.com, y en estado "Undergoing Analysis" sin puntaje propio de NVD; y el feed JSON del catálogo KEV, de donde salen las altas, los plazos y las marcas de ransomware. Lo que es medición propia sobre ese feed, con fecha del 29 de octubre: el conteo de CWE-778 y de su familia, el de clases con una sola entrada, el de entradas sin clase asignada, el de menciones de "admin" y las tasas de ransomware. Lo que no pude verificar: si entre las 175 entradas sin clase asignada hay otra falla de registro, porque esa clasificación no está en el feed; y la fecha exacta en que Broadcom publicó la compilación U3j, porque la matriz da el número pero no su fecha. Lo que no incluyo: no hay indicadores de compromiso publicados en este aviso, así que no hay nada que bloquear ni buscar, y tampoco describo qué operaciones concretas quedan sin registrar.
La otra alta del catálogo de ayer fue CVE-2026-46300, una falla de inicialización en el kernel de Linux relacionada con el procesamiento de entrada de IPsec, con plazo más corto, al 31 de octubre. No la cubro acá para no mezclar dos historias; el antecedente del kernel en el catálogo está en la nota de ayer sobre Brotli y las librerías que vienen abajo.
Preguntas frecuentes sobre CVE-2026-41709 en VMware ESX
¿Un 2,7 puede ser urgente de verdad?
En este caso sí, y el motivo es que el puntaje mide otra cosa. CVSS evalúa el daño que hace una falla por sí sola, y esta por sí sola no hace daño: no da acceso ni expone datos, y requiere privilegios de administrador. Lo que aporta es que ciertas operaciones de ese administrador no queden registradas. Para alguien que ya consiguió esos privilegios por otra vía, eso vale mucho, y es la razón por la que CISA la catalogó como explotada aunque puntúe 2,7. El número no está mal calculado: está midiendo la falla aislada, no lo que habilita.
Parcheé el aviso de julio. ¿Estoy cubierto?
Depende de la rama y de la compilación exacta. En 9.0 y 9.1 la misma compilación corrige todo el aviso. En 8.0 no: la lectura fuera de rango de 7,6 se corrigió en ESXi80U3i-25205845 y esta falla pide ESXi80U3j-25429389, que es posterior. En Cloud Foundation 5.x pasa lo mismo, 5.2.3 contra 5.2.4. Así que si en agosto priorizaste por severidad, conviene mirar la build antes de darlo por cerrado.
¿Esto le sirve a un atacante para entrar a mi ESXi?
No. La falla requiere privilegios de administrador, así que no es una vía de entrada y decir lo contrario sería exagerar el aviso. El punto es el inverso y conviene tenerlo claro: si CISA la considera explotada, significa que hubo atacantes que ya tenían privilegios de administrador en algún ESX y usaron esto para que ciertas operaciones no quedaran en el registro. Lo que corresponde revisar, además del parche, es quién tiene esas credenciales.
Si estuve en una versión vieja, ¿mis logs sirven para descartar un incidente?
Para descartarlo, no del todo, y es la consecuencia práctica más importante de esta falla. Que el registro del host no muestre nada deja de ser prueba de que no pasó nada, porque justamente la falla permite que ciertas operaciones no se registren. No significa que algo haya pasado. Significa que, para ese período, el log del host es una fuente incompleta y hay que cruzarlo con otras: lo que vio la red, los registros de vCenter, los de respaldo.
¿Hay alguna configuración que lo mitigue mientras actualizo?
No. Broadcom dice explícitamente que para esta falla no hay solución alternativa, así que la única salida es la compilación corregida. Lo que sí se puede hacer en el mientras tanto no mitiga la falla pero reduce su precondición: revisar quién tiene credenciales de administrador en los hosts y dar de baja las que no se usen, porque la falla no sirve sin esos privilegios.