Solo lectura en la consola de copias no era solo lectura

En el aviso que Veeam publicó el 6 de octubre, el permiso que hace falta para ejecutar código en el servidor de copias es el de mirar. El rol se llama Backup Viewer, no toca nada, no borra nada, no lanza nada, y es el que se concede sin convocar a nadie porque sirve para comprobar si los trabajos salieron en verde.

El aviso es el KB4934, publicado el 6 de octubre de 2026 junto con Veeam Backup & Replication 12.3.2 P4, build 12.3.2.4934. Trae tres vulnerabilidades. Afectan a la build 12.3.2.4854 y a todas las anteriores de la versión 12; la versión 13, dice el propio aviso, no está afectada. Sin mitigación provisional: no hay apartado de workaround.

Tres fallos, y dos los dispara el mismo rol

Un apunte práctico antes de seguir: dos de los tres identificadores pertenecen a la serie de 2025 y el tercero a la de 2026. Si los buscas por año no te van a salir juntos, y si tu inventario de vulnerabilidades ordena por fecha del identificador, estos tres no van a aparecer en la misma pantalla aunque vengan en el mismo aviso y se arreglen con la misma build.

PR:L es la parte que cambia la conversación

El vector del grave, tal cual lo publica Veeam:

CVE-2025-64393
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Léelo de izquierda a derecha y es una lista de obstáculos que no existen. AV:N, por red. AC:L, sin condiciones de carrera ni configuraciones raras. AT:N, sin requisitos previos. UI:N, nadie tiene que pinchar en nada. Y PR:L: privilegios bajos, no ninguno. Ese es el único peaje, y en las casas que vemos suele estar pagado por adelantado.

La cola del vector es la que normalmente se pasa por alto, y aquí dice algo. Los tres primeros impactos, VC:H/VI:H/VA:H, son del sistema vulnerable: el servidor de copias entero. Los tres siguientes, SC:H/SI:H/SA:H, son la categoría que CVSS 4.0 reserva para los sistemas subsiguientes, es decir, para el impacto que cae fuera del sistema vulnerable. Veeam marca esas tres en alto y ahí se detiene: no dice cuáles son esos sistemas. Quiénes son los ponemos nosotros, porque de una consola de copias cuelgan las credenciales de los hipervisores, las de los repositorios y las de las cabinas.

¿Quién tiene Backup Viewer en tu consola?

Esa es la pregunta del aviso, aunque el aviso no la haga. El rol de solo lectura existe para concederse sin reunión previa, y se le da al que pregunta «¿puedo ver yo si la copia de anoche fue bien?». La respuesta razonable a esa pregunta es que sí.

Los sospechosos habituales, por orden de probabilidad de que estén en tu lista y de que nadie se acuerde: la cuenta con la que el sistema de monitorización lee el estado de los trabajos; el grupo del service desk, para que puedan contestar «sí, hay copia» sin escalar; el consultor de la última auditoría; el proveedor al que se le dio visibilidad durante una migración ya terminada; y la cuenta de alguien que ya no está, todavía dentro de un grupo del directorio que tiene el rol asignado. Ninguna de esas concesiones fue un error cuando se hizo. El aviso del 6 de octubre es lo que las reclasifica.

El 6,1 toca la llave de la caja fuerte

El segundo CVE está puntuado 6,1, media, y es el que nos parece peor explicado por su número. Lo que permite es modificar o borrar la master key de Enterprise Manager. La documentación de Veeam describe ese keyset como un par de claves que encajan: la pública cifra las storage keys en los servidores de copia conectados a Enterprise Manager, y la privada descifra esas storage keys «in case a password for encrypted backup or tape is lost». O sea, es el mecanismo documentado para cuando alguien pierde la contraseña de una copia cifrada.

No vamos a decir que borrar esa clave te deja sin copias, porque no lo sabemos y depende de cuántas contraseñas tengas apuntadas y dónde. Lo que sí decimos es más incómodo de lo que parece: la vía de escape documentada para el día que falle la gestión de contraseñas estaba al alcance de una cuenta de solo lectura, y eso se puntúa 6,1 porque el impacto se mide sobre el producto y no sobre tu capacidad de recuperarte. La acción que sale de aquí, además de parchear, es exportar el keyset a fichero y guardarlo fuera del servidor de copias. Y esto no es idea nuestra: la propia documentación de Veeam lo pide con todas las letras, «It is important to regularly back up your Enterprise Manager keys or save their copies in a safe place».

No hay workaround. Hay una lista

El KB no ofrece mitigación temporal, y es honesto: con una deserialización en un servicio interno no hay regla de cortafuegos que te salve a medias. La build corregida es la 12.3.2.4934 y punto. Pero entre que lees esto y consigues la ventana de cambio para tocar el servidor de copias —que en muchas casas es el que menos se toca, porque funciona y porque nadie quiere ser quien rompa las copias— hay un trabajo que no necesita ventana ninguna: saber quién tiene el rol.

En la consola está en Users and Roles. Si prefieres sacarlo a un fichero y comparar la lista dentro de seis meses, la referencia de PowerShell de Veeam documenta Get-VBRUserRoleAssignment, que devuelve RoleEntity, Role, Type, Name e Id. El resultado son unas pocas líneas de texto, y esas líneas son el inventario que no está en tu plan de recuperación.

Por qué duele más aquí que en otro servidor

Un RCE en un servidor de aplicaciones es un mal día. Un RCE en el servidor de copias es un mal día en el que además pierdes el plan B, porque la máquina comprometida es la que guarda las credenciales con las que se llega a todo lo demás y la que decide qué se retiene y durante cuánto. Lo hemos escrito aquí de varias maneras: cuando el servidor de copias está en el mismo dominio que lo que respalda, la dependencia es circular y no se ve hasta que hace falta; y la inmutabilidad se queda corta si existe un permiso que borra el objeto antes de que el candado cuente. Este aviso añade una tercera vía al mismo sitio, y es la más barata de las tres: una cuenta de lectura.

Tampoco es la primera vez que la superficie de privilegio de esta consola aparece en un aviso: en septiembre ya comentamos un CVE donde lo que se escapaba era un ticket de administrador escrito en un log. Veeam tiene fallos como todo el mundo y los publica con detalle, con vector y build corregida, que es como se hace. Lo que se repite está un piso más abajo: el plano de recuperación acumula privilegio por capas y nadie lo audita con la frecuencia con la que audita el directorio.

El orden en que lo haríamos

Lo que no afirmamos

Con una consola y cuatro cuentas, esto es media mañana y no necesitas a nadie: miras la build, imprimes los roles y programas la subida. Se complica cuando el plano de recuperación lleva años creciendo —un Enterprise Manager heredado, repositorios en tres sitios, un grupo del directorio que nadie recuerda haber creado— y la pregunta «quién puede entrar en la consola de copias» no tiene respuesta escrita en ninguna parte. Ese inventario, y el plan que se construye encima, es exactamente el trabajo de un plan de recuperación ante desastres, y es lo que vendemos, así que cógelo con el conflicto de interés por delante. Si tu gente ya lo tiene mapeado, perfecto y no nos debes nada. Si al leer el punto 2 has pensado «uf», hablémoslo.

Fuentes