ESXi: el 2,7 que dejamos de quinto era un día cero

Noventa días exactos. El 30 de julio publicamos un triaje del boletín de VMware y dejamos CVE-2026-41709 el quinto de cinco, porque es lo que puntúa: 2,7 sobre 10. Le dedicamos su propia sección y lo llamamos «el fallo que nadie va a mirar»; lo que no hicimos fue moverlo de sitio en la lista. El 28 de octubre CISA lo metió en su catálogo de vulnerabilidades explotadas. Un actor lo estaba usando como día cero.

Este post no va de decir «ya lo avisamos». Va de lo contrario: de las dos cosas que escribimos entonces y que el dato de octubre obliga a corregir. Si solo quieres la parte accionable, salta al entregable del final; son seis comprobaciones y ninguna consiste en parchear.

Qué ha pasado en noventa días

Cuatro fechas y de dónde sale cada una:

Por qué un número bajo no mide tu capacidad de reconstruir después lo que pasó ya está en lo que escribimos el 30 de julio y no lo vamos a repetir aquí. Lo que aquel post no podía saber es lo que viene ahora.

Corrección 1: la ventana dudosa no empieza en la fecha del aviso

En julio dimos una regla corta: parchear, marcar el periodo de registros anterior al parche como poco fiable y no aceptar un «no se ve nada raro» de ese periodo como revisión limpia. La regla sigue siendo buena —dijimos «anterior al parche», sin fecha de inicio—, pero no dijimos en voz alta lo que ahora hay que decir: esa ventana tampoco empieza cuando el fabricante publica. Nosotros la dejamos abierta; mucha gente la cierra por la fecha del aviso.

Un día cero es, por definición, explotación anterior al aviso. CrowdStrike sitúa el uso de este CVE «as late as early 2026» dentro de intrusiones de un informe cuyo periodo de observación arranca el 1 de septiembre de 2025. Seamos precisos con lo que eso permite afirmar y lo que no: el informe no publica una fecha de inicio para la explotación de este CVE en concreto. Lo que sí queda claro es que el boletín de julio no acota nada hacia atrás. Si escribes un informe diciendo «revisado el periodo desde la publicación del aviso», estás acotando por la fecha equivocada.

Ya nos pasó con otro de los CVE de ese mismo boletín: «sin explotación conocida» duró cinco días desde que se publicó. La diferencia es de escala. Allí el desfase se contaba en días; aquí, en el mejor de los casos, en meses.

Corrección 2: sacar los registros de la caja no arregla esto

Hace once días escribimos que los registros tienen que salir de la caja, porque el registro que vive dentro del aparato comprometido es la evidencia menos fiable. Lo mantenemos, y además no sirve de nada aquí.

Syslog remoto, SIEM, almacenamiento inmutable, firma de eventos: todo eso protege el transporte y la custodia de un evento que primero tiene que existir. La descripción de CISA es inequívoca sobre dónde ocurre la cosa: «perform certain operations without being logged». No es un borrado. Es una no-escritura.

Y esa distinción cambia la investigación entera. Un borrado deja rastro: huecos de minutos, numeración de secuencia que salta, un volumen diario que cae. Todo eso se detecta. Una operación que nunca se escribió deja un registro coherente, continuo y completo a la vista. No hay anomalía que buscar, porque no falta nada: nunca estuvo. Es la diferencia entre una página arrancada y una página en blanco.

Y aquí hay que frenar: el texto dice «certain operations», no «todas». Nadie ha publicado cuáles. Eso acota el daño y, a la vez, impide decir qué parte de tu registro vale.

Por qué tardó noventa días (y por qué volverá a pasar)

El catálogo de CISA se llama, literalmente, «vulnerabilidades explotadas conocidas». Conocer exige evidencia. Y la evidencia de este fallo es justo lo que el fallo impide generar. No iba a salir del SIEM de nadie: salió del informe de un proveedor de respuesta a incidentes que estaba leyendo memoria y disco en víctimas reales, no cuadros de mando.

De ahí la tesis: si tu política de parcheo se mueve por lo que está en el catálogo, esta familia de fallos te llegará siempre la última, no por descuido sino por construcción. Los fallos de registro son los que más tardan en demostrarse explotados precisamente porque su efecto es que no se demuestre nada.

Hay un detalle que lo ilustra bien. CISA dio de alta dos CVE el mismo 28 de octubre. Al de ESX le puso plazo el 11 de noviembre: catorce días. Al otro, un fallo del kernel de Linux encadenable para plantar webshells y ejecutar como root, le puso el 31 de octubre: tres días. Los plazos salen de la tabla de la directiva BOD 26-04, del 10 de junio de 2026, construida sobre los mismos factores SSVC que CISA anota en cada ficha. Y los dos están marcados igual en casi todo —explotación «active», automatizable «no»—: lo único que los separa es el impacto técnico, «partial» en el de ESX y «total» en el del kernel. Esa casilla son once días de diferencia.

Y que quede dicho: el 2,7 no está mal puesto. CVSS mide lo que mide, y para entrar por este fallo hay que ser ya administrador (PR:H). Lo que falla es tener una sola cola de trabajo y ordenarla por ese número.

Lo que casi nadie tiene que hacer ahora es parchear

Y ahora la parte rara. El arreglo de este CVE venía en el mismo boletín de julio que los dos 9,8 y la fuga de VM. De hecho, la ficha de CISA apunta a esa misma referencia del portal de Broadcom. Quien aplicó aquel aviso ya lo corrigió, sin saberlo, hace tres meses. Con una salvedad que no es menor: el aviso se revisó dos veces —los parches exprés de ESX y vCenter 8.0 U2f llegaron el 3 de agosto y la guía para 7.0 el 19—, así que «julio» no es la misma fecha para todos tus hosts. De ahí la primera comprobación.

Así que el alta en el catálogo no te crea una tarea de parcheo. Te crea una tarea de evidencia, que es la que nadie tiene en el proceso. Nuestro flujo de parches está lleno de «aplicado / pendiente» y vacío de «qué dejó de ser cierto cuando esto salió a la luz». Eso es lo que se arregla en el comité, no en la ventana de mantenimiento.

Conflicto de interés por delante: el comité mensual que viene ahora es un servicio que facturamos. Es, literalmente, lo que hacemos en el Programa RID: un comité mensual con dueño y fecha donde se revisan riesgos abiertos y, también, los cerrados que han cambiado de significado. La parte de detección y respuesta la cubre la ciberseguridad gestionada. Lo decimos sin adornos: esto no se compra con una herramienta, se sostiene con una reunión que alguien convoca todos los meses.

Seis comprobaciones, ninguna es parchear

Antes de que alguien lo cuente mal en una reunión

Porque la versión alarmista de esto también está circulando, y no se sostiene:

• Para usarlo hay que ser administrador antes (PR:H), así que no es una puerta de entrada. Si nadie alcanzó ese nivel en tus hosts, esto no te ha pasado. Ojo con cómo lo compruebas: eso no lo demuestra el registro del propio ESX, que es justo el que aquí no vale. Lo demuestra el segundo testigo.
• No apaga tu registro. «Certain operations», dice el texto. El resto se sigue escribiendo.
• No es una campaña masiva. CISA lo anota como no automatizable y sin uso conocido en ransomware. Lo documentado para este CVE es espionaje dirigido contra entidades de Estados Unidos, con el sector legal entre los objetivos. El actor, sin embargo, opera también contra Japón, Taiwán y Corea del Sur: la ausencia en un informe no es ausencia en el mundo.
• No es urgente parchear si ya aplicaste el boletín de julio. Si no lo aplicaste, tu problema no es este CVE: son los otros cuatro del mismo lote.

El expediente que alguien firmó en julio

Un boletín se cierra el día que se aplica el parche y, a partir de ahí, nadie vuelve. Noventa días después alguien publica lo que faltaba y el expediente que dábamos por cerrado dice otra cosa. Si tienes vCenter y ESX en producción y ese expediente lo firmó alguien en julio, escríbenos y lo repasamos juntos.

Fuentes (verificadas el 30 de octubre de 2026): la puntuación 2,7, el vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N, la clasificación CWE-778, la fecha de publicación (30-07-2026) y el registro SSVC de CISA del 28-10-2026 (active / no / partial) salen de la ficha de CVE-2026-41709 en NVD, consultada por API. El título oficial, la descripción («perform certain operations without being logged»), el alta el 28-10-2026, el plazo del 11-11-2026 y la marca de ransomware «Unknown» salen del catálogo KEV de CISA, fichero descargado y leído por nosotros. La cita de la explotación como día cero, el actor WARP PANDA, el camino (dispositivos de borde a vCenter) y el periodo de observación 01-09-2025 a 31-08-2026 son del informe del sector legal 2026 de CrowdStrike (28-10-2026). El plazo de tres días del segundo CVE del mismo día (CVE-2026-46300, kernel de Linux) y su encadenamiento para plantar webshells y ejecutar como root están en su propia ficha del catálogo. La tabla de plazos y su construcción sobre factores SSVC son de la directiva BOD 26-04 (10-06-2026), cuya Tabla 1 está publicada como imagen: por eso no citamos literalmente la correspondencia entre casilla y plazo, aunque los dos plazos y los cuatro factores SSVC sí están publicados. Las fechas de revisión del aviso de julio (versión .1 del 03-08-2026 y .2 del 19-08-2026) son del registro de cambios del propio aviso de Broadcom. Los noventa días, la distinción entre página arrancada y página en blanco, la tesis sobre por qué esta familia de fallos llega siempre la última al catálogo, las dos correcciones de nuestros propios posts y las seis comprobaciones son aritmética y lectura nuestras.