Un fallo de TeamViewer deja que el equipo asistido ataque al técnico

Una pantalla de 32.768 por 32.768 píxeles a 32 bits de color no existe, pero el cliente de TeamViewer anterior a la 15.83 se la cree, reserva unos 4 MB para dibujarla y después escribe en ella como si dispusiera de los 4,3 GB que le corresponden. Con ese desajuste, el equipo que recibe soporte puede colgar el cliente del técnico que se conecta a ayudarle o ejecutar código en su PC, según el informe que Remedio publicó el 29 de octubre de 2026 sobre CVE-2026-111585, un fallo de CVSS 8,8 que TeamViewer corrigió dos días antes en el boletín TV-2026-1011.

• CVE-2026-111585, de CVSS 8,8, afecta a TeamViewer Full Client, Portable y la app Remote Control para Android anteriores a la 15.83, incluida la 15.82 de septiembre.
• El host de la sesión, y no el técnico, es quien ataca. Un mensaje de pantalla con dimensiones imposibles desborda el búfer del viewer que se conecta.
• Remedio demostró ejecución de código en Windows con CFG y DEP activos. A 31 de octubre no hay ataques conocidos ni código de explotación público.
• El parche es la 15.83, y 15.64.10, 14.7.48868 o 13.2.x en ramas heredadas. TeamViewer no ofrece mitigación alternativa.
• Lo urgente es actualizar primero los puestos de helpdesk y de MSP y revisar sus conexiones salientes desde el 29 de octubre.

Un mensaje DisplayParams que el viewer de TeamViewer nunca acota

En una sesión de TeamViewer hay dos papeles. El host comparte su pantalla y el viewer la muestra y devuelve el ratón y el teclado. Omri Dar, investigador principal de vulnerabilidades de Remedio, lo resume en su informe con una frase que le da la vuelta al modelo mental de cualquier helpdesk, «the attacker is the host and the victim is the viewer» (el atacante es el host y la víctima es el viewer). El diagrama de Remedio lo dibuja con dos flechas, la del técnico que se conecta para ayudar y la del fotograma manipulado que vuelve por la misma sesión y acaba ejecutando código en su equipo.

Al arrancar la sesión, el host envía un mensaje DisplayParams con la anchura, la altura y la profundidad de color de la pantalla que va a transmitir. El viewer usa esos tres números para reservar la superficie de decodificación, un objeto llamado CBitmapBuffer en el que se descomprimen las actualizaciones de pantalla antes de pintarlas. Según Remedio, nada en la ruta de recepción limita esos valores. Ese objeto solo entra en juego cuando el viewer carece de decodificador de vídeo por hardware, porque en caso contrario los fotogramas van por AV1 o H.264, pero la elección tampoco depende del viewer. Un host que rechaza negociar los códecs de vídeo fuerza la ruta de mapa de bits y elige un códec de teselas sin pérdida cuyas actualizaciones se decodifican directamente en ese búfer.

El fallo está en la aritmética del constructor. La función calcula el tamaño de cada plano de color en 32 bits, de modo que el producto se desborda y vuelve a empezar desde cero, mientras la anchura y la altura declaradas se guardan sin truncar. Remedio reduce el constructor a estas líneas.

// width, height y bpp_bits llegan del mensaje DisplayParams del host, sin comprobar
stride = (bpp_bits * (width + 0x10)) >> 3;            // se guarda sin truncar
plane.byteSize = (uint32)(stride * (height + 0x10));  // multiplicación de 32 bits, se desborda
buf = operator_new[]( (ulong)(stride * (height + 0x10)) ); // reserva el tamaño desbordado

La tabla recoge las cuentas del informe para una pantalla declarada de 32.768 por 32.768 píxeles a 32 bits por píxel.

Los decodificadores RLE sí comprueban cada rectángulo de actualización, pero contra la anchura y la altura declaradas, nunca contra el tamaño reservado. Un rectángulo que cubra toda la superficie pasa la comprobación y, a partir de la fila 32, cada escritura cae fuera del búfer y pisa lo que haya al lado en el heap. Es la misma familia de desbordamiento de búfer que practicábamos hace años con servidores de laboratorio, con la diferencia de que aquí lo dispara el ordenador al que has ido a ayudar.

Los tres CVE del boletín TV-2026-1011 y quién los encontró

TeamViewer publicó el boletín TV-2026-1011 el 27 de octubre de 2026 y lo actualizó el día 28. Cubre tres fallos, los tres de severidad alta. A las 07:00 UTC del 31 de octubre, NVD tenía los tres registros en estado Awaiting Analysis, con la puntuación enviada por el propio fabricante como CNA y sin valoración propia, y ninguno estaba en KEV, la lista de explotadas de CISA.

La captura del boletín muestra la ficha oficial del fallo. El vector lleva UI:R porque la víctima tiene que aceptar la sesión, y TeamViewer afirma en el mismo documento que «is not aware of any active exploitation in the wild» (no tiene constancia de explotación activa). Remedio tampoco ha visto ataques y no ha publicado código de explotación.

Los otros dos fallos del boletín llevan la firma de los investigadores HeaZzy (Mathys Khalfa) y skav (Antoine Rieul), según el registro CVE de cada uno. CVE-2026-92372, también de 8,8 y con el mismo vector, es una escritura fuera de límites en el decodificador de imagen de pantalla del Full Client y el Host para Linux y macOS, que se dispara con datos de pantalla manipulados durante una sesión o al abrir una grabación de sesión .tvs preparada. CVE-2026-92374, de 7,8, es una condición de carrera con enlaces simbólicos en el ayudante privilegiado de la versión para macOS que permite a un usuario local sin privilegios instalar un paquete malicioso y llegar a root.

El mismo 27 de octubre, TeamViewer publicó el boletín TV-2026-1012 con seis elevaciones de privilegios locales en los complementos de Remote Management, en Monitoring anterior a 26.10.1 y en Patch Management anterior a 26.9.1, tres de ellas de 7,8. Esos componentes se corrigen por actualización automática. El cliente, no.

De un desbordamiento de heap a WinExec en un Windows con CFG y DEP

Provocar el cierre del viewer es la parte fácil. Con la superficie de 32.768 por 32.768 y una sola actualización que cubra toda la pantalla declarada, el cliente de Windows se cae de forma limpia y repetible, y el host puede repetirlo cada vez que el técnico vuelva a conectarse. El informe añade que el atacante también elige el tamaño del búfer. Con anchura 0xFFFFFFF5, altura 1 y 8 bits por píxel, la reserva baja a unos 0x440 bytes y cae en una clase de tamaño pequeña del heap, al lado de objetos que el atacante puede preparar de antemano. El resultado es un desbordamiento lineal, con contenido elegido por el atacante y en la zona del heap que el atacante escoge.

La superficie corrompida es un objeto vivo al que el viewer llama más tarde a través de un puntero guardado en su primer campo. Sobrescribir ese puntero redirige la llamada. Remedio afirma que esquivó Control Flow Guard y DEP, las dos protecciones de Windows pensadas para frenar justo eso, y que dirigió la llamada a WinExec para ejecutar un programa elegido por el atacante en el viewer. El informe no detalla cómo saltó esas protecciones.

El fotograma inicial de la demo de Remedio, un vídeo en inglés alojado en el propio informe, muestra a la izquierda el cliente del técnico listo para conectar y a la derecha el host malicioso con la consola del exploit abierta. El vídeo termina con el host ejecutando un programa en la máquina del técnico. Remedio pone límites a lo que demuestra. Los bytes que corrompen el heap los coloca un gancho en el lado del host que sustituye a la carga de teselas enviada por la red y al paso de preparación del heap, así que el ataque completo por el cable no está demostrado en público, y la ejecución de código solo se ha enseñado en Windows. TeamViewer se limita a decir que, según la plataforma, el fallo puede permitir ejecutar código con los privilegios del proceso del viewer.

La cronología que publican Remedio y TeamViewer cabe en cinco fechas.

Entre el aviso y el parche hubo una actualización de seguridad, la 15.82 del 29 de septiembre, que no tocó el fallo. Remedio probó la 15.80.6.0 y observó el constructor vulnerable todavía presente en la 15.82.6.0, de modo que quien actualizó en septiembre sigue expuesto hasta que instale la 15.83.

Helpdesk, MSP y el silencio de INCIBE-CERT sobre el boletín de octubre

Aquí no sirven Shodan ni Censys. El fallo vive en el cliente que inicia la conexión, no en un servicio a la escucha en internet, así que a la hora de publicar esta pieza no existe recuento de exposición ni puede existir. La población en riesgo es la de los puestos desde los que se conecta a equipos ajenos, el helpdesk interno, el técnico de un proveedor de servicios gestionados que atiende a decenas de clientes y el usuario que ayuda a un familiar. Remedio recuerda que el propio fabricante presume de más de 2.500 millones de dispositivos con el software instalado.

En España, TeamViewer es la herramienta por defecto de buena parte del soporte a pymes y del canal MSP, y aparece además en el aviso del FBI y CISA sobre SafePay como una de las tres herramientas de acceso remoto que el grupo instala para persistir en sus víctimas, como contamos en la noticia sobre SafePay. Ese dato tiene una segunda lectura con este fallo. Un equipo ya comprometido con TeamViewer instalado es, desde el 29 de octubre, un host desde el que atacar al técnico que entre a limpiarlo.

INCIBE-CERT publicó el 30 de septiembre de 2026 el aviso INCIBE-2026-683, de importancia alta, para los cinco fallos que cerró la 15.82, entre ellos CVE-2026-92370, otro 8,8 que permitía a un atacante remoto hacer en la sesión acciones que la víctima había denegado. A las 07:00 UTC del 31 de octubre no había aviso para el boletín del 27 de octubre, y el más reciente de la lista del CERT nacional era uno de Veeam del día 29. Quien programe sus parches a partir de los avisos de INCIBE-CERT tiene hoy la 15.82 como referencia, y la 15.82 sigue siendo vulnerable a CVE-2026-111585.

La cuenta del mes deja 14 CVE de severidad alta en productos de TeamViewer repartidos en tres boletines, cinco el 29 de septiembre con el boletín TV-2026-1010, tres el 27 de octubre en los clientes y seis ese mismo día en Remote Management.

El fabricante ya pasó en 2024 por un incidente de otra naturaleza, cuando atribuyó a APT29 un acceso a su entorno corporativo de TI detectado el 26 de junio de 2024 y sostuvo que la plataforma de conexión y los datos de clientes no se vieron afectados, según su comunicado. Aquel caso afectaba al fabricante. Este afecta a cada puesto desde el que se presta soporte.

Un helpdesk da por hecho que el riesgo de una sesión remota corre hacia el equipo que recibe ayuda, y su segmentación, sus permisos y su EDR están pensados en esa dirección. Este fallo invierte el sentido. El puesto del técnico suele guardar credenciales de administración de dominio, consolas de RMM y acceso a decenas de clientes, como vimos con la credencial robada de ConnectWise, y es un objetivo mucho más rentable que cualquier portátil de usuario. Tratarlo como un endpoint expuesto y no como una máquina de confianza es la consecuencia práctica de este boletín, y es la misma que dejó el zero-day de BeyondTrust Remote Support hace dos semanas, aunque allí el atacante entrase por el appliance.

Dudas habituales sobre la seguridad de TeamViewer

¿Cuál es la última versión de TeamViewer?

A 31 de octubre de 2026, la versión corregida es la 15.83 del Full Client, del Host, de la edición Portable de Windows y de la app Remote Control para Android. En una rama heredada por compatibilidad con Windows 7 u 8, el parche está en la 15.64.10, y en las ramas 14.7 y 13.2 en las compilaciones de la tabla del boletín que reproduce la captura. El menú Ayuda muestra la versión instalada en Acerca de TeamViewer.

¿Es seguro TeamViewer?

Es tan seguro como su versión y su configuración. Las sesiones van cifradas y el acceso exige un ID con contraseña o una cuenta con doble factor, pero en un mes el fabricante ha corregido 14 fallos de severidad alta y uno de ellos convierte al equipo asistido en atacante. Más que cambiar de herramienta, conviene tratar el cliente como cualquier otro software expuesto, con un inventario de versiones y cuentas de técnico sin privilegios de administración permanentes.

¿Cómo saber si alguien está conectado a mi TeamViewer?

El cliente muestra la sesión activa en su propia ventana y, en Windows, el fichero Connections_incoming.txt de la carpeta de instalación registra cada conexión entrante con el ID de origen, la fecha y la duración. Las sesiones salientes de cada técnico quedan en Connections.txt dentro de su perfil de usuario, y en las cuentas con licencia el panel web de TeamViewer ofrece informes de conexión por usuario. Ese registro de salientes es el que interesa tras este fallo.

Actualizar a 15.83 y comprobar qué versión corre en cada puesto de soporte

Este bloque devuelve la versión instalada en un equipo Windows a partir del registro y del propio ejecutable, y lista las últimas conexiones salientes del técnico. Se puede lanzar contra una lista de equipos con Invoke-Command desde la consola de administración. En Linux, teamviewer --version imprime la versión, y en macOS la da el campo CFBundleShortVersionString del Info.plist de la aplicación.

# Versión de TeamViewer instalada en este equipo Windows
Get-ItemProperty 'HKLM:\SOFTWARE\TeamViewer', 'HKLM:\SOFTWARE\WOW6432Node\TeamViewer' -ErrorAction SilentlyContinue |
  Select-Object Version, InstallationDirectory
(Get-Item "$env:ProgramFiles\TeamViewer\TeamViewer.exe" -ErrorAction SilentlyContinue).VersionInfo.ProductVersion

# Últimas conexiones salientes del usuario actual (ID remoto, fecha y hora)
Get-Content "$env:APPDATA\TeamViewer\Connections.txt" -Tail 20 -ErrorAction SilentlyContinue

Con el inventario hecho, el orden de trabajo que sale del boletín y del informe es este.

1. Actualiza hoy a la 15.83 todos los puestos desde los que se conecta a equipos de terceros, empezando por el helpdesk y los técnicos de MSP, y después el resto de Full Client, Host, Portable y la app de Android. El Host no aparece en la ficha de CVE-2026-111585, pero sí en las de CVE-2026-92372 y CVE-2026-92374.
2. Si mantienes ramas heredadas, instala 15.64.10 en Windows 7 y 8, 14.7.48868 en la rama 14.7 y las compilaciones 13.2.36231, 13.2.154008 o 13.2.154007 según el sistema. TeamViewer no ofrece mitigación alternativa, solo actualizar.
3. Comprueba que los complementos de Remote Management hayan recibido Monitoring 26.10.1 y Patch Management 26.9.1 por actualización automática, y en el cliente 14.7 la 24.12.5 de Patch Management.
4. Hasta que todos los puestos estén en 15.83, limita las sesiones salientes a hosts conocidos y desconfía de las peticiones de soporte que lleguen de equipos nuevos o de contactos desconocidos, porque ese es el escenario de ingeniería social que convierte este fallo en un vector de entrada.
5. Revisa el registro de conexiones salientes de cada técnico y los cierres inesperados de TeamViewer.exe en el visor de eventos de Windows (registro Application, origen Application Error, evento 1000) desde el 29 de octubre. Un viewer que se cierra en mitad de una sesión es el síntoma más barato del fallo.
6. Aplica en los puestos de soporte lo que ya exiges en los servidores, con una regla del EDR que alerte de procesos hijos inesperados de TeamViewer.exe, cuentas de técnico sin administración permanente y segmentación respecto a las consolas de RMM, en la línea del modelo Zero Trust que ya aplicas al acceso de los usuarios.
7. Si detectas una sesión sospechosa, avisa a INCIBE-CERT (empresas y particulares) o al CCN-CERT (administraciones públicas) y conserva los registros del cliente y del EDR antes de reinstalar nada.

TeamViewer ha tardado 74 días en pasar del informe de Remedio al parche, un plazo habitual en el sector, y publicó el boletín antes de que el investigador contase los detalles. El boletín, en cambio, no nombra al Host en la ficha de CVE-2026-111585 ni explica por qué la 15.82 de septiembre, distribuida como actualización de seguridad, dejó intacto el constructor que Remedio observó en la 15.82.6.0. Esa es la pregunta que decide si el ciclo de parches del cliente de soporte puede seguir yendo por detrás del de los servidores.

Queda el ataque completo por la red, que Remedio no ha demostrado y que nadie ha publicado. Con el fallo descrito al detalle, las cuentas del desbordamiento en abierto y el parche disponible desde hace cuatro días, es razonable esperar que alguien cierre ese hueco antes de que lo haga la mayoría de los helpdesk con su inventario.