RCE TeamViewer via la taille d'écran, corrigée dans 15.83 (CVE-2026-111585)

TL;DR

• Le décodeur d'écran des clients TeamViewer multiplie la taille d'écran annoncée par l'hôte en arithmétique 32 bits. Un hôte malveillant ou compromis peut donc exécuter du code sur le viewer qui se connecte à lui. Remedio a publié la recherche le 29 octobre 2026, et TeamViewer l'a corrigée dans 15.83.
• Chaque composant client avant 15.83 est concerné : le Full Client et l'Host sur Windows, Linux et macOS, le client Portable Windows et l'application Android Remote Control, plus les lignes héritées 15.64, 14.7 et 13.2. Le vendeur indique que TeamViewer est installé sur plus de 2,5 milliards d'appareils.
• Le bulletin TV-2026-1011 note la faille High, CVSS v3.1 8,8, et ne publie pas de preuve de concept. Deux autres failles arrivent dans la même version 15.83 : une écriture hors limites atteignable depuis des enregistrements de session et une élévation de privilèges locale vers root sur macOS.
• TeamViewer déclare ne pas connaître d'exploitation active, et la faille n'est pas au catalogue KEV de la CISA au 2 novembre 2026. Mettez chaque client à jour en 15.83, ou vers la version corrigée de sa ligne héritée, et lisez la suite pour savoir quoi vérifier.

Suis-je concerné ?

Vous êtes exposé lorsque la première condition est remplie et qu'au moins l'une des deux autres s'applique :

• Un composant client TeamViewer est en version antérieure à 15.83. Les composants concernés sont le Full Client et l'Host sur Windows, Linux et macOS, le client Portable Windows et l'application Android Remote Control.
• Pour CVE-2026-111585, l'attaquant est l'hôte distant d'une session que votre opérateur accepte. Cet hôte peut être tenu par l'attaquant, ou être une vraie machine dont le trafic de session ou le compte a été détourné. La compromission survient à l'ouverture de la session, avant tout travail.
• Pour la voie des enregistrements, CVE-2026-92372, un utilisateur ouvre un enregistrement de session TeamViewer fabriqué, un fichier .tvs, d'une source non fiable sur un Full Client Linux ou macOS.

Remedio a testé le viewer Windows en 15.80.6.0 et l'a trouvé concerné, et a observé le constructeur vulnérable encore présent en 15.82.6.0, donc la frontière est bien 15.83. Vérifiez ce que vous exécutez :

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

Sur Android, la version de l'application apparaît dans Paramètres, sous Applications, ou dans la fiche du Play Store. L'application Android Remote Control porte la même faille de décompression d'écran, donc incluez les téléphones gérés dans le recensement.

Comment corriger ?

Mettez à jour chaque composant client en 15.83, ou vers la version corrigée de sa ligne :

1. Mettez à jour le Full Client et l'Host depuis l'invite de mise à jour de l'application, ou téléchargez 15.83 depuis le vendeur et installez-la par-dessus le client existant.
2. Remplacez le client Portable par la version 15.83 de la base de connaissances du vendeur, car les installations portables ne se mettent pas à jour seules.
3. Mettez à jour l'application Android Remote Control depuis le Play Store, et confirmez que la version indique 15.83 ou plus.
4. Pour les hôtes figés sur les lignes héritées, appliquez la version corrigée de la ligne, que la section des versions corrigées du bulletin lie par plateforme.

Il n'existe aucune solution de contournement de configuration, car accepter des sessions est le mode de fonctionnement normal du produit et la faille se déclenche à l'ouverture de la session. La limite de toute atténuation est claire. Restreindre les partenaires autorisés à se connecter réduit qui peut vous attaquer, mais tout hôte que vos opérateurs aident encore reste une source possible de la géométrie malveillante.

Quelle est la cause racine ?

Le viewer alloue son bitmap d'écran avec une taille qui boucle en arithmétique 32 bits. Les contrôles de bornes qui gardent les écritures suivantes lisent les dimensions non tronquées. Le composant est CBitmapBuffer, la surface de décodage de repli du viewer quand aucun décodeur vidéo matériel n'est utilisé pour la session.

La session s'ouvre par un message DisplayParams de l'hôte portant une largeur, une hauteur et une profondeur de couleur. Le viewer alloue le bitmap à partir de ces nombres, et le chemin d'écriture suit :

// 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 multiplication est évaluée en 32 bits, boucle, et seul le reste bouclé atteint l'allocation. La largeur et la hauteur stockées gardent les valeurs complètes de l'hôte. Les contrôles de rectangle des décodeurs RLE comparent ensuite chaque mise à jour aux dimensions déclarées, jamais aux octets alloués :

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)

Rien sur le chemin n'impose de borne supérieure à la géométrie annoncée. L'hôte choisit donc des dimensions qui font diverger l'allocation et l'autorisation d'écrire de presque 2 puissance 32. L'hôte peut aussi diriger le viewer vers cette surface à volonté. Il refuse de négocier les codecs vidéo AV1 ou H.264, ce qui force le chemin des tuiles sans perte que sert la surface bitmap.

Comment la faille est-elle exploitée ?

La recherche publiée déroule l'attaque depuis une seule session acceptée :

1. L'attaquant tient un hôte, ou détourne le port d'un vrai, et le viewer de la victime s'y connecte pour aider. La victime accepte la session ; c'est l'unique interaction que le vecteur CVSS note comme UI:R.
2. L'hôte refuse la négociation des codecs vidéo, donc le viewer retombe sur CBitmapBuffer et les décodeurs de tuiles RLE.
3. Le DisplayParams annonce un écran de 32768 sur 32768 à 32 bits par pixel. La taille voulue est de 4 299 162 624 octets ; l'allocation bouclée est de 4 195 328 octets, environ 4 Mo, et la surface revendique toujours 32 784 lignes.
4. Une seule mise à jour d'écran dont le rectangle couvre toute la taille déclarée fait écrire au décodeur la surface entière dans ce tampon. Sur un Windows standard, c'est un plantage net et reproductible : un déni de service distant dans une session ordinaire.
5. Pour l'exécution de code, l'attaquant rétrécit l'allocation exprès. Annoncer une largeur de 0xFFFFFFF5 avec une hauteur de 1, à 8 bits par pixel, boucle l'allocation, selon la mesure de la recherche, à un tampon d'environ 0x440 octets. Cela la place dans une petite classe de taille de tas, à côté d'objets préparables.
6. Le débordement corrompt un objet vivant que le viewer appelle ensuite via un pointeur dans son premier champ. Écraser ce pointeur redirige l'appel, et la recherche l'a routé via un pivot de pile vers WinExec, vainquant à la fois le control-flow guard et le DEP.

L'exécution de code démontrée a tourné sur les binaires livrés, avec le client à jour à l'époque (avant 15.83) et ses défenses habituelles activées. Dans la démonstration, les octets corrupteurs étaient placés par un greffon côté hôte qui suit le chemin de code identique et remplace la charge tuile du réseau pendant l'étape de préparation du tas.

Comment l'attaque se déroule-t-elle ?

Une seule session acceptée constitue toute la surface d'attaque, et l'allocation bouclée transforme la géométrie d'écran de l'hôte en contrôle du processus du viewer.

Que peut faire un attaquant ?

Le plafond démontré est l'exécution de code dans le processus du viewer, sous le compte qui l'exécute, au moment où la session s'ouvre :

• L'attaquant peut faire planter le viewer quand il le veut, un déni de service distant atteint dans une session ordinaire.
• Avec la préparation de la classe de taille, l'attaquant convertit la même écriture en exécution d'un programme de son choix sur le viewer, démontré sur des clients Windows à jour à l'époque (avant 15.83) avec control-flow guard et DEP activés.
• La voie des enregistrements de CVE-2026-92372 étend le même impact aux Full Clients Linux et macOS via un enregistrement de session .tvs fabriqué que l'utilisateur ouvre, sans hôte nécessaire.
• Séparément, CVE-2026-92374 donne à un attaquant local peu privilégié sur macOS les droits root, via une course de type time-of-check-to-use et la gestion des liens symboliques dans l'assistant d'installation privilégié.

Les conditions de la faille principale sont peu nombreuses et précises : l'attaquant doit contrôler le côté hôte d'une session que l'opérateur accepte, ou un port auquel le viewer se connecte. L'opérateur voit une session normale s'ouvrir, et la compromission ne nécessite ni vol de mot de passe ni interaction supplémentaire.

Pourquoi le correctif fonctionne-t-il ?

TeamViewer est un logiciel fermé, donc aucun diff de correctif n'est public. Le bulletin corrige la faille dans 15.83 pour tous les produits actuels et la rétroporte aux trois lignes héritées. Remedio a vérifié la frontière depuis l'extérieur : le constructeur était encore présent en 15.82.6.0, et 15.83 résout le problème.

Ce que le correctif doit faire découle de la cause racine. L'allocation et les contrôles de bornes lisent deux nombres différents pour la même surface, donc un correctif complet fait valider chaque écriture contre les octets réellement alloués. Il valide aussi la géométrie annoncée contre une borne supérieure avant la création du bitmap.

La note du vendeur, un bulletin Important dont l'unique remède est la mise à jour vers la dernière version, correspond à cette portée.

Comment savoir si j'ai été compromis ?

Ni le bulletin ni la recherche ne publient d'indicateurs de compromission. Les traces découlent de la mécanique publiée de l'attaque :

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

Des plantages de TeamViewer.exe dans le journal applicatif, sans explication, marquent la variante par déni de service. La variante d'exécution de code lance sa charge en enfant du viewer. Passez en revue la télémétrie de création de processus pour tout processus dont le parent est TeamViewer.exe ou TeamViewer_Desktop.exe que l'opérateur ne peut pas justifier.

Passez en revue les enregistrements de connexion dans la TeamViewer Management Console pour des sessions avec des partenaires non fiables autour d'un tel événement, et considérez le compte de l'opérateur comme compromis si une charge a tourné.

Pour la voie des enregistrements, cherchez sur les points de terminaison gérés les fichiers .tvs de sources non fiables et supprimez-les après la mise à jour. Un enregistrement fabriqué ouvert avant la mise à jour a le même effet qu'un hôte hostile.

Chronologie

• 2026-08-14 : Remedio signale la faille du viewer au TeamViewer Product Security.
• 2026-10-22 : TeamViewer accepte le signalement à CVSS v3.1 8,8 et attribue CVE-2026-111585.
• 2026-10-27 : TeamViewer publie 15.83, le bulletin TV-2026-1011 et les trois enregistrements CVE, et note le bulletin Important.
• 2026-10-29 : Remedio publie l'analyse technique, par Omri Dar.
• 2026-11-02 : TeamViewer déclare aucune exploitation connue, et les failles ne sont pas au catalogue KEV de la CISA.

FAQ

L'application Android est-elle concernée ?

Oui. L'application Android Remote Control porte la même faille d'écran de contrôle à distance, avant la version 15.83, selon la liste des produits concernés du bulletin. Les téléphones gérés qui utilisent TeamViewer pour contrôler d'autres appareils ont besoin de la même mise à jour.

Un mot de passe TeamViewer fort arrête-t-il cela ?

Non. L'attaque circule dans une session que l'opérateur accepte délibérément. L'hôte n'a jamais besoin du mot de passe du viewer, et la compromission survient à l'ouverture de la session, avant que toute authentification du viewer vers l'hôte n'ait d'importance.

Qu'en est-il des enregistrements de session ?

Un enregistrement .tvs fabriqué est une seconde voie de livraison sur Linux et macOS, suivie comme CVE-2026-92372 avec la même note 8,8. Traitez les enregistrements de sources non fiables comme des programmes, car sur des clients non corrigés c'est ce qu'ils sont.

Est-ce la même classe de bug que la faille du viewer TightVNC ?

Oui, la même semaine a produit deux divulgations indépendantes du même schéma dans des viewers d'accès distant. L'hôte annonce une géométrie d'écran, le viewer tronque le calcul de taille, et le chemin de décodage écrit au-delà de l'allocation. SSD Secure Disclosure a publié la faille TightVNC avec un exploit public le 29 octobre 2026. Tout outil d'accès distant qui dimensionne un tampon à partir de dimensions annoncées par le pair mérite la même question.

Qu'en est-il de MeshCentral ?

Séparément, et ce n'est pas une divulgation de vulnérabilité, les mainteneurs du serveur de gestion à distance open source MeshCentral ont publié une mise à jour de sécurité urgente le 23 octobre 2026. La note de version avertit d'un attaquant actif qui prend le contrôle de serveurs et de leurs clients distants, et presse de mettre à jour immédiatement vers 1.3.1.

Cette note de version est toute la divulgation ; aucun avis ni CVE n'existe pour elle. C'est le même coin de la surface d'attaque, la confiance qu'un outil d'assistance place dans la machine à laquelle il se connecte.

La faille a-t-elle été exploitée en conditions réelles ?

TeamViewer déclare ne pas avoir connaissance d'une exploitation active au moment de la publication. Les failles n'étaient pas au catalogue KEV de la CISA au 2 novembre 2026. La démonstration de la recherche est un résultat de laboratoire, pas un signalement de terrain.

Références

• Bulletin de sécurité TeamViewer TV-2026-1011, les trois CVE et la matrice des versions corrigées : https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1011/ (publié le 27 octobre 2026 ; consulté le 2 novembre 2026)
• Recherche Remedio, « Remote Code Execution in TeamViewer », l'analyse technique complète : https://remedio.io/research/vulnerability-disclosures/remote-code-execution-in-teamviewer/ (publiée le 29 octobre 2026 ; consultée le 2 novembre 2026)
• Enregistrement CVE-2026-111585, TeamViewer CNA, CVSS v3.1 8,8 : https://www.cve.org/CVERecord?id=CVE-2026-111585 (publié le 27 octobre 2026 ; consulté le 2 novembre 2026)
• Enregistrement CVE-2026-92372, la voie des enregistrements de session : https://www.cve.org/CVERecord?id=CVE-2026-92372 (publié le 27 octobre 2026 ; consulté le 2 novembre 2026)
• Enregistrement CVE-2026-92374, l'élévation de privilèges locale macOS : https://www.cve.org/CVERecord?id=CVE-2026-92374 (publié le 27 octobre 2026 ; consulté le 2 novembre 2026)
• SSD Secure Disclosure, « TightVNC Viewer Pre-auth RCE », la divulgation de la même semaine sur le même schéma de viewer : https://ssd-disclosure.com/tightvnc-viewer-pre-auth-rce/ (publiée le 29 octobre 2026 ; consultée le 2 novembre 2026)
• Note de version MeshCentral 1.3.1, l'avertissement de mise à jour urgente pour une attaque active : https://github.com/Ylianst/MeshCentral/releases/tag/1.3.1 (publiée le 23 octobre 2026 ; consultée le 2 novembre 2026)
• Bulletin compagnon TeamViewer TV-2026-1012, les add-ons Remote Management : https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1012/ (consulté le 2 novembre 2026)
• Catalogue KEV de la CISA, flux vérifié pour CVE-2026-111585, CVE-2026-92372 et CVE-2026-92374 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consulté le 2 novembre 2026)