TeamViewer CVE-2026-111585: a malicious host can attack the support technician's viewer, fixed in 15.83

Seventy four days from report to fix, and the flaw runs the wrong way

Remedio, a security vendor, says it reported the integer overflow now tracked as CVE-2026-111585 to TeamViewer on 14 August 2026. TeamViewer's fix shipped, and its bulletin TV-2026-1011 was issued, on 27 October. That is 74 days (derived). On day 46 (derived), 29 September, TeamViewer shipped 15.82.6 with a bulletin for five other flaws, and Remedio says the vulnerable code was still present in 15.82.6 on Windows. A fleet that patched to 15.82.6 because of that bulletin, which this site covered in an earlier briefing, is therefore still in the affected range for this flaw.

The attack runs in the opposite direction to the one a help desk plans for. The usual worry is a hostile caller reaching a customer's machine. Here the machine being helped attacks the helper. TeamViewer's bulletin says the flaw "may allow a malicious remote host to cause a denial of service or, depending on the platform, potentially execute arbitrary code" with the privileges of the viewer, and that exploitation requires a user to set up a session to a host the attacker controls or has compromised. TeamViewer scored it 8.8 (High) and says it was not aware of active exploitation at the time of publication.

This briefing was built from TeamViewer's bulletin, the CVE and NVD records and CISA's exploited vulnerabilities catalogue, Remedio's write up and TeamViewer's release notes, all read between 11:37 and 11:50 GMT on Friday 30 October 2026. SecurityWeek's report of 30 October, 4:44 AM ET (08:44 GMT, derived), was the pointer to them and is cited only for what it says. What the record does not establish: that anyone has exploited the flaw, that code execution works on any platform other than Windows, or that the full attack has been run end to end over a real network session. Remedio's own write up says its code execution demonstration used a stand in for one step, and the bulletin says only "potentially". The sections below set out what each source says, where they differ, and what a help desk or managed service provider should do about it.

Stated and not stated: the record, line by line

TeamViewer wrote the bulletin and, as the CVE numbering authority, the CVE record, so the two carry the same words and the same score. There is no difference between a vendor score and a CVE record score to report here: both are TeamViewer's. The NVD entry repeats TeamViewer's vector as a secondary score and was still marked "Awaiting Analysis" when read, so no independent score exists yet. "Not stated" below means not found in any of the pages read in full, not that the answer does not exist.

The direction of the attack, and what the attacker needs

A TeamViewer session has two roles, in Remedio's account: the host shares its screen, and the viewer displays it and sends back mouse and keyboard input. In this flaw the host is the attacker and the viewer is the victim. When a session starts, the host tells the viewer the size of the screen it will stream, and Remedio says the viewer uses those numbers to size an in memory pixel buffer for decoding incoming screen updates. Remedio found no upper limit on what the host may announce. In its example, 32768 by 32768 pixels at 32 bits per pixel, the size calculation wraps in 32 bits and allocates about 4 MB (4,195,328 bytes) for a surface of 4,299,162,624 bytes, so the buffer holds roughly a thousandth of what the rest of the code believes it has (derived). The updates then write past the end of it.

Zoom

Two details matter for a help desk. First, the host can push the viewer onto the vulnerable path. Remedio says the viewer uses this buffer only when it has no hardware video decoder for the session, and that a host that refuses to negotiate the video codecs forces it down that path. Whether a technician can stop that from the viewer side is not stated by anyone. Second, the attacker needs no foothold on the technician's machine. The bulletin scores privileges required as none. What the attacker does need is control of the other end, and a technician's job is to connect to other people's machines, some of which may already be compromised. That is our inference from the wording "attacker controlled or compromised", not a TeamViewer statement: a managed service provider that supports many customer machines has many such ends.

The user action is the session itself. Remedio's opening says "You don't have to click anything", and its impact section says the UI:R in the vector "reflects that the victim accepts the session". The bulletin says a user must establish the session. Read together, no file, link or attachment is involved in this flaw; the connection is the trigger. That is also why the usual advice about not opening unknown files does not help here.

Zoom

What was shown, and the stand in

Remedio says it crashed a stock Windows client in a clean and repeatable way over a normal session. That is the low end. At the high end it says it ran a program of its choosing on the viewer: the corrupted buffer is an object the viewer later calls through a pointer, overwriting the pointer redirects the call, and Remedio says it bypassed Control Flow Guard and DEP and routed the call to the Windows function WinExec. It says this ran on the shipping binaries of a client with its usual defences on.

The qualification sits in the next paragraph of its write up. In the demonstration, the corrupting bytes were placed by a host side hook standing in for the network payload, which Remedio says replaces only the step that prepares the heap. So what was shown is the corruption, the redirected call and the program launch, with one preparation step done by a hook instead of over the wire. Whether that step can be done reliably over a network session is not shown in what was read. The bulletin's "potentially" and "depending on the platform" are consistent with that gap. The versions Remedio lists as tested are all Windows builds, so code execution on macOS, Linux and Android rests on the bulletin's hedged wording alone.

Affected and fixed versions, and where the pages disagree

TeamViewer's fixed version is 15.83. The release notes for the 15.83 line on Windows, macOS and Linux are dated 27 October 2026 and name the build 15.83.3, so look for that build or later rather than the shorter number. The Android Remote Control app is 15.83.294. The bulletin also lists older lines that were patched separately, so an estate that still runs them does not need to jump to 15.83.

Three places where the pages do not line up, each a question to ask before trusting a spreadsheet built from them. Portable on the 15.64 line. The CVE record lists Portable 15.64.0 up to below 15.64.10 as affected, but the bulletin's fixed table has no Portable row for that line. It has a Host row for 15.64 on Windows 7 and 8 printed twice, which may be a copy error (inference). Host. The affected list names the Full Client, Portable and the Android Remote Control app, not the Host, yet the fixed table lists Host builds. That is consistent with the Host being fixed for the other flaws in the same bulletin, but the page does not say so. A host only machine is not the one under attack here, because the attack runs against the viewer. Release notes. The change logs name the fix as a "memory corruption vulnerability that could lead to application termination or RCE", not as an integer overflow, and the Android note for 15.83.294 carries no security line at all.

On the Android row the point is narrow. The bulletin says the Android app is fixed in 15.83 and links to the Play Store and an APK download, and the notes simply do not say so. A change log silent about a fix is a reason to confirm the build number on the device, not a sign the fix is absent.

Two siblings in the same bulletin round, and one earlier bulletin

The same bulletin covers two other flaws, and a second bulletin published the same day covers six more. CVE-2026-92372 is an out of bounds write in the screen image decoder of the Linux and macOS Full Client, scored 8.8, that the bulletin says can be exploited by a remote attacker supplying crafted screen image data in a session, or by persuading a user to open a specially crafted TeamViewer session recording (a .tvs file). The bulletin does not say who the remote attacker is in that case, but a session recording is a file, which makes it the one of the three that does not need a live connection to a hostile host. CVE-2026-92374 is a local privilege escalation to root on macOS, scored 7.8. Bulletin TV-2026-1012 covers six local privilege escalation flaws in the Remote Management add ons, scored 7.3 or 7.8, fixed through auto update to component versions 26.10.1, 26.9.1 and 24.12.5.

Do not confuse this with the earlier bulletin, TV-2026-1010, covered in our briefing. That one lists five different CVEs, one of them also about a crafted .tvs file on macOS and Linux (CVE-2026-92368). A session recording file is therefore a repeat entry on TeamViewer's list: two bulletins 28 days apart (derived, 29 September to 27 October). The bulletin for the earlier round and this one both say the flaws are fixed in the latest version, but they are different versions, and the earlier one does not contain this fix.

Zoom

Labels that are not controls

"Requires user interaction". UI:R sounds like a brake. Here the interaction is the thing a technician does a dozen times a day: start a session. The flaw is not behind a warning dialog or an unusual file. It is behind the product's normal mode of operation, as Remedio puts it, and Remedio says the surface is reachable in the default configuration. TeamViewer's pages do not address the default configuration.

"No known exploitation". TeamViewer says it was not aware of active exploitation "at the time of publication". The bulletin was last updated on 28 October. That is a statement about the vendor's knowledge on two named dates, not a statement about a technician's machine. A full technical write up of the root cause, with the vulnerable function's logic, was public from 29 October, so the situation can change. Neither TeamViewer nor Remedio publishes an indicator a defender could search for.

"Restrict clipboard and file transfer". This is the advice a help desk reaches for after a TeamViewer flaw, and it does not fit here. The bulletin names the remote control screen processing component, not clipboard, file transfer or drag and drop, and it offers no mitigation other than updating. Turning off those features is sensible hygiene for other reasons, but nothing read says it reduces exposure to this flaw, so it must not be reported as a mitigation. The screen is the one thing a viewer must always receive.

"Important" and "High". Important is TeamViewer's own priority, on a scale its index describes as running from low to critical, and High is the CVSS band for 7.0 to 8.9. Neither says whether your machines are reachable. For a managed service provider the answer is probably yes, and for a team that only receives support it probably is not, because the vulnerable code is in the viewer. That is our reading of the direction of attack, not a TeamViewer statement.

Method and interest. TeamViewer sells the product, wrote the bulletin, scored the flaw and chose the wording "potentially". Remedio sells endpoint configuration and vulnerability remediation software, publishes this research on its own site beside its product pages, and gains visibility from the finding. That does not make the analysis wrong, and TeamViewer's bulletin confirms the flaw, the score and the fix. It does mean the strongest claims, code execution on a fully up to date client and bypass of two exploit defences, come from the party that benefits from the attention and have not been independently reproduced in anything read. SecurityWeek, a trade outlet, reported the two without adding its own testing.

What to do, in the order worth doing

Technical details

These are the artifacts the primary sources print, copied as printed, with the source and the date read in each caption. TeamViewer's bulletin and TeamViewer's release notes print identifiers, vectors and version strings. Remedio's write up prints the size arithmetic and two excerpts of its reading of the vulnerable code. Neither prints an indicator of compromise, a detection rule, a log line, a setting or a command a defender could run, and none is invented here. This site leaves out the other geometry values Remedio gives for steering a buffer into a chosen heap size, because they help an attacker and not a defender, and it includes no exploit code.

CVE-ID
CVE-2026-111585
CVSS3.1 Score
Base Score 8.8 (High)
CVSS3.1 Vector String
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Problem type
CWE-190: Integer Overflow or Wraparound

TeamViewer Full Client (+ Portable version)
Prior V15.83 (Windows, Linux, macOS)
Legacy/Maintenance: V15.64 (Windows), V14.7 (Windows, Linux, macOS), V13.2 (Windows, Linux, macOS)
TeamViewer Remote Control (Android) prior V15.83

TeamViewer Full Client (Windows, Linux, macOS)   15.83
TeamViewer Portable (Windows)   15.83
TeamViewer Remote Control App (Android)   15.83
Teamviewer Full Client v15.64 (Windows 7 & 8)   15.64.10
TeamViewer Full Client v14.7 (Windows)   14.7.48868
TeamViewer Full Client v13.2 (Windows)   13.2.36231
TeamViewer Full Client v14.7 (Linux)   14.7.48868
TeamViewer Full Client v13.2 (Linux)   13.2.154008
TeamViewer Full Client v14.7 (MacOS)   14.7.48868
TeamViewer Full Client v13.2 (MacOS)   13.2.154007

Fixed a memory corruption vulnerability that could lead to application termination or RCE (Security Bulletin: TV-2026-1011).

The next block is Remedio's own arithmetic for the size calculation, taken from its Figure 1. It is the same calculation SecurityWeek summarises, and it explains why a surface that claims to be nearly 33,000 rows tall is backed by a buffer of about 31. For a defender it shows the scale of the mismatch, and it is why the crash is easy to reproduce. The last row is Remedio's label for the result.

DisplayParams: width = height = 0x8000 (32,768), bpp = 32
alignedWidth   width + 0x10   32,784
stride   (bpp × alignedWidth) >> 3   131,136 bytes   untruncated
intended bytes   stride × (height + 0x10) = 131,136 × 32,784   4,299,162,624   0x1_0040_0C00
allocated   intended mod 2^32   4,195,328 (~4.0 MB)   0x0040_0C00
rows claimed / held   height + 0x10 vs. allocated ÷ stride   32,784 / ~31   every row past the 31st is out of bounds

The two excerpts below are Remedio's reduction of what it says is the viewer's code, copied with its comments. The first shows the multiply that wraps. The second shows the bounds check that compares a screen rectangle with the declared size, not with the bytes actually allocated. They are root cause logic for a developer or a reviewer, not something a defender runs. Line breaks are normalised to one statement per line.

// 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)) );

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)

Windows   TeamViewer.exe (viewer)   15.80.6.0   Affected
Windows   TeamViewer_Desktop.exe (host)   15.80.6.0   Affected (delivery)
Windows   TeamViewer.exe (viewer)   15.82.6.0   Vulnerable constructor still present (observed)
All   Fixed build   15.83   Fixed

What to hunt and harden, in words. The viewer process is TeamViewer.exe on Windows, per Remedio's table. A crash of it when a session opens is the low end of the flaw. A program started by that process is what the WinExec route in Remedio's demonstration would produce (inference). Neither primary says either is logged or alerted by anything. The hardening is the update and the separation of the technician workstation, as in the checklist.

The question this leaves

TeamViewer says it is not aware of any exploitation, and it may be right. The flaw has been fixed in a build that has been available since 27 October, and the technical write up has been public since 29 October. So ask your own team one question. If a technician's TeamViewer had crashed three times running when connecting to one customer's machine last week, which log would show it, and who would look at it? If the honest answer is that nobody would, then the exposure is not only a version number. It is that the machine that fixes everyone else's computers is the one nobody watches.

Key facts