Volver al Blog

CVE-2026-32996: el agente de copias dejaba el ticket de administrador escrito en un log

Sala con filas de puestos de trabajo y ordenadores encendidos bajo luz fluorescente

La prueba de concepto de CVE-2026-32996 no desborda una pila ni corrompe memoria. Abre un fichero de texto, busca dentro un identificador con pinta de GUID, lo presenta por una tubería con nombre y ejecuta lo que le digas. Como SYSTEM. El fichero es un log del agente de copias y lo puede leer cualquier usuario del equipo.

El fallo está en cómo el servicio Veeam Endpoint Backup atiende las sesiones elevadas por su tubería gRPC local, \\.\pipe\Veeam\VAW\ServiceConnectionPipe: guarda en caché un principal de administrador asociado a un identificador de sesión que lo elige el cliente y que no queda atado ni al usuario que lo pidió ni a la conexión por la que lo pidió. Y esos identificadores acaban escritos en C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, legible por usuarios normales. El resto es copiar y pegar.

El investigador que lo encontró lo publicó el 14 de septiembre, y al día siguiente subió el ejecutable: se invoca con CVE-2026-32996.exe "whoami > C:\pwned.txt" y devuelve diez líneas por consola. Su frase resume el fallo mejor que cualquier resumen ajeno: «Session UID can be spoofed, as it is not binded to a identity or connection». El NVD lo clasifica como CWE-532, «inserción de información sensible en un fichero de registro», que es exactamente lo que pasó.

Y ahora las tres cosas que, con los avisos delante, no cuadran con lo que se está publicando.

1. La versión que te dicen que mires no es la del agente

Casi toda la cobertura repite la misma frase: «afecta a Veeam Agent para Microsoft Windows 13.0.1.2067 y anteriores». Ese número existe, pero no es una versión del agente: es una compilación de Veeam Backup & Replication. En la tabla oficial de compilaciones del agente no aparece, y no puede aparecer. Si abres tu agente y comparas, no vas a encontrar nada parecido, y ahí es donde se concluye «pues no me afecta».

  • ▸12 de marzo de 2026: sale el servidor 13.0.1.2067 y, el mismo día, el agente 13.0.2.1102. Los dos vulnerables.
  • ▸27 de mayo de 2026: sale el servidor 13.0.2.29 y, el mismo día, el agente 13.0.3.1220. Los dos corregidos. Este es el número que hay que comparar con lo que tienes instalado.
  • ▸Después: la rama 13.0.x va por el agente 13.0.4.1341 (25 de agosto), y el agente suelto —el que no gestiona ningún servidor— por la 13.1.1.700, del 13 de agosto.

Dicho así se ve la simetría: cada compilación del servidor tiene su gemela del agente, publicada el mismo día, con otra numeración. Y conviene repartir la culpa donde toca, porque no es de quien lo copió: el propio aviso del fabricante encabeza la sección con «Affected Deployment Type: Veeam Agent for Microsoft Windows» y a renglón seguido escribe que las vulnerabilidades «affect Veeam Backup & Replication 13.0.1.2067 and all earlier version 13 builds». El aviso induce el error en su primer párrafo. Lo demás fue propagación.

2. El parche del portátil no está en el portátil

Cuando el agente está gestionado —el caso normal en cualquier empresa con un servidor de copias—, la vía soportada para llevarlo a la compilación corregida es actualizar Veeam Backup & Replication a 13.0.2.29 o posterior, que trae consigo la 13.0.3.1220 para los agentes; luego hay que lanzar esa actualización desde la consola, no llega sola. O sea: el parche de doscientos puestos de usuario cuelga de la ventana de cambio del servidor de copias.

Y el servidor de copias es, con diferencia, la máquina que menos ganas tiene nadie de tocar: hay trabajos en marcha, la ventana nocturna es sagrada y si algo sale mal te quedas sin la red de seguridad justo el día que la necesitas. Resultado: una escalada local de un portátil hereda el calendario del sistema más conservador de la casa. Cuando alguien se pregunta por qué un parche publicado en mayo sigue sin aplicar en septiembre, la respuesta casi nunca es «se nos olvidó»; es esta dependencia, que está escrita en los avisos técnicos pero no en el inventario de nadie.

Es el mismo patrón que ya comentamos cuando Acronis documentó que su agente «requiere acceso local»: el software de copias vive con privilegio máximo en el 100 % del parque, precisamente porque tiene que leerlo todo, y eso lo convierte en la superficie más privilegiada y más ubicua que administras. Lo mismo que pasa con un servidor de impresión: corre como SYSTEM y nadie lo tiene en la lista de joyas de la corona. La diferencia es que el de copias está en todas partes.

3. «Explotación activa»: qué sostiene esa frase hoy

Lo de «crítica» se despacha rápido: el fabricante la clasifica como alta, con 7,3 en CVSS v4.0 y vector AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, reportada por Alibaba a través de HackerOne. La L inicial es la que manda: hay que estar ya dentro de la máquina.

Lo de «explotación activa» es más interesante, porque se puede reconstruir entero. El 16 de septiembre, el proveedor de detección gestionada Arctic Wolf publicó un boletín titulado «UPDATE: Active Exploitation CVE-2026-32996». El cuerpo de ese boletín no afirmaba explotación en el mundo real. Decía esto, y solo esto: «On September 14, 2026, public technical details and proof-of-concept (PoC) exploit code were released for CVE-2026-32996, increasing the likelihood of exploitation attempts against affected Veeam Agent for Microsoft Windows deployments». Eso es una frase de probabilidad. «Aumenta la probabilidad de intentos» no es «lo están explotando».

Lo único que decía «explotación activa» era el titular. Y el titular es lo que viajó. Una semana después, el 22 de septiembre, la cobertura ya lo había convertido en observación —hay publicaciones que escriben que los investigadores «confirmaron que hay actores explotando el fallo»—, que es exactamente lo que el cuerpo del boletín no decía. Al cabo de unos días, Arctic Wolf retiró la pieza: el 28 de septiembre de 2026 esa dirección no devuelve el artículo, devuelve el listado del blog.

Las dos fuentes que siguen en pie y que se pueden consultar hoy dicen lo mismo que el cuerpo del boletín, no que su titular. El aviso del fabricante no menciona explotación en ningún punto. Y el registro del NVD lleva la decisión SSVC de la propia CISA, con fecha del 28 de mayo de 2026: exploitation: poc —prueba de concepto, no explotación activa—, automatable: no y technicalImpact: total. Y el catálogo de vulnerabilidades explotadas conocidas de CISA, versión 2026.09.27, con 1.728 entradas, no incluye esta CVE. Lo hemos descargado y buscado hoy.

Nada de esto es una excusa: parchea igual. Hay exploit público, funciona y el privilegio que entrega es el máximo. Lo que no conviene es que la decisión la tome un titular, porque el mismo titular que hoy te mueve a ti mañana mueve a otro por algo que no lo merece, y al tercer susto ya no corre nadie. La urgencia se justifica sola con lo que hay: exploit público desde mediados de septiembre, trivial de usar, sin mitigación soportada por el fabricante.

Por qué no funciona en todas las máquinas

En el vector hay una letra que casi nadie comenta: AT:P. En CVSS v4 significa, literalmente, que el ataque está «conditioned on execution conditions that are not under full control of the attacker». Y el propio exploit lo confirma sin querer: primero busca un GUID válido en el log. Si en ese equipo nunca se abrió una sesión elevada del agente, no hay identificador que robar. Lo cual reduce el número de máquinas donde funciona a la primera y no reduce ni un gramo el daño en las que sí — y un atacante que ya está dentro tiene tiempo de esperar a que alguien eleve.

Eso da una priorización que no es la de la hoja de cálculo. El boletín retirado ya recomendaba priorizar por rol —«systems used by administrators, backup operators, help desk personnel, or other privileged users»— y el consejo es bueno. Nosotros añadimos un paso, y es el que de verdad decide: no priorices por rol, prioriza por evidencia. Abre el log y mira si hay GUID dentro. El rol te dice quién debería haber elevado; el log te dice en qué máquina se elevó de verdad, incluida aquella en la que nadie recuerda haberlo hecho. Así ordenamos el mantenimiento del parque cuando sale algo de este tipo: no por inventario alfabético ni por organigrama, por lo que hay escrito en el disco.

Qué haríamos esta semana

  • 1Inventario de la versión del agente, no de la del servidor. El número que importa es si estás por debajo de 13.0.3.1220. Si la respuesta a «¿qué compilación del agente hay en ese portátil?» tarda más de cinco minutos, ese es el hallazgo del día, no la CVE.
  • 2Mira el log. C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, en un puñado de equipos representativos. Si contiene GUID de sesión, ahí había material que robar. Es una comprobación de treinta segundos y te dice si el problema es teórico o concreto.
  • 3Planifica el servidor antes que los puestos. Si vas a actualizar doscientos agentes gestionados, lo primero del calendario es la ventana de Veeam Backup & Replication. Ponla con fecha esta semana o asume por escrito que los puestos siguen sin parchear; lo que no vale es dejarlo implícito.
  • 4Deja la detección puesta aunque parchees. La recomendación que circula —limitar el acceso interactivo, revisar permisos locales, acotar los derechos de operador de copias y de administrador, y vigilar el servicio, sus ficheros de log y los procesos hijos inesperados lanzados con SYSTEM— es buena y sigue valiendo después del parche. Un servicio de copias engendrando cmd.exe es una regla de EDR/MDR que debería existir con o sin esta CVE.

Lo que no afirmamos

  • ✗No decimos que no se esté explotando. Decimos que ninguna fuente primaria en pie lo afirma, que el catálogo de CISA no la recoge y que quien lo tituló así retiró la pieza. Que no haya constancia pública no significa que no ocurra: significa que no lo sabemos, y que quien diga que sí lo sabe tiene que enseñar de dónde.
  • ✗No hemos ejecutado el exploit contra un sistema. La mecánica que describimos sale del aviso del fabricante y del análisis publicado por quien encontró el fallo, no de una prueba nuestra en laboratorio.

Cuándo esto no va contigo

Si no usas Veeam Agent para Windows, no va contigo y puedes cerrar la pestaña. Si lo usas pero ya vas por la rama 13.1 del agente suelto, tampoco: estás por encima de la corregida. Y si eres seis personas con seis portátiles y el agente lo instaló y actualizó la misma persona hace dos semanas, esto son diez minutos de comprobar una versión, no un proyecto.

Lo decimos sabiendo de qué lado cobramos: vendemos mantenimiento de parque y servicios gestionados, así que un post que acaba en «hay que inventariar versiones» nos favorece. Por eso conviene el contrapeso: si ya tienes una herramienta que te dice en un clic qué compilación del agente corre en cada máquina, ya has hecho la parte difícil y no necesitas a nadie. La que no la tiene es la empresa que descubre la respuesta abriendo equipos de uno en uno, y esa sí tiene un problema que no es esta CVE.

Fuentes (verificadas el 28 de septiembre de 2026): descripción del fallo, severidad alta, 7,3 en CVSS v4.0, vector completo, crédito a Alibaba vía HackerOne, corrección a partir de 13.0.2.29 y la propia frase que induce la confusión de versiones — Veeam KB4852, «Vulnerabilities Resolved in Veeam Backup & Replication 13.0.2» (publicado el 27-05-2026, última modificación el 17-08-2026); tabla oficial de compilaciones del agente con sus fechas —13.0.2.1102 el 12-03-2026, 13.0.3.1220 el 27-05-2026, 13.1.1.700 el 13-08-2026 y 13.0.4.1341 el 25-08-2026— y ausencia de 13.0.1.2067 como compilación de agente — Veeam KB2683; fechas de las compilaciones de servidor — Veeam KB4738; análisis técnico original, cita sobre el identificador de sesión y correspondencia servidor/agente — suce, «CVE-2026-32996 Veeam Agent Local Privilege Escalation» (14-09-2026, actualizado el 15-09-2026), con el repositorio creado el 15-09-2026 (fecha tomada de la API de GitHub); CWE-532, puntuación y decisión SSVC de CISA (exploitation: poc, automatable: no, technicalImpact: total, 28-05-2026) — registro del NVD, consultado vía API; ausencia del catálogo KEV de CISA (versión 2026.09.27, 1.728 entradas), JSON descargado y buscado hoy; definición de AT:P — especificación CVSS v4.0 de FIRST. El boletín de Arctic Wolf del 16-09-2026 (título, cuerpo y recomendación de priorizar por rol) se cita desde una copia archivada: la dirección original ya no devuelve el artículo.

¿Sabes qué compilación del agente de copias corre en cada máquina?

Inventariamos versiones de agente en todo el parque, priorizamos por dónde hay sesiones elevadas y planificamos la ventana del servidor de copias antes de tocar los puestos.

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