TeamViewer has patched a bug, CVE-2026-111585, that reverses the usual direction of a remote session: the machine being controlled can attack the machine controlling it. The flaw scores 8.8 out of 10, and the fix is in version 15.83. There is no workaround.
In TeamViewer's terms the viewer is the computer that connects and takes control, and the host is the machine it controls. Normally the host carries the risk, handing over its screen and input to whoever connects. Here the risk runs the other way. A malicious or compromised host can crash the viewer's TeamViewer and, on at least one platform, run code on the viewer's computer. It only works once the viewer has started a remote-control session to that host, but after that it needs no password and no click beyond accepting the session, and it works in the default configuration.
The weak point is a size the viewer is willing to trust. At the start of a session the host tells the viewer how large its screen image is. The viewer uses that number to allocate memory for incoming screen data, but the calculation can overflow, so it reserves too little. Screen data that arrives afterward gets written past the end of that buffer. Omri Dar of the security firm Remedio, who published the technical write-up on October 29, summarized the setup: "the attacker is the host and the victim is the viewer."
At a minimum the overwrite crashes the viewer's session, and the host can trigger the crash again whenever it likes. On Windows, Remedio took it further, getting past the operating system's built-in exploit defenses and running code of its choosing inside the viewer. That demonstration used a stand-in on the host to supply part of the attack data, so it is not yet an exploit carried end to end over the network. Code execution was shown only on Windows. The write-up does not cover whether macOS, Linux, or Android behave the same way, and TeamViewer says only that code execution is possible depending on the platform.
The flaw affects the TeamViewer Full Client on Windows, Linux, and macOS, the Windows Portable edition, and the Android Remote Control app, in every version before 15.83. That includes 15.82, the security update TeamViewer shipped in September, so patching last month did not close this hole.
One detail to check against your inventory: TeamViewer's bulletin for CVE-2026-111585 lists the Full Client, Portable, and Android app, but not the Host product. The same 15.83 release fixes two other flaws that do affect the Host, including a separate code-execution bug on Linux and macOS, so Host installs need updating regardless. A companion bulletin the same day, TV-2026-1012, patches six more flaws in TeamViewer's Remote Management add-ons, which arrive by automatic update.
What to do
Update to 15.83 or later. The fixed builds for older supported branches are in TeamViewer's bulletin table, and that update is the only remediation on offer.
The practical consequence is that your technicians' workstations are now in scope. If a help-desk operator connects out to an endpoint an attacker already controls, the endpoint becomes the thing attacking the operator's machine. That inverts the usual model, where you harden the hosts receiving connections and treat the support console as trusted. Managed service providers reaching into customer machines and support staff connecting to user-reported problem boxes are exactly the viewers exposed here.
When it published the fix TeamViewer said it knew of no attacks exploiting the flaw. It is not in CISA's Known Exploited Vulnerabilities catalog as of the October 29 listing, and Remedio reported none in the wild and did not release exploit code.
Top comments (0)