Neutron, nuestro motor de IA, obtuvo un 97.1% en el benchmark CyberGym de UC Berkeley. Más información

Análisis a fondo

Análisis a fondo

RCE en TeamViewer por el tamaño de pantalla, corregida en 15.83 (CVE-2026-111585)

Un host de TeamViewer malicioso ejecuta código en el viewer que conecta para ayudarle, mediante un tamaño de pantalla truncado; actualice los clientes a 15.83.

TL;DR

  • El decodificador de pantalla de los clientes de TeamViewer multiplica el tamaño de pantalla anunciado por el host en aritmética de 32 bits. Un host malicioso o comprometido puede ejecutar código en el viewer que se conecta a él. Remedio publicó la investigación el 29 de octubre de 2026, y TeamViewer la corrigió en 15.83.
  • Todo componente del cliente anterior a 15.83 está afectado: el Full Client y el Host en Windows, Linux y macOS, el cliente Portable de Windows y la aplicación Android Remote Control, más las líneas heredadas 15.64, 14.7 y 13.2. El fabricante indica que TeamViewer está instalado en más de 2.5 mil millones de dispositivos.
  • El boletín TV-2026-1011 califica la falla como High, CVSS v3.1 8.8, y no publica prueba de concepto. Dos fallas más llegan en la misma versión 15.83: una escritura fuera de límites alcanzable desde grabaciones de sesión y una escalada de privilegios local a root en macOS.
  • TeamViewer declara no conocer explotación activa, y la falla no está en el catálogo KEV de CISA al 2 de noviembre de 2026. Actualice todos los clientes a 15.83, o a la versión corregida de su línea heredada, y siga leyendo para saber qué revisar.

¿Está afectado?

Está expuesto cuando se cumple la primera condición y al menos una de las otras dos:

  • Un componente del cliente de TeamViewer está en una versión anterior a 15.83. Los componentes afectados son el Full Client y el Host en Windows, Linux y macOS, el cliente Portable de Windows y la aplicación Android Remote Control.
  • Para CVE-2026-111585, el atacante es el host remoto de una sesión que su operador acepta. Ese host puede estar operado por el atacante, o ser una máquina real cuyo tráfico de sesión o cuya cuenta ha sido tomada. La compromisión ocurre al abrirse la sesión, antes de cualquier trabajo.
  • Para la vía de grabaciones, CVE-2026-92372, un usuario abre una grabación de sesión de TeamViewer manipulada, un archivo .tvs, de una fuente no confiable en un Full Client de Linux o macOS.
Rama Versiones afectadas Versión corregida
Full Client y Host, Windows, Linux, macOS antes de 15.83 15.83 (27 de octubre de 2026)
Cliente Portable, Windows antes de 15.83 15.83
Aplicación Remote Control, Android antes de 15.83 15.83
Línea heredada 15.64, Windows 7 y 8 antes de 15.64.10 15.64.10
Línea heredada 14.7, Windows, Linux, macOS antes de 14.7.48868 14.7.48868
Línea heredada 13.2, Windows antes de 13.2.36231 13.2.36231
Línea heredada 13.2, Linux antes de 13.2.154008 13.2.154008
Línea heredada 13.2, macOS antes de 13.2.154007 13.2.154007

Remedio probó el viewer de Windows en 15.80.6.0 y lo encontró afectado, y observó el constructor vulnerable aún presente en 15.82.6.0, así que el límite es realmente 15.83. Compruebe lo que ejecuta:

(Get-Item "C:\Program Files\TeamViewer\TeamViewer.exe").VersionInfo.FileVersion

En Android, la versión de la aplicación aparece en Configuración, dentro de Aplicaciones, o en la ficha de Play Store. La aplicación Android Remote Control lleva la misma falla de descompresión de pantalla, así que incluya los teléfonos gestionados en el barrido de versiones.

¿Cómo corregirlo?

Actualice todos los componentes del cliente a 15.83, o a la versión corregida de su línea:

  1. Actualice el Full Client y el Host desde el aviso de actualización de la aplicación, o descargue 15.83 del fabricante e instálela sobre el cliente existente.
  2. Reemplace el cliente Portable por la versión 15.83 de la base de conocimiento del fabricante, porque las instalaciones portables no se actualizan solas.
  3. Actualice la aplicación Android Remote Control desde Play Store, y confirme que la versión diga 15.83 o posterior.
  4. Para los hosts fijados en las líneas heredadas, aplique la versión corregida de esa línea, que la sección de versiones corregidas del boletín enlaza por plataforma.

No existe solución alternativa de configuración, porque aceptar sesiones es el modo normal de operación del producto y la falla se dispara al abrirse la sesión. El límite de cualquier mitigación es claro. Restringir qué socios pueden conectarse reduce quién puede atacarle, pero todo host al que sus operadores sigan ayudando sigue siendo una fuente posible de la geometría maliciosa.

¿Cuál es la causa raíz?

El viewer asigna su mapa de bits de pantalla con un tamaño que se desborda en aritmética de 32 bits. Las comprobaciones de límites que guardan las escrituras posteriores leen las dimensiones sin truncar. El componente es CBitmapBuffer, la superficie de decodificación de reserva del viewer cuando no se usa un decodificador de vídeo por hardware para la sesión.

La sesión se abre con un mensaje DisplayParams del host que lleva un ancho, un alto y una profundidad de color. El viewer asigna el mapa de bits a partir de esos números, y el camino de escritura sigue:

// width, height, bpp_bits all originate in the peer
// DisplayParams message, unchecked.
// stored at plane+0x20, NOT truncated
stride = (bpp_bits * (width + 0x10)) >> 3;
// 32-bit multiply: wraps mod 2^32
plane.byteSize = (uint32)(stride * (height + 0x10));
// allocates the WRAPPED size
buf = operator_new[]( (ulong)(stride * (height + 0x10)) );

La multiplicación se evalúa en 32 bits, se desborda, y solo el resto desbordado llega a la asignación. El ancho y el alto almacenados conservan los valores completos del host. Las comprobaciones de rectángulo de los decodificadores RLE comparan luego cada actualización con las dimensiones declaradas, nunca con los bytes asignados:

if ((D_height < y2) || (D_width < x2))
    return "invalid rectangle";
// D_width / D_height are the DECLARED dims (untruncated)
// otherwise, for y in [y1, y2):
// write pixels at base + y*stride + (x*bpp >> 3)

Nada en el camino impone un límite superior a la geometría anunciada. El host elige por tanto dimensiones que hacen divergir la asignación y el permiso de escribir en casi 2 elevado a 32. El host también puede dirigir al viewer hacia esa superficie a voluntad. Se niega a negociar los códecs de vídeo AV1 o H.264, lo que fuerza el camino de teselas sin pérdida que sirve la superficie del mapa de bits.

¿Cómo se explota?

La investigación publicada recorre el ataque desde una sola sesión aceptada:

  1. El atacante opera un host, o toma el puerto de uno real, y el viewer de la víctima se conecta para ayudar. La víctima acepta la sesión; esa es la única interacción que el vector CVSS registra como UI:R.
  2. El host rechaza la negociación de códecs de vídeo, así que el viewer cae en CBitmapBuffer y los decodificadores de teselas RLE.
  3. El DisplayParams anuncia una pantalla de 32768 por 32768 a 32 bits por píxel. El tamaño previsto es 4,299,162,624 bytes; la asignación desbordada es de 4,195,328 bytes, unos 4 MB, y la superficie sigue reclamando 32,784 filas.
  4. Una sola actualización de pantalla cuyo rectángulo cubre todo el tamaño declarado hace que el decodificador escriba la superficie entera en ese búfer. En un Windows estándar esto es un fallo limpio y repetible: denegación de servicio remota dentro de una sesión ordinaria.
  5. Para la ejecución de código, el atacante encoge la asignación a propósito. Anunciar un ancho de 0xFFFFFFF5 con un alto de 1, a 8 bits por píxel, reduce la asignación, según la medición de la investigación, a un búfer de unos 0x440 bytes. Eso la coloca en una clase pequeña de tamaño del montón, junto a objetos preparables.
  6. El desbordamiento corrompe un objeto vivo que el viewer llama después mediante un puntero en su primer campo. Sobrescribir ese puntero redirige la llamada, y la investigación la llevó mediante un pivote de pila a WinExec, venciendo tanto control-flow guard como DEP.

La ejecución de código demostrada corrió sobre los binarios de fábrica, con el cliente vigente en ese momento (anterior a 15.83) y sus defensas habituales activadas. En la demostración, los bytes corruptores los colocó un gancho del lado del host que recorre el camino de código idéntico y sustituye a la carga de teselas del cable durante el paso de preparación del montón.

¿Cómo fluye el ataque?

Una sola sesión aceptada es toda la superficie de ataque, y la asignación desbordada convierte la geometría de pantalla del host en control del proceso del viewer.

flowchart LR A["El viewer de la víctima se conecta
para ayudar a un host hostil"] --> B["El host rechaza los códecs de vídeo,
el viewer cae en CBitmapBuffer"] B --> C["DisplayParams anuncia
32768 x 32768 a 32 bpp"] C --> D["La multiplicación se desborda en 32 bits,
asignación pequeña, lienzo completo,
sin comprobación de límites"] D --> E["El rectángulo de superficie completa escribe
más allá de la asignación"] E --> F["Fallo a voluntad, o preparación del montón
hacia ejecución de código en el viewer"]

¿Qué puede hacer un atacante?

El techo demostrado es la ejecución de código en el proceso del viewer, con la cuenta que lo ejecuta, en el momento en que se abre la sesión:

  • El atacante puede bloquear el viewer cuando quiera, una denegación de servicio remota dentro de una sesión normal.
  • Con la preparación de la clase de tamaño, el atacante convierte la misma escritura en la ejecución de un programa de su elección en el viewer, demostrado en clientes de Windows vigentes en ese momento (anteriores a 15.83) con control-flow guard y DEP activados.
  • La vía de grabaciones de CVE-2026-92372 extiende el mismo impacto a los Full Client de Linux y macOS mediante una grabación de sesión .tvs manipulada que el usuario abre, sin necesidad de host.
  • Separadamente, CVE-2026-92374 da a un atacante local con pocos privilegios en macOS acceso root, mediante una condición de carrera de verificación-uso y el manejo de enlaces simbólicos en el ayudante privilegiado del instalador.

Las condiciones de la falla principal son pocas y específicas: el atacante debe controlar el lado del host de una sesión que el operador acepta, o un puerto al que el viewer se conecta. El operador ve abrirse una sesión normal, y la compromisión no necesita robo de contraseñas ni interacción adicional.

¿Por qué funciona la corrección?

TeamViewer es software cerrado, así que no hay parche público. El boletín corrige la falla en 15.83 para todos los productos actuales y lo traslada a las tres líneas heredadas. Remedio verificó el límite desde fuera: el constructor seguía presente en 15.82.6.0, y 15.83 resuelve el problema.

Lo que la corrección debe hacer se deduce de la causa raíz. La asignación y las comprobaciones de límites leen dos números distintos para la misma superficie, de modo que una corrección completa hace que cada escritura se valide contra los bytes realmente asignados. También valida la geometría anunciada contra un límite superior antes de crear el mapa de bits.

La calificación del fabricante, un boletín Importante cuya única solución es actualizar a la última versión, coincide con ese alcance.

¿Cómo sé si fui comprometido?

Ni el boletín ni la investigación publican indicadores de compromiso. Los rastros se deducen de la mecánica publicada del ataque:

Get-WinEvent -LogName Application | Where-Object { $_.Message -match "TeamViewer" } | Select -First 20

Fallos de TeamViewer.exe en el registro de aplicación, si no tienen explicación, marcan la variante de denegación de servicio. La variante de ejecución de código lanza su carga como hija del viewer. Revise la telemetría de creación de procesos buscando cualquier proceso cuyo padre sea TeamViewer.exe o TeamViewer_Desktop.exe que el operador no pueda justificar.

Revise los registros de conexión en la TeamViewer Management Console buscando sesiones con socios no confiables alrededor de cualquiera de esos eventos, y trate la cuenta del operador como comprometida si una carga llegó a ejecutarse.

Para la vía de grabaciones, busque en los equipos gestionados archivos .tvs de fuentes no confiables y bórrelos tras actualizar. Una grabación manipulada abierta antes de la actualización tiene el mismo efecto que un host hostil.

Cronología

  • 2026-08-14: Remedio informa la falla del viewer a TeamViewer Product Security.
  • 2026-10-22: TeamViewer acepta el hallazgo con CVSS v3.1 8.8 y asigna CVE-2026-111585.
  • 2026-10-27: TeamViewer publica 15.83, el boletín TV-2026-1011 y los tres registros CVE, y califica el boletín como Importante.
  • 2026-10-29: Remedio publica el análisis técnico, por Omri Dar.
  • 2026-11-02: TeamViewer declara que no conoce explotación, y las fallas no están en el catálogo KEV de CISA.

La falla pasó de informe a corrección en 74 días, y el análisis llegó dos días después de la corrección
Figura 1: el informe del 14 de agosto, la aceptación y el CVE del 22 de octubre, la versión 15.83 y el boletín del 27 de octubre, y el análisis del 29 de octubre. Fuente: Remedio y el boletín de TeamViewer TV-2026-1011, comprobados el 2 de noviembre de 2026

FAQ

¿Está afectada la aplicación de Android?

Sí. La aplicación Android Remote Control lleva la misma falla de pantalla de control remoto, antes de la versión 15.83, según la lista de productos afectados del boletín. Los teléfonos gestionados que usan TeamViewer para controlar otros dispositivos necesitan la misma actualización.

¿Una contraseña de TeamViewer fuerte detiene esto?

No. El ataque viaja dentro de una sesión que el operador acepta deliberadamente. El host nunca necesita la contraseña del viewer, y la compromisión ocurre al abrirse la sesión, antes de que cualquier autenticación del viewer hacia el host importe.

¿Qué hay de las grabaciones de sesión?

Una grabación .tvs manipulada es una segunda vía de entrega en Linux y macOS, registrada como CVE-2026-92372 con la misma nota 8.8. Trate las grabaciones de fuentes no confiables como programas, porque en clientes sin parchear es exactamente lo que son.

¿Es la misma clase de falla que la del viewer de TightVNC?

Sí, la misma semana produjo dos divulgaciones independientes del mismo patrón en viewers de acceso remoto. El host anuncia una geometría de pantalla, el viewer trunca el cálculo del tamaño, y el camino de decodificación escribe más allá de la asignación. SSD Secure Disclosure publicó la falla de TightVNC con un exploit público el 29 de octubre de 2026. Cualquier herramienta de acceso remoto que dimensione un búfer a partir de dimensiones anunciadas por el par merece la misma pregunta.

¿Qué hay de MeshCentral?

Separadamente, y no es una divulgación de vulnerabilidad, los mantenedores del servidor de gestión remota de código abierto MeshCentral publicaron una actualización de seguridad urgente el 23 de octubre de 2026. La nota de versión advierte de un atacante activo que toma servidores y sus clientes remotos, e insta a actualizar de inmediato a 1.3.1.

Esa nota de versión es toda la divulgación; no existe aviso ni CVE para ella. Es el mismo rincón de la superficie de ataque, la confianza que una herramienta de soporte deposita en la máquina a la que se conecta.

¿Se explotó en entornos reales?

TeamViewer declara no tener conocimiento de explotación activa en el momento de la publicación. Las fallas no estaban en el catálogo KEV de CISA al 2 de noviembre de 2026. La demostración de la investigación es un resultado de laboratorio, no un informe de campo.

Referencias

  • Boletín de seguridad de TeamViewer TV-2026-1011, los tres CVE y la matriz de versiones corregidas: https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1011/ (publicado el 27 de octubre de 2026; comprobado el 2 de noviembre de 2026)
  • Investigación de Remedio, «Remote Code Execution in TeamViewer», el análisis técnico completo: https://remedio.io/research/vulnerability-disclosures/remote-code-execution-in-teamviewer/ (publicada el 29 de octubre de 2026; comprobada el 2 de noviembre de 2026)
  • Registro CVE-2026-111585, TeamViewer CNA, CVSS v3.1 8.8: https://www.cve.org/CVERecord?id=CVE-2026-111585 (publicado el 27 de octubre de 2026; comprobado el 2 de noviembre de 2026)
  • Registro CVE-2026-92372, la vía de grabaciones de sesión: https://www.cve.org/CVERecord?id=CVE-2026-92372 (publicado el 27 de octubre de 2026; comprobado el 2 de noviembre de 2026)
  • Registro CVE-2026-92374, la escalada de privilegios local en macOS: https://www.cve.org/CVERecord?id=CVE-2026-92374 (publicado el 27 de octubre de 2026; comprobado el 2 de noviembre de 2026)
  • SSD Secure Disclosure, «TightVNC Viewer Pre-auth RCE», la divulgación de la misma semana sobre el mismo patrón de viewer: https://ssd-disclosure.com/tightvnc-viewer-pre-auth-rce/ (publicada el 29 de octubre de 2026; comprobada el 2 de noviembre de 2026)
  • Nota de versión de MeshCentral 1.3.1, el aviso de actualización urgente por un ataque activo: https://github.com/Ylianst/MeshCentral/releases/tag/1.3.1 (publicada el 23 de octubre de 2026; comprobada el 2 de noviembre de 2026)
  • Boletín complementario de TeamViewer TV-2026-1012, complementos de Remote Management: https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1012/ (comprobado el 2 de noviembre de 2026)
  • Catálogo KEV de CISA, feed comprobado para CVE-2026-111585, CVE-2026-92372 y CVE-2026-92374: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (comprobado el 2 de noviembre de 2026)