El CVE de Proxmox que tu escáner no puede evaluar

La pregunta que llega a un equipo de sistemas cuando sale un CVE gordo siempre es la misma: «¿nosotros estamos afectados?». Y la respuesta que suele bastar para cerrar el hilo también: «el escáner dice que no». Hoy hemos ido a ver qué tiene el escáner encima de la mesa para poder decir eso con este CVE concreto. La respuesta corta es que no tiene nada.

Hablamos de CVE-2023-54391, el fallo de autenticación de Proxmox VE del que ya escribimos cuando salió el aviso. Aquel post iba del agujero: en el endpoint de login de la API, mandar cualquier valor en el parámetro tfa-challenge salta entera la verificación de la contraseña para cualquier cuenta sin segundo factor, root@pam incluida. Este va de otra cosa: de por qué, tres semanas después, sigue siendo difícil contestar si tú lo tienes o no.

Lo que devuelve la ficha, campo a campo

Un escáner de vulnerabilidades no sabe nada de Proxmox. Sabe leer una lista de versiones afectadas y compararla con lo que encuentra en tu máquina. Esa lista sale casi siempre de dos sitios: la ficha de NVD y la base de avisos de GitHub. Esta mañana hemos pedido las dos por API. Estos son los campos que importan.

Ese último campo es el que desmonta la comprobación automática. versionType: "custom" significa, literalmente, que no se declara ningún esquema de comparación. Una herramienta lee «afectado hasta 7.4 inclusive», se encuentra un nodo que se presenta como pve-manager/7.4-17 y tiene que decidir sola. Con el orden de versiones de Debian, que es el que aplica a un .deb, 7.4-17 es la revisión 17 del upstream 7.4 y queda por encima de un «7.4» a secas: fuera del rango, nodo en verde. Con reglas tipo semver saldría justo lo contrario, porque ahí el sufijo baja la precedencia y el nodo entraría. Dos herramientas razonables, dos veredictos opuestos sobre la misma máquina. Eso es exactamente lo que significa no declarar el esquema.

Y hay dos silencios más en la misma ficha. El primero ya lo comprobamos el 4 de septiembre: este CVE no estaba en el catálogo KEV de CISA. Hemos vuelto a descargarlo hoy, versión 2026.09.22, y sigue sin estar; tampoco hay ninguna otra entrada de Proxmox en todo el catálogo. Lo nuevo no es la ausencia, es que dure tres semanas. El segundo está dentro del propio registro del NVD: un bloque SSVC firmado por «CISA Coordinator» el 2 de septiembre que marca automatable: yes y technicalImpact: total, y a la vez exploitation: none. Añade el EPSS que devuelve GitHub, 1,75 % en el percentil 76,8, y tienes un 9,8 al que todos los semáforos automáticos dan ámbar.

El parche que sí existe para la rama 7

El arreglo no está en el hipervisor, está en el paquete libpve-access-control, que se numera en otra serie; y en la rama 7 no hay ninguna versión que lo lleve, porque el código se cerró dentro de la 8.0.4 y Proxmox reconoce en su aviso que entonces «no se reconoció como candidato a retroportarse a la rama de PVE 7». Eso ya lo contamos a principios de mes y se comprueba en dos minutos: la rama stable-7 del repositorio público de pve-access-control muere en la 7.4.3, con fecha de febrero de 2024, y los dos commits del arreglo no están ahí.

Lo que casi nadie ha contado, y es la parte útil, es que en ese mismo aviso Proxmox publicó un parche para quien no pueda migrar ya. Es un script corto que añade la validación que faltaba: a partir de ahí todo tfa-challenge tiene que ser un tique firmado y válido, que un atacante no puede fabricar, y ni el login normal ni el de dos factores dejan de funcionar. Aplicarlo a mano no es migrar, y el nodo sigue estando fuera de soporte con lo que eso arrastra. Pero cierra esta puerta hoy, y la migración se planifica en frío en vez de a las dos de la mañana.

Mil cien máquinas, doce hipervisores, diecisiete días

Todo lo anterior sería una discusión de metadatos si no tuviera factura. La tiene, y está publicada. Un proveedor de alojamiento finlandés, Pulsed Media, publicó el 20 de septiembre un aviso contando que una campaña automatizada de minado de criptomoneda había conseguido root en doce de sus hipervisores Proxmox VE. La entrada fue este CVE. La ventana va del 31 de agosto al 17 de septiembre, día en que ellos mismos la detectaron y la cortaron: diecisiete días. Y dan un dato que no habíamos visto en ningún sitio más: «Roughly eleven hundred machines worldwide were in this campaign».

Que lo publicaran con ese detalle es más de lo que hace la mayoría, y por eso este post lleva datos en vez de suposiciones. Su aviso enumera lo que hicieron: quitaron el software malicioso y cada mecanismo de persistencia que identificaron, cerraron la entrada en los doce hosts, restablecieron el registro que el atacante había apagado, rotaron las contraseñas de acceso a los hosts y restringieron la interfaz de gestión de Proxmox a sus propias redes. Los sistemas de contacto, facturación y pagos no se vieron comprometidos.

Conviene leer despacio ese «restablecieron el registro»: volvieron a encender el mecanismo, no recuperaron lo que el atacante ya había borrado. De ahí sale la frase que nos parece la más importante de todo el aviso. No encontraron indicios de que los datos de clientes fueran leídos, copiados o modificados, y a continuación escriben, literal, «the deleted logs mean we cannot prove it either way». Por eso avisaron a los clientes afectados de que trataran sus datos como potencialmente expuestos.

Ahí está el coste real, y no es el de la CPU que alguien te robó para minar. La minería es el ruido. Lo caro es la distancia entre «no pasó nada» y «no puedo demostrar que no pasara nada», porque la segunda es la que se dice delante de un cliente, de una aseguradora o de quien pregunta por el artículo 33. Esa distancia no la decidió el atacante el día del incidente; la decidió, meses antes, quien dejó que los registros vivieran solo en la máquina que los genera. Es el mismo patrón del que ya escribimos por otro camino: parchear el kernel es reiniciar, y reiniciar borra la prueba.

Cuatro comprobaciones, diez minutos por nodo

Para un parque de veinte nodos eso es una mañana, y sale un inventario que sirve para el siguiente aviso y para el de después. Si además vas a migrar esos nodos, las decisiones de acceso y cortafuegos conviene tomarlas durante la migración, no al terminarla: las tenemos ordenadas en nuestra guía de hardening de Proxmox para producción.

Lo que no vamos a recomendarte

Cómo lo montamos nosotros

Cuando el control preventivo no puede responder —y hoy, con este CVE, no puede—, lo que queda es detectar y poder demostrar. Por eso el servicio de EDR y detección gestionada que operamos no termina en el agente instalado: la telemetría y los registros salen del host y se guardan fuera, con retención propia, para que borrarlos en la máquina no borre la respuesta. Y detrás hay gente de guardia, porque la ventana entre que algo pasa y alguien mira es la variable sobre la que de verdad se manda. Diecisiete días es lo que llega a medir esa ventana; nadie la elige, se hereda del turno que se tiene.

«Publicado» no es «aplicado», y «no aparece en el escáner» no es «no me afecta». Lo primero lo contamos con un parche que llevaba 97 días disponible; lo segundo es este post. Son la misma frase dicha dos veces, y las dos veces sale caro por el mismo motivo: el sistema que te avisa no es el mismo que te protege.

Fuentes (consultadas el 23-sep-2026): los campos configurations, vulnStatus, affected y el bloque SSVC los hemos leído en la respuesta de la API 2.0 del NVD (marca de tiempo 2026-09-23T06:32 UTC); el vulnerabilities: [], el type: "unreviewed" y el EPSS, en la API de GitHub Advisories; la ausencia en el catálogo, en el KEV de CISA, versión 2026.09.22. El rango >= 7.0-7 y < 8.0.4, el comando de comprobación, el parche para quien no puede migrar y la frase sobre el retroporte están en el aviso PSA-2026-00043-1 de Proxmox; la rama stable-7 se comprueba en el repositorio público de pve-access-control. El incidente, las fechas, las cifras y las citas literales, en el aviso público de Pulsed Media del 20-sep-2026. Lo que este post NO afirma: no hemos reproducido el ataque ni verificado ningún indicador técnico de compromiso en un laboratorio propio, y la campaña de mil cien máquinas la afirma ese proveedor, no una fuente independiente.