Volver al Blog

Veeam: dos críticos en 21 días, y cada uno salva la rama que el otro hunde

Veeam: dos críticos en 21 días, y cada uno salva la rama que el otro hunde

El 7 de octubre escribimos aquí sobre un aviso de Veeam y repetimos, porque lo decía el fabricante, que la rama 13 no estaba afectada. Esa frase duró veinte días. El 27 de octubre Veeam publicó KB4948 con un crítico de 9,1 que afecta a 13.0 y a 13.1, y que repite la misma nota debajo de cada CVE: «Older versions (e.g., 12.x) are not affected». Dos avisos, veintiún días de diferencia, y la cláusula tranquilizadora de cada uno apunta exactamente a la rama que el otro hunde.

No lo contamos como anécdota. Lo contamos porque la lectura habitual de un aviso es «¿me toca o no me toca?», y en octubre la respuesta correcta para un parque de Veeam fue «te toca dos veces, con tres semanas de margen, y por motivos distintos». Quien se quedó en la rama 12 para no comerse los cambios de la 13 se libró del segundo y se comió el primero. Quien subió a la 13 hizo el recorrido inverso. No había una rama a la que quedarse quieto.

Los dos avisos, uno al lado del otro

  KB4934 KB4948
Fecha 6 oct 2026 27 oct 2026
Crítico CVE-2025-64393 — 9,4 CVE-2026-108142 — 9,1
Dónde Mount Service (deserialización insegura) CDP Coordinator Service (salto de autorización)
¿Hace falta cuenta? Sí: rol Backup Viewer No: sin autenticar
Afecta a 12.3.2.4854 y anteriores de la v12 13.1.1.18 y anteriores de 13.1; 13.0.2.29 y anteriores de 13.0
Rama a salvo La 13 La 12.x
Build que corrige 12.3.2 P4 (12.3.2.4934) 13.1.2.57 / 13.0.3.63
Mitigación provisional Ninguna publicada Ninguna publicada

La fila de «mitigación provisional» es la que marca el ritmo. Ninguno de los dos avisos publica un apaño temporal: la única respuesta que ofrece el fabricante es subir de build. Eso convierte un servidor de copias en una pieza que hay que poder parar y actualizar en caliente, dos veces en tres semanas, sin que nadie tenga que pedir permiso por correo a tres departamentos. Si tu ventana de cambios para esa máquina es trimestral, el calendario de octubre no te cabe.

El 9,1 corre más que el 9,4, y el número no lo dice

Si ordenas los dos por puntuación, el de octubre 6 va primero. Si los ordenas por lo que hace falta para dispararlos, el orden se da la vuelta. Los vectores, copiados tal cual:

CVE-2025-64393  (9,4)  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
CVE-2026-108142 (9,1)  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

Las dos letras que importan son PR y AT. PR:L en el de 9,4 significa que el atacante necesita una cuenta con algún privilegio; en ese caso concreto, el rol Backup Viewer, que es el que se reparte para que alguien mire si los trabajos salieron en verde. PR:N en el de 9,1 significa que no necesita ninguna. A cambio, el de 9,1 trae AT:P: hay una condición previa que no controla el atacante. El de 9,4 trae AT:N, sin condiciones.

Esto es lectura nuestra, no del aviso, y conviene decirlo: Veeam no explica cuál es la condición que esconde ese AT:P. Nuestra hipótesis razonable es que tenga que ver con que el servicio de CDP esté levantado y sea alcanzable, pero es una hipótesis y la marcamos como tal. Conviene además rebajar el énfasis: los cuatro CVE de KB4948 llevan AT:P, así que no es un rasgo exclusivo de este. Lo que sí es un hecho del propio vector es la asimetría: el fallo mejor puntuado pide credenciales y el peor puntuado no pide ninguna. Si tu criterio de priorización es «primero los nueve y medio», el 27 de octubre ese criterio te puso el orden al revés.

Del rol Backup Viewer ya escribimos largo en su momento, cuando sostuvimos que solo lectura en la consola de copias no era solo lectura: el peaje de aquel 9,4 era justamente el permiso que más se reparte sin pensarlo. Lo nuevo de este mes es que el 9,1 ni siquiera cobra peaje.

Dónde vive el fallo nuevo: el servicio de CDP

El componente afectado es el Veeam CDP Coordinator Service, que corre en el propio servidor de copias. Su trabajo es hablar con vCenter, repartir las tareas de protección continua y gobernar las piezas que intervienen en ellas. En la tabla de puertos de Veeam aparece con dos entradas que conviene distinguir: el 9509 es local, para que el servicio de backup hable con el coordinador dentro de la misma máquina; el 33034 es el que escucha para que lleguen las conexiones de los proxies de CDP, de los hosts ESXi y de vCenter. El segundo es el que importa aquí. La tabla documenta esos tres orígenes y ningún otro; que cualquier cosa que no sea uno de los tres sobre en ese puerto ya es lectura nuestra, no una recomendación del fabricante.

Y aquí hay un detalle de calendario que cambia el tamaño del problema. Durante años, la protección continua de Veeam fue una función exclusiva de VMware vSphere, construida sobre el filtro de entrada/salida de VMware (VAIO). En la 13.1, publicada el 29 de julio de 2026, Veeam sacó Universal CDP, que mueve la captura de entrada/salida fuera de la API del hipervisor y lleva la protección continua a otras plataformas; la propia página de producto lo resume como «RPO casi cero para cargas Linux con Universal CDP». Dicho de otro modo: el componente donde ha aparecido el fallo sin credenciales es, justo en la rama donde ha aparecido, el que ha dejado de ser cosa solo de quien tiene vSphere.

Lo que el aviso no te dice, que es justo lo que necesitas

El aviso lista builds afectadas y builds que corrigen. Lo que no dice en ningún punto es si el CDP Coordinator Service está levantado y escuchando en toda instalación de la rama 13, o solo donde hay políticas de protección continua configuradas. Esa diferencia es la que separa «esto me afecta a mí» de «esto afecta a otros», y el documento no te deja contestarla. Así que no la contestes leyendo: ve a mirar la máquina. En este orden, y sin saltarte el primero porque creas que te lo sabes:

  • La build exacta, no la rama. «Vamos por la 13» no sirve: la frontera está en 13.1.1.18 y en 13.0.2.29. Sale en Ayuda > Acerca de, en la consola.
  • Si el 33034 escucha en ese servidor, y desde dónde se llega. Un servicio que no escucha no se ataca por red; uno que escucha y acepta media empresa, sí.
  • Quién tiene los roles Backup Viewer y Restore Operator. Son el peaje de los otros fallos del par de avisos.
  • La versión del agente de Linux, que va por su cuenta y tiene su propio CVE en el mismo aviso.
# Windows (servidor de copias)
netstat -ano | findstr ":33034"

# Veeam Software Appliance / Linux
ss -lntp | grep ':33034'

# desde otra maquina: ¿a quien le responde?
nc -zv <servidor-de-copias> 33034

La tercera orden es la que de verdad informa, porque no pregunta qué hay instalado sino quién llega. Si te responde desde el portátil de administración, desde la red de usuarios o desde cualquier sitio que no sea un proxy de CDP, un ESXi o el vCenter, tienes dos trabajos por delante: subir la build y, después, arreglar el motivo por el que ese puerto estaba abierto a quien no debía. El parche tapa este fallo; el alcance de red te deja expuesto al siguiente.

Los otros tres CVE del mismo aviso

KB4948 no trae solo el crítico. Trae dos de severidad media, CVE-2026-108140 y CVE-2026-108141, ambas de 5,9 y con la misma descripción: un usuario autenticado con el rol Restore Operator que además controla el contenido de un recurso NAS respaldado puede escribir ficheros que él controla en una ruta arbitraria del servidor de copias, mediante recorrido de rutas relativas. Esa segunda condición no es menor, y Veeam las puntúa con PR:H, no con PR:L: en su lectura, ese rol cuenta como privilegio alto. Y trae CVE-2026-105477, de 7,3, una escalada local de privilegios en el agente de Veeam para Linux, que afecta a 13.1.1.4 y anteriores de la 13.1 y se corrige en 13.1.2.11.

El rol de los dos medianos merece un apunte. Restore Operator es, por diseño, el permiso que le das a alguien para que pueda recuperar cosas sin ser administrador del servidor de copias; es decir, el permiso del que presume cualquier plan de recuperación bien repartido. Dos de los cuatro fallos de este aviso se disparan desde roles que existen precisamente para no tener que repartir el de administrador. Separar funciones sigue estando bien; lo que no se puede es contarlo como si el rol pequeño fuera inofensivo.

La parte que no arregla ningún parche

Octubre dejó una cosa clara y es más incómoda que cualquiera de los cuatro CVE: el servidor de copias es un objetivo, no un espectador. Tiene su propio ritmo de avisos, sus propios servicios escuchando y sus propios roles repartidos, y nada de eso depende de lo bien que hagas las copias. Es un servidor más, con la particularidad de que es el que tiene que seguir en pie cuando los demás no lo están.

La consecuencia práctica es de aislamiento, y ya la desarrollamos cuando explicamos por qué el servidor de copias dentro del dominio es una dependencia circular: si la máquina que te salva comparte autenticación y red con lo que se ha caído, no te salva. Octubre le añade una capa de calendario: quien necesite el visto bueno de tres departamentos para tocar esa máquina va a llegar tarde al próximo aviso, y habrá un próximo aviso.

En everyWAN esto cae en cumplimiento y continuidad, porque el RTO y el RPO que firmas en un plan dependen de una máquina concreta que alguien tiene que mantener en pie y al día, y en mantenimiento informático, que es donde vive la parte aburrida: el inventario de builds y la cadencia de parcheo. Lo decimos sin adornos, porque es lo que hemos visto: casi nadie tiene escrito en ningún sitio qué build de su software de copias está corriendo hoy, y es el primer dato que pide cualquiera de estos dos avisos.

Y una cosa más, por honestidad: nada de esto dice que Veeam sea peor que el resto. Un fabricante que publica cuatro CVE con vector, builds exactas y fecha está haciendo su trabajo; el silencio sería mucho peor noticia. Lo que octubre demuestra no va de marcas: la estrategia de «me quedo en la versión anterior hasta que la nueva madure» no es una posición defensiva. Es, simplemente, otra apuesta.

Fuentes. CVE-2026-108142, CVE-2026-108140, CVE-2026-108141 y CVE-2026-105477, con sus puntuaciones, builds afectadas, builds corregidas y la frase «Older versions (e.g., 12.x) are not affected» — aviso KB4948 de Veeam, 27-oct-2026. CVE-2025-64393 y la nota de que la v13 no estaba afectada — aviso KB4934 de Veeam, 06-oct-2026. Puertos 9509 y 33034 del CDP Coordinator Service y los orígenes documentados para cada uno — tabla de puertos de la documentación de Veeam. «RPO casi cero para cargas Linux con Universal CDP» — página de producto de Veeam Data Platform 13.1; la fecha de disponibilidad general, el 29 de julio de 2026, está en la nota de prensa de Veeam, no en la página de producto. Que la protección continua fue exclusiva de VMware vSphere hasta la 13.1 y se apoyaba en el filtro VAIO lo documenta Chris Childerhose en la comunidad de Veeam; es una fuente de comunidad (Veeam Legend), no documentación oficial, y así lo señalamos. La lectura comparada de los dos vectores y la hipótesis sobre el AT:P son nuestras y están marcadas como tales en el texto. Dedupe declarado: KB4934 y el rol Backup Viewer los publicamos el 07-10-2026; lo nuevo aquí es KB4948, la simetría entre las dos ramas y el encaje con Universal CDP. Las frases de los avisos se reproducen en su inglés original; la de la página de producto va traducida. Los identificadores, puntuaciones, vectores y builds se reproducen tal cual.

¿Qué build de tu software de copias está corriendo ahora mismo?

Si la respuesta tarda más de un minuto, ese es el hallazgo. Lo revisamos contigo: inventario de builds, qué servicios escuchan y desde dónde, quién tiene cada rol y qué ventana de actualización necesita esa máquina.

Hablar con everyWAN

Etiquetas:

Compartir:

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN