Proxmox VE 7: el parche llevaba tres años publicado y nadie sabía que era un parche

Imagina un portero que te pide el DNI y, si le dices «tranquilo, que traigo también el segundo documento», deja de pedirte el primero. No comprueba el segundo. Solo con mencionarlo, se olvida del otro. Eso es, literalmente, lo que hacía el inicio de sesión de Proxmox VE 7: bastaba con enviar un parámetro tfa-challenge con cualquier valor para entrar como root@pam sin contraseña. El código que lo arregla se publicó el 20 de julio de 2023. El aviso llegó el 1 de septiembre de 2026, tres años y seis semanas después, cuando alguien encontró su nodo cifrado.

Qué hace el fallo, sin adornos

La autenticación de Proxmox VE pasa por una única llamada: POST /api2/json/access/ticket. Ahí se envían usuario, contraseña y, si toca, el segundo factor mediante el parámetro tfa-challenge. En las versiones afectadas, para las cuentas sin segundo factor configurado ese parámetro nunca se validaba —no había con qué compararlo— y, además, su simple presencia hacía que se saltara la comprobación de la contraseña. No es que la contraseña se validara mal: es que no se llegaba a mirar.

El resultado es un acceso sin autenticación con el que un atacante se convierte en cualquier usuario existente y habilitado que no tenga segundo factor, root@pam incluido. El paquete vulnerable es libpve-access-control desde la versión 7.0-7 hasta la 8.0.4 sin incluirla; el aviso lo traduce a Proxmox VE 7.0 a 7.4, y el registro del CVE extiende el rango hasta la 8.0 inicial. El CVE es CVE-2023-54391 y el mismo asignador le pone 9,8 en CVSS 3.1 y 9,3 en CVSS 4.0, con el vector completo de red, sin privilegios previos y sin interacción del usuario.

El único requisito para explotarlo es alcanzar la API. Por defecto, el puerto 8006. Quien lo tenga publicado en internet tiene una puerta abierta con el cartel puesto.

El segundo factor te salvaba, y no por el motivo que crees

Aquí está el detalle que le da la vuelta a la intuición. El parámetro que abría la puerta era el del segundo factor, pero el aviso es tajante: «los usuarios con cualquier segundo factor configurado para el inicio de sesión no están afectados». En esas cuentas el tfa-challenge es un tique firmado por el propio servidor y su firma sí se verificaba — exactamente la comprobación que el parche de Proxmox reinserta. La vulnerabilidad vivía justo en el hueco de las cuentas que no lo tenían.

Con una salvedad que conviene no perder de vista: protegía a cada cuenta que lo tuviera, no al nodo. Bastaba con que quedara un solo usuario habilitado sin segundo factor —uno de servicio, uno de monitorización, el que creaste para una integración y nunca borraste— para que la puerta siguiera abierta.

Nos gusta este caso porque cierra una discusión que tenemos cada pocos meses, cuando alguien pregunta si merece la pena poner segundo factor en root@pam de un hipervisor «que solo se toca desde dentro». El argumento de siempre es el robo de contraseñas, y es el más flojo. El bueno es este: el segundo factor es una condición extra que el código tiene que evaluar, y cada condición extra es una rama menos por la que colarse. Aquí acabó protegiendo de un fallo lógico que nadie había visto. Por accidente, que también cuenta.

Tres años entre el arreglo y el aviso

Lo que convierte esto en algo más que un CVE del montón es la cronología, y no la contamos nosotros: está en el aviso. El código vulnerable dejó de existir el 20 de julio de 2023, en libpve-access-control 8.0.4, como efecto secundario de una reelaboración del manejo de la configuración del segundo factor. Nadie lo etiquetó como arreglo de seguridad porque nadie se dio cuenta de que lo era, y por eso —cita literal del aviso— «no se consideró candidato a retroportarse a la rama de PVE 7», que en aquel momento todavía tenía soporte. Los dos commits de aquellos días hablan de leer tfa.cfg y del marcador x en user.cfg. Ninguno menciona contraseñas.

Eso rompe el modelo mental con el que casi todos gestionamos parches: un fallo grave se descubre, se le asigna un CVE, se arregla y el arreglo baja a todas las ramas vivas. Aquí el orden fue el contrario. Y entre medias la rama 7 llegó a su fin de soporte en julio de 2024 —según la tabla de ciclo de vida del propio proyecto, alineada con Debian 11 «Bullseye»—, así que cuando el aviso se publicó ya no había nadie con la obligación de arreglarlo.

Ya escribimos sobre la otra cara de esto cuando le tocó a la rama 8: Debian te sigue parcheando, el hipervisor no. Aquel post iba de una fecha que pasa sin que se rompa nada. Este va del día, meses o años después, en que la ausencia de mantenedor se cobra la factura de golpe.

Cómo se enteró todo el mundo: por un hilo del foro

La secuencia también dice algo. El 31 de agosto un usuario abrió el hilo que puso el problema en el mapa: su instalación de VE 7 había aparecido cifrada, con petición de rescate y los registros borrados. Él mismo apuntaba a una queja anterior, en chino, del día previo. En cuestión de horas se sumaron otros con el mismo cuadro. El 1 de septiembre Proxmox publicó el aviso PSA-2026-00043-1, «Authentication bypass in EOL Proxmox VE 7 release», explicando que había tenido noticia del problema por «múltiples informes independientes en los últimos dos días» que además reportaban explotación activa. Poco después apareció públicamente una prueba de concepto.

El descubrimiento, por tanto, vino de las víctimas. Cuando el primer canal de detección de una vulnerabilidad es el foro de soporte, la ventana entre «alguien lo está usando» y «tú te enteras» ya lleva abierta un tiempo que nadie puede medir.

Lo que se puede afirmar y lo que no

Conviene separar tres niveles de certeza, porque ahora mismo se están mezclando:

• El fallo y las versiones afectadas están confirmados por el fabricante. Eso no admite discusión: lo dice el aviso.
• La explotación activa la afirma Proxmox a partir de los informes que recibió. En cambio, CISA no lo ha incluido en su catálogo KEV: lo hemos comprobado en el fichero de origen, versión 2026.09.02, y ahí no figura CVE-2023-54391 ni ninguna otra entrada de Proxmox. No es una contradicción: son dos umbrales de evidencia distintos, y el de CISA es más lento. Que no esté en el KEV no significa que no esté pasando.
• Los indicadores de compromiso que circulan vienen de la comunidad, no del aviso: un fichero /var/lib/systemd/PVE-1 que resultó ser el minero, los registros del sistema (auth.log, wtmp, btmp, lastlog, secure) sustituidos por enlaces a /dev/null, y conexiones salientes a un pool de minado de Monero. Nos parecen razonables y merece la pena buscarlos, pero hay que tratarlos como lo que son: reportes de afectados, no una lista oficial.

Qué mirar hoy, en este orden

1. Mira la versión del paquete. dpkg -l libpve-access-control. Si el número cae entre 7.0-7 y 8.0.3, ese nodo es explotable. Ojo con el atajo de «menor que 8.0.4»: un PVE 6 con la 6.4-x da un número más bajo y queda fuera del rango afectado. pveversion te da la rama, que ayuda, pero el dato que decide está en el paquete.
2. Quién llega al 8006. ss -tlnp | grep 8006 te dice que escucha; lo que importa es desde dónde se alcanza. Compruébalo desde fuera de tu red, no desde la oficina. Si responde desde internet, cortar ese acceso es lo primero, antes que cualquier otra cosa de esta lista.
3. El registro, con una advertencia. En /var/log/pveproxy/access.log verás las peticiones POST /api2/json/access/ticket y su IP de origen, pero no el parámetro: viaja en el cuerpo, y pveproxy anota la línea de petición al estilo Apache, no los cuerpos. Busca ahí accesos desde direcciones que no reconozcas. Y haz también ls -l /var/log/: en los casos reportados, auth.log, wtmp, btmp, lastlog y secure aparecían sustituidos por enlaces a /dev/null. Si alguno lo es, eso ya es una respuesta.
4. Usuarios y tokens que no pusiste tú. pveum user list y, para cada cuenta, pveum user token list <usuario>@<reino> — por ejemplo, pveum user token list root@pam. Un token de API creado por el atacante sobrevive al cambio de contraseña y a la actualización. Es el residuo que más veces se queda atrás.
5. Las copias, antes de tocar nada. Si el nodo está comprometido y hay que reconstruirlo, lo primero que necesitas es saber si las copias de seguridad son alcanzables desde ese mismo nodo. Si lo son, asume que el atacante también las alcanzaba.

Ese último punto no es retórico. En el informe de ransomware de 2026 desmenuzamos por qué restaurar no es lo mismo que recuperar, y el orden de las operaciones importa: preservar registros y discos antes de reinstalar, porque una vez formateado ya no hay forma de saber qué se llevaron.

El parche de emergencia y por qué lo pondríamos con pinzas

Proxmox publica en el propio aviso un remedio provisional: un sed sobre /usr/share/perl5/PVE/AccessControl.pm que reinserta la verificación del tique del segundo factor, seguido del reinicio de pvedaemon y pveproxy. Es del fabricante, no un apaño de foro, y en un nodo que no puedes actualizar hoy hace su trabajo. Pero quien lo aplique debería tener claras tres cosas: es una modificación local de un fichero de un paquete, que no está bajo /etc y por tanto cualquier reinstalación o salto de rama lo sobrescribe sin preguntar; y no arregla el resto de fallos que la rama 7 no ha recibido desde julio de 2024.

Nuestro orden sería este: primero cerrar el 8006 a internet, que se hace en minutos y elimina el vector; después verificar si el nodo ya está comprometido; y solo entonces planificar la subida de rama. El sed encaja en el hueco entre lo segundo y lo tercero, no en lugar de ninguno de los dos. Y si acabas en la 9, el siguiente paso es dejarla decente: eso lo escribimos entero en hardening de Proxmox 9.2 en producción.

Lo que este caso dice de tu inventario

Montamos y mantenemos esta infraestructura, así que vamos a decir la parte incómoda. Nadie deja un hipervisor cinco años sin tocar por dejadez. Lo deja porque funciona, porque dentro hay tres máquinas virtuales que no se pueden parar, porque la persona que lo montó ya no está, o porque cada vez que se abre el tema alguien pregunta cuánto cuesta y la conversación se acaba ahí. Ese nodo no está en el plan de nadie precisamente porque no da guerra.

Es el mismo patrón que contamos con los BMC e IPMI expuestos, el ordenador que nadie mantiene: la pieza que no aparece en el inventario porque no genera tickets. Y es donde insistimos con una idea que repetimos hasta que cansa: el fallo es inevitable, la avería es una decisión de diseño. Que hubiera un fallo lógico en el inicio de sesión de 2021 no lo decidiste tú. Que ese fallo llegara a producción tres años después de estar arreglado, con la interfaz publicada en internet y sin segundo factor en root@pam, sí es una cadena de decisiones. Todas razonables por separado. Ninguna revisada nunca junta.

Al grano

Entra en cada nodo y ejecuta dpkg -l libpve-access-control. Si sale un número entre 7.0-7 y 8.0.3, eso es trabajo para esta mañana. Después comprueba desde fuera si el 8006 contesta. Con esas dos respuestas ya sabes si esto es una tarea de mantenimiento o un incidente.

Y si el número sale bien, aprovecha el susto para hacer la pregunta que de verdad importa, que no va de este CVE: ¿cuántas máquinas tienes funcionando cuya versión no sabrías decir sin conectarte a mirar? Esas son las que van a salir en el próximo aviso.

Fuentes (consultadas el 4 de septiembre de 2026): la fuente principal es el aviso PSA-2026-00043-1, «Authentication bypass in EOL Proxmox VE 7 release», del 1 de septiembre de 2026, publicado en el hilo de avisos de seguridad de Proxmox VE. De ahí salen, literalmente: el rango del paquete libpve-access-control (de 7.0-7 a antes de 8.0.4) y su traducción a «Proxmox VE 7.0 through 7.4»; que la presencia del parámetro «hacía que la verificación de la contraseña enviada se saltara por completo»; que «los usuarios con cualquier segundo factor configurado para el inicio de sesión no están afectados»; que el fallo se cerró en la 8.0.4, publicada el 2023-07-20, como «efecto secundario de una reelaboración del manejo de la configuración TFA» y que «por tanto no se reconoció como candidato a retroportarse a la rama de PVE 7»; los «múltiples informes independientes en los últimos dos días» con explotación activa; y el remedio provisional con sed sobre AccessControl.pm más el reinicio de pvedaemon y pveproxy. El hilo de usuarios del 31 de agosto es Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth. La prueba de concepto pública y el resumen de explotación — securityonline.info. Los indicadores de compromiso (/var/lib/systemd/PVE-1, los registros del sistema enlazados a /dev/null y el pool de minado) proceden solo del análisis de prepaid-host sobre casos reportados. Puntuaciones CVSS 3.1 de 9,8 y CVSS 4.0 de 9,3, del mismo asignador, y el vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — registro del CVE y IONIX Threat Center. Que CVE-2023-54391 no figura en el catálogo KEV de CISA lo hemos comprobado nosotros descargando known_exploited_vulnerabilities.json de cisa.gov, versión de catálogo 2026.09.02: no aparece esa entrada ni ninguna otra de Proxmox; también lo señala BlackTree. Fin de soporte de Proxmox VE 7 en julio de 2024, alineado con Debian 11 «Bullseye» — tabla de ciclo de vida de Proxmox VE. Matiz importante: los indicadores de compromiso no están en el aviso oficial; conviene usarlos como pistas, no como veredicto.