If you work in IT support, you probably think of the remote computer as the risky side of a TeamViewer session. The machine you connect to might be infected, out of date, or owned by someone you do not fully trust, but your own workstation is supposed to be safe. A newly detailed TeamViewer vulnerability turns that assumption around: in the right conditions, the remote host can attack the technician’s computer instead.
The short answer: update TeamViewer to version 15.83 (or the matching fixed build for your older branch) before your next remote session with an untrusted machine. The flaw, tracked as CVE-2026-111585 and rated High with a CVSS score of 8.8, affects TeamViewer Full Client versions before 15.83 on Windows, Linux, and macOS, plus the Windows Portable client and the Android Remote Control app. TeamViewer said it was not aware of any active exploitation when it published its bulletin, but the fix has been available since October 27, so there is no reason to keep running a vulnerable client.
What CVE-2026-111585 actually is
CVE-2026-111585 is an integer overflow in TeamViewer’s remote-control screen processing that can lead to a heap-based buffer overflow in the viewer application. In plain terms, the program that shows you the remote screen miscalculates how much memory it needs, reserves far too little, and then writes incoming screen data past the end of that memory. That can crash the viewer, and depending on the platform, it can potentially let the remote side run code on the technician’s machine with the permissions of the TeamViewer viewer process.
The research comes from Omri Dar at security firm Remedio, who reported the issue to TeamViewer on August 14 and published the technical findings on October 29, after the fix was released. TeamViewer’s own bulletin for the issue is TV-2026-1011, published October 27 and updated the following day.
How the attack works, step by step
A normal TeamViewer session has two roles. The host shares its screen, and the viewer displays it. CVE-2026-111585 abuses the data flowing in the direction most people never worry about: from host back to viewer.
First, the victim has to establish a remote-control session with an attacker-controlled or compromised host. This is not a drive-by flaw that hits you while you browse the web. The attacker needs you to connect to their machine, which is exactly what happens in support work, where technicians routinely connect to computers belonging to strangers, contractors, and customers.
Once the session is running, the malicious host sends a DisplayParams message announcing its screen dimensions: width, height, and color depth. The viewer uses those numbers to reserve memory for incoming pixels inside an object called CBitmapBuffer. Before that happens, the host can refuse the AV1 and H.264 video options, which forces the viewer down the bitmap-update path where the bug lives.
The core error is arithmetic. The buffer size is calculated using 32-bit numbers, so very large screen dimensions can wrap around the maximum value and produce a much smaller result. Remedio gives a stark example: a screen measuring 32,768 by 32,768 pixels at 32 bits per pixel should need more than 4.29 gigabytes after padding. The flawed calculation reserves roughly four megabytes instead.
The viewer then keeps treating that small buffer as if it were large enough for the announced screen. Its decoder checks incoming image rectangles against the declared screen dimensions, not against the memory that was actually allocated, so a rectangle can pass validation while its pixels spill beyond the buffer. Those writes corrupt nearby heap memory, causing a repeatable crash and opening a route toward code execution.
One honest caveat matters here. Remedio demonstrated code execution on Windows while bypassing Control Flow Guard and Data Execution Prevention, but its demonstration used a host-side hook to place the corrupting bytes, standing in for the network payload and heap preparation. That means the researchers showed the memory corruption and a code-execution path, but the demonstration was not a complete, ready-to-fire remote exploit delivered purely over the wire. It is still a serious, patch-worthy flaw, and it is worth describing it accurately rather than overstating it.
Who is affected and which versions are safe
For CVE-2026-111585, the affected products are TeamViewer Full Client before 15.83 on Windows, Linux, and macOS, TeamViewer Portable on Windows, and the TeamViewer Remote Control app on Android. The fixed version for current installs is 15.83 or later.
If you are stuck on an older branch, TeamViewer published matching maintenance builds, including 15.64.10, 14.7.48868, and platform-specific 13.2 builds. Check bulletin TV-2026-1011 for the exact build for your operating system and branch rather than guessing, because the right legacy build differs by platform.
Code execution, where possible, runs with the viewer process’s permissions. That is an important detail: it does not automatically mean SYSTEM on Windows or root on Linux and macOS. But a support technician’s workstation often holds credentials, VPN access, ticketing systems, and admin tools, so code running as that user is still a serious compromise.
The same bulletin fixed two more high-severity flaws
CVE-2026-111585 was not the only issue in TV-2026-1011. The same update cycle fixed two more high-severity client flaws, and updating to 15.83 covers all three at once.
CVE-2026-92372, also rated 8.8, affects the screen-image decoder in TeamViewer Full Client for Linux and macOS before 15.83. It involves a failure to validate incoming screen data against the destination buffer size, with a similar crash or code-execution outcome.
CVE-2026-92374, rated 7.8, affects the privileged helper tool used by TeamViewer Full Client and Host on macOS. It involves a timing issue and unsafe handling of symbolic links, and it can lead to privilege escalation on the Mac itself. That one is a local issue rather than a remote-session attack, but it belongs in the same update round for any Mac fleet.
How to check your version and update
On a Windows or Mac client, open TeamViewer, go to Help and then About TeamViewer, and compare the version number against 15.83. On Linux, check the installed package version with your package manager. On Android, open the Remote Control app’s page in the Play Store and confirm you are on the latest release. If the number is lower than 15.83, update from TeamViewer’s official download page or through your normal managed deployment, and then re-check the version after the install finishes.
For IT teams, the harder part is coverage. The main workstation build is easy to patch, but vulnerable copies hide in places that normal update routines miss: portable TeamViewer on USB sticks and shared folders, old installs on rarely used support laptops, and Android devices used for on-call remote control. Inventory all four — Full Client, Host, Portable, and the Android Remote Control app — before you declare the fleet patched.
Also check machines that are not managed by your usual software deployment. Contractors, vendors, and MSP technicians who connect into your environment bring their own viewers, and a vulnerable viewer on their side is still a risk to their access into your systems. If your support agreements allow it, require a minimum client version before granting remote sessions.
What to do if you already connected to an untrusted machine
TeamViewer reported no known active exploitation when the bulletin was published, so there is no reason to assume a past session means a compromise. Still, if a technician on a pre-15.83 client recently connected to a machine they did not trust, and that workstation has since crashed repeatedly or behaved oddly during sessions, treat it as worth investigating rather than ignoring.
Update the client first, then review the workstation for unexpected processes, new scheduled tasks, and unusual outbound connections around the time of the session. If anything looks off, isolate the machine and hand it to your incident-response process. For most users, though, the correct response is simple: patch, verify the version, and carry on.
Why this flaw is a useful reminder for support teams
Remote support tools are trusted by design. They cross network boundaries, they run with meaningful privileges, and they are used precisely when something is already wrong on the other end. That combination makes the viewer a valuable target, and CVE-2026-111585 is a reminder that approving a session is not the same as trusting the other side’s data.
Session approval, passwords, and two-factor authentication all protect who can connect. They do not protect the viewer from malformed screen data sent after the connection is established. That is why keeping the client itself patched matters as much as controlling who gets in, and why a flaw that reverses the expected direction of risk deserves attention even though it needs an active session to trigger.
Remote-access flaws have been a recurring theme this year. The AnyDesk AnyPwn flaw showed how a remote desktop tool can become an entry point, the BeyondTrust zero-day hit remote support appliances used by enterprises, and the Ivanti Connect Secure exploit chain reminded everyone that VPN and remote-access gateways are prime targets. TeamViewer’s bulletin fits the same pattern: the tools that let people in remotely need the most disciplined patching.
Frequently asked questions
Do I need to update if I only use TeamViewer to help family members?
Yes. The fix is free and quick, and the risk scenario is exactly a session with a machine you do not control. If you connect to a relative’s computer that turns out to be compromised, a vulnerable viewer puts your own computer at risk. Update to 15.83 or later before the next session.
Is CVE-2026-111585 being exploited in the wild?
TeamViewer said it was not aware of active exploitation when bulletin TV-2026-1011 was published. That can change, and public technical details now exist, so the safe assumption is that the window between disclosure and patching is the time to close.
Does the flaw affect TeamViewer Host or QuickSupport?
For CVE-2026-111585 itself, the listed affected products are the Full Client, Windows Portable, and the Android Remote Control app. The sibling macOS privilege-escalation flaw CVE-2026-92374 does affect Host on macOS, so Mac deployments should still update both components.
What if I cannot upgrade to 15.83 yet?
Use the matching legacy maintenance build from bulletin TV-2026-1011 for your branch, such as 15.64.10 or 14.7.48868 where applicable. Until you can update, avoid remote sessions with machines you do not trust from a vulnerable viewer, and prioritize the workstations used for support work.
How can I tell whether a crash was caused by this flaw?
You cannot tell from a single crash alone. Repeated viewer crashes during sessions with a specific remote machine, especially on a pre-15.83 client, are a reason to update immediately and investigate the workstation, but a crash by itself is not proof of exploitation.