El fallo de TeamViewer demuestra que el ordenador del técnico es el blanco fácil

¿Quién es el objetivo en una sesión de soporte remoto: el cliente con el portátil averiado o el técnico que tiene las llaves de todos los demás? La mayoría de los planteamientos de seguridad dan por hecho lo primero. La última vulnerabilidad de TeamViewer es un buen recordatorio de que lo segundo es un premio mucho más jugoso.

El fallo está catalogado como CVE-2026-111585 y tiene una puntuación CVSS de 8,8. SecurityWeek informa de que la firma Remedio advierte de que podría explotarse para tomar el control del sistema del visor, es decir, el del técnico de TI, y lo describe como un desbordamiento de enteros en el componente de procesamiento de la pantalla de control remoto de los clientes de TeamViewer. Según Daily Security Review, los clientes afectados funcionan en Windows, macOS, Linux y Android. Un rastreador, Rescana, afirma que no figura en el catálogo de vulnerabilidades explotadas conocidas de la CISA y que la solución es actualizar los clientes a la versión 15.83. TeamViewer también publica boletines de seguridad en su propio centro de confianza.

El paciente contagia al médico

La seguridad del soporte remoto siempre se ha planteado en torno a una pregunta: ¿cómo evitamos que un desconocido entre en el equipo del cliente? Las contraseñas, los avisos de confirmación y los códigos de sesión sirven a ese fin. Este error invierte el sentido. El técnico se conecta hacia fuera, voluntariamente, a una máquina que no controla, y después procesa todo lo que esa máquina le devuelve, incluidos los datos de su pantalla.

Es un problema estructural, no un error aislado. Un técnico de soporte es justo el tipo de persona que se conecta todo el día a equipos averiados, sospechosos y posiblemente comprometidos. A nuestro juicio, eso convierte al visor en uno de los programas más expuestos de una empresa: procesa datos no fiables llegados del otro lado, y quien lo usa suele tener privilegios elevados y acceso a muchos otros sistemas. Un único ataque con éxito ahí vale mucho más que comprometer el PC de un cliente.

Conviene ser prudentes con lo que se sabe. La documentación de la que disponemos describe una posible toma de control por parte de un host remoto malicioso, es decir, el atacante tiene que estar al otro lado de una sesión. No hay indicios de ataques en circulación, y no daríamos por hecho que sea trivial llevarlo a cabo. Pero «necesita una sesión» es un consuelo escaso cuando las sesiones son todo el producto.

Los fabricantes deberían aislar la sesión, no solo corregir el error

Los desbordamientos de enteros en el código que maneja contenido multimedia y pantallas son una clase de error clásica. Corregir este es necesario, y ya hay una versión corregida disponible. Pero no basta. Mientras el código que decodifica una pantalla remota se ejecute con los mismos privilegios que la cuenta del propio técnico, el próximo desbordamiento tendrá probablemente el mismo alcance.

La respuesta sensata es el aislamiento: decodificar el flujo remoto en un proceso con pocos privilegios y en un entorno aislado (sandbox) que no pueda tocar el resto del equipo, de modo que un fallo o incluso la ejecución de código dentro de él quede contenido. Creemos que este debería ser el diseño por defecto de cualquier herramienta cuyo trabajo sea mirar el ordenador de otra persona. Los fabricantes venden estos productos por su comodidad y su alcance; la inversión menos vistosa es dar por hecho que el otro extremo es hostil.

Los equipos de TI deberían tratar toda conexión como hostil, en ambos sentidos

Para quienes defienden, la lección práctica sale barata. Primero, actualizar los clientes; Rescana apunta a la versión 15.83. Segundo, dejar de hacer sesiones de soporte desde el mismo puesto en el que el técnico lee el correo y guarda sus credenciales de administrador. Un equipo dedicado y blindado, o un escritorio virtual, para el soporte saliente convierte un posible compromiso del dominio en una simple reinstalación. Tercero, dar a la cuenta de soporte solo el acceso que necesita, para que un visor secuestrado no sea una llave maestra.

Nada de esto es exótico. Es la misma disciplina que las empresas ya aplican a un navegador que abre sitios web desconocidos. Las herramientas de soporte remoto merecen la misma desconfianza, porque son, en la práctica, un navegador apuntando al ordenador entero de otra persona.

Nuestro veredicto

La noticia no es que TeamViewer tuviera un error; todo producto grande los tiene. La noticia es que el modelo de confianza del soporte remoto lleva años al revés. Actualiza ya, pero toma el parche como un empujón para aislar el lado del técnico. Si un fabricante no sabe explicarte cómo aísla su visor, da por hecho que no lo hace.