Most people think of remote-access risk as one-way. You worry about someone getting into the machine you are controlling. You don't usually worry about that machine turning on you. A TeamViewer vulnerability disclosed this week covers exactly that second case: a remote computer that is malicious or already compromised can use the screen data it sends to attack the person viewing it.
The flaw is tracked as CVE-2026-111585, and The Hacker News reports a CVSS score of 8.8. It is fixed in TeamViewer 15.83. Every client version before 15.83 is affected, including 15.82. TeamViewer says it knew of no active exploitation when it published, and The Hacker News notes the bug was not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of its October 29 listing. There is also no workaround. If you run TeamViewer, you need to update.
The Bug: Screen Data That Doesn't Add Up
When you connect to a remote machine, your TeamViewer client (the "viewer") keeps receiving data that describes the other machine's screen, then decodes and draws it. According to the National Vulnerability Database entry, which TeamViewer's PSIRT (its product security incident response team) published on October 27, the code that handles this screen data contains an integer overflow.
Here's what that means. Software stores numbers in fixed-size slots. If a calculation produces a value too large for its slot, the number "wraps around" and becomes much smaller than intended. When that wrapped number is used to decide how much memory to set aside, the program can reserve too little space and then write more data into it than it can hold. At best the program crashes. At worst, an attacker who controls the incoming data can shape what gets written past the end of that memory and turn the crash into code execution.
NVD describes those two outcomes for this bug: a malicious remote host "may" cause a denial of service or "potentially" execute code with the privileges of the viewer. The careful wording matters. Whether a crash can be turned into code execution depends on the platform and the memory protections it has. The Hacker News says Remedio demonstrated code execution only on Windows, using a stand-in on the host for part of the attack data, and that the write-up does not cover macOS, Linux or Android.
Who Is Exposed
NVD lists the TeamViewer Full Client, the Portable client and the Remote Control App before 15.83 as affected. The Hacker News breaks that down by platform:
- Full Client on Windows, Linux and macOS
- Portable client on Windows
- The Android Remote Control app
One condition limits the risk: the attack requires the user to start a session to the attacker-controlled host. An attacker cannot reach out and hit a viewer that is sitting idle. Someone has to connect to the bad machine first.
That condition is narrower than it sounds, though, because of who connects to unfamiliar machines all day. Help-desk technicians, managed service providers and IT staff who support remote users regularly connect to computers they don't control and can't vouch for. Some of those computers will be infected. A scam caller can tell a target to "let me show you something on my screen" and get them to connect. And a machine an attacker has already taken over becomes a trap for the next administrator who logs in to investigate. In all of these cases the viewer is often the more valuable machine: it belongs to the person holding admin credentials, saved sessions and access to many other systems.
What Else Is in the Bulletin
CVE-2026-111585 is one of several fixes. TeamViewer's security bulletin TV-2026-1011, issued October 27 and updated October 28, is rated priority "Important," with CVSS scores up to 8.8. It lists three CVEs:
- CVE-2026-111585: the screen-processing integer overflow described above.
- CVE-2026-92374: a time-of-check to time-of-use (TOCTOU) privilege-escalation flaw on macOS, fixed in 15.83. A TOCTOU bug is a race condition. Software checks that something is safe, and in the short gap before it acts on that check, an attacker swaps the thing out. Here that could let a local user gain more privileges than they should have.
- CVE-2026-92372: an out-of-bounds write in the screen-image decoder of the Full Client for Linux and macOS, fixed in 15.83. The bulletin says it can allow remote code execution and requires user interaction. It is rated CVSS 8.8.
The Hacker News says that, along with the remote-host flaw, version 15.83 fixes two other high-severity vulnerabilities. It also points to a companion bulletin, TV-2026-1012, which fixes six flaws in TeamViewer's Remote Management add-ons, delivered by automatic update. Organizations that use those add-ons should read that bulletin separately.
According to The Hacker News, the security firm Remedio published a technical account of the issue on October 29, and reported no attacks in the wild and released no exploit code. This article does not cover technical exploitation details, and defenders don't need them to act. The fix is the same whatever those details are.
Quick Answers
Is this being exploited? TeamViewer said it was not aware of active exploitation when it published the bulletin. The Hacker News notes the flaw was not in CISA's KEV catalog as of its October 29 listing. Now that a fix and public research are both out, the usual pattern is that attackers study the patch, so the time to update is before that happens.
Is there a workaround? No. The Hacker News reports that updating to 15.83 is the only fix.
We're on an older major version for licensing reasons. Are we stuck? Not necessarily. TeamViewer's bulletin lists fixed legacy builds, including 15.64.10 (Windows 7 and 8) and 14.7.48868 (the 14.7 line on Windows, Linux and macOS). It also lists fixed 13.2 builds. If your organization stays on an older line, check that you are on at least the fixed build for that line.
Do I need to patch the machines I connect to? This CVE affects the viewer, the side doing the controlling. Patching the viewer is what closes it. The other fixes in the bulletin, and the separate Remote Management bulletin, may apply to other installations, so updating every TeamViewer install you have is the simplest approach.
What It Means for Defenders
Who is affected: Anyone running the TeamViewer Full Client (Windows, Linux, macOS), the Windows Portable client, or the Android Remote Control app at any version before 15.83. That includes 15.82. Mac users are also exposed to the separate TOCTOU privilege-escalation flaw (CVE-2026-92374), and Linux and macOS users to the decoder flaw CVE-2026-92372, which 15.83 fixes too.
What to patch:
- Update every TeamViewer client to 15.83 or later. Do support staff and MSP technician workstations first, since they connect to untrusted machines most often.
- If you are tied to a legacy line, confirm you are on at least 15.64.10 (Windows 7 and 8), 14.7.48868 (14.7 line) or the fixed 13.2 build for your platform, as listed in the TeamViewer bulletin.
- Update the Android Remote Control app on managed phones and tablets. Mobile devices are easy to miss in desktop-focused patch cycles.
- If you use TeamViewer Remote Management add-ons, review bulletin TV-2026-1012. It fixes six flaws in the add-ons, delivered by automatic update.
What to check:
- Portable copies. The Windows Portable client runs without being installed, so software-inventory and patch-management tools often don't see it. Look for old portable executables on technician USB drives, shared folders and download directories, and replace them.
- Shadow installs. Users and contractors who installed TeamViewer themselves may never update it. Your endpoint inventory should show every version in use, not just the ones IT deployed.
- Who connects to what. Until patching is done, technicians should be especially careful about connecting to machines they suspect are compromised. The attack depends on the viewer starting that session.
Mitigations: The sources list none other than updating. There is no configuration change that works around this bug. For CMMC and other compliance programs, record the update under your flaw-remediation process. If remote-access tools are not already a tracked asset class in your inventory, this is a good reason to make them one.
The broader lesson is about trust. A remote-control session is a two-way channel, and the side you think is in control still processes everything the other side sends. Treat the screens you connect to as untrusted input, because the software receiving them has to.