TeamViewer patches critical flaw exposing support technicians' machines to remote code execution

TeamViewer has patched a critical vulnerability that flips the usual support-session risk: instead of endangering the machine being helped, the flaw can crash the app or run arbitrary code on the machine of whoever initiates the connection — typically the support technician. The fixes ship in version 15.83 for the Full Client, Host, Portable and Android Remote Control apps, with additional updates for older releases listed in TeamViewer bulletin TV-2026-1011.

A display-processing bug on the viewer's side

The core flaw, tracked as CVE-2026-111585, is an integer overflow in the component that processes the remote desktop display, according to a warning from Remedio reported by SecurityWeek and relayed on dev.to. It carries a CVSS score of 8.8 and affects TeamViewer applications on Windows, macOS, Linux and Android.

Exploitation requires the user to connect to a remote machine that an attacker controls or has compromised. That is precisely the situation support teams work in daily: a technician dialing into a customer's device has no guarantee the far end is clean. As the dev.to report points out, being the one who starts the session offers no protection, because the vulnerable code runs on the viewer's side of the connection.

TeamViewer says it has not observed exploitation of these vulnerabilities in the wild.

Two further flaws fixed in the same release

On macOS and Linux, the update also addresses CVE-2026-92372, an out-of-bounds write that could permit arbitrary code execution through crafted screen image data or a maliciously constructed .tvs session recording. The recording vector extends the risk beyond live sessions to anyone reviewing saved session files after the fact.

On macOS, CVE-2026-92374 covers a time-of-check-to-time-of-use race combined with improper handling of symbolic links. A local attacker holding low privileges could use it to install a malicious package and obtain root. Unlike the display flaw, this one requires existing local access to the machine.

What teams should check first

Guidance from TMGS, whose analysis was published on dev.to, recommends prioritizing technicians' and administrators' machines when reviewing exposure:

• Inventory operating systems, application types and versions, including Portable copies, then apply and verify the appropriate patches.
• Review connections to unfamiliar machines against support requests and the staff who handled them.
• Investigate application crashes and security alerts on viewer machines, keeping in mind that a crash alone is not proof of exploitation.
• Verify the origin of .tvs recordings before opening them, particularly on macOS and Linux.
• Preserve logs, examine suspicious devices and isolate any machine showing signs of compromise under existing incident-response procedures.

Why it matters

The defining feature of this bug class is the inversion of trust. Remote support tools are usually assessed as a risk to the person being helped; here the trusted party — the technician — is the target, and the attack surface is every endpoint they connect to, plus every session recording they later open. Support workstations function as privileged access infrastructure: compromising one through a routine ticket could expose internal systems, saved credentials and customer environments. Patch priority should reflect that, and a retrospective review of past sessions involving unfamiliar machines is prudent given that crafted screen data and .tvs files are also vectors. With TeamViewer reporting no observed exploitation so far, organizations still have a window to patch before the fixes are reverse-engineered.