TeamViewer CVE-2026-111585 Turns the Host Into the Attacker and the Technician Into the Target

TeamViewer published nine CVE fixes on October 27 and three separate version numbers to go with them. Client 15.83 closes six. The other three live in the Remote Management add-ons and need Monitoring 26.10.1 or Patch Management 26.9.1, numbers that never appear in the client's About box. The worst bug in the set, CVE-2026-111585, also reverses who carries the risk in a support session: the machine being controlled runs code on the machine doing the controlling.

This matters to you if your team connects out to other people's computers for a living, or if one person at your company is the one who does it. A help-desk technician, an owner who fixes the office printer remotely, a managed service provider logging into a client network. The viewer, not the host, is the asset at risk here. If your remote support runs on ScreenConnect, AnyDesk, Splashtop, RustDesk or Intune Remote Help, these nine CVEs are not yours and you can stop reading. If you only ever receive sessions and never start one, CVE-2026-111585 is not yours either, though the macOS privilege-escalation bug in the same bulletin still is. Everyone else has a patch to apply on the wrong machine from the one they expected.

What the viewer trusts

A remote-control session opens with the host describing its own screen. The viewer takes those dimensions and allocates a buffer to draw into. TeamViewer's bulletin TV-2026-1011 records the result as CWE-190, an integer overflow or wraparound in the remote-control screen processing component, scored CVSS 8.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.

The arithmetic is the whole bug. SecurityWeek's account of the Remedio research describes a host announcing a 32768 by 32768 surface at 32 bits per pixel. That multiplication wraps a 32-bit size calculation, so the allocation comes back far smaller than the data that follows, and the writes run off the end of it. Remedio researcher Omri Dar reported that the corrupted object is live and in use: its first field is a pointer the viewer calls through, so overwriting it redirects execution. In the published demonstration that pointer was aimed at WinExec.

Two details decide whether this reaches you in practice. First, the vulnerable path runs only when no hardware video decoder is available, and a host can simply refuse codec negotiation to force the software path. The attacker chooses. Second, Remedio states the surface is reachable in the default configuration, and the only user action required is the one the technician was going to take anyway: starting the session. There is no second click, no credential to steal, no payload to talk anyone into running.

TeamViewer says it has no evidence of exploitation at publication, and the CVE is absent from the CISA Known Exploited Vulnerabilities catalog as of catalog version 2026.10.30. A working proof of concept is on GitHub. Treat that gap as the window you are patching inside, not as reassurance.

Nine CVEs, three version numbers

The reason this one is worth a careful hour rather than a quick update is that the fix is not one fix. TV-2026-1011 covers the three client bugs: CVE-2026-111585 above, CVE-2026-92372 (an out-of-bounds write in the screen-image decoder on Linux and macOS, also triggerable by opening a malicious .tvs session recording), and CVE-2026-92374 (a TOCTOU race in the macOS privileged helper that installs a package as root). All three close at client 15.83.

Bulletin TV-2026-1012 is the one people will miss. It carries six local privilege-escalation CVEs in the Remote Management add-ons. Three of them resolve with the client update: CVE-2026-92375, CVE-2026-92377 and CVE-2026-111583. The other three do not:

The three that the client update does not touch

• CVE-2026-92376, improper authentication in the Windows Monitoring IPC broker (ITbrain_Monitoring_Service.exe). Fixed in Monitoring 26.10.1.
• CVE-2026-111582, improper privilege management in the Windows Monitoring installer (MonitoringInstaller.exe). Fixed in Monitoring 26.10.1.
• CVE-2026-111584, improper privilege management in Patch Management for Windows (RM_PatchManagement_Service.exe). Fixed in Patch Management 26.9.1, or 24.12.5 if you are still on the legacy 14.7 client.

The first of those three deserves its own line. CVE-2026-92375 is an access-control failure in the IPC between the client and the Monitoring service, so both ends need updating; moving one and leaving the other still leaves it open. TeamViewer notes that the Remote Management components arrive through auto-update, which usually means the fix lands without anyone asking for it. Usually is doing a lot of work in that sentence on a machine that has been asleep, offline, or pinned to an old branch for a quarter.

Legacy branches get their own numbers: 15.64.10 on Windows 7 and 8, 14.7.48868 across Windows, Linux and macOS, and a set of 13.2 builds that differ per platform. If your inventory report says "TeamViewer, current" and nothing else, it has not answered the question.

Here is the check that does. Run it on the machines your technicians use, not only on the endpoints they connect to.

# Inventory TeamViewer client and Remote Management component versions.
# Target versions: client 15.83, Monitoring 26.10.1, Patch Management 26.9.1.
# Legacy branches: 15.64.10 (Win 7/8), 14.7.48868, 13.2.x per platform.

$uninstall = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $uninstall -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -like 'TeamViewer*' } |
  Select-Object DisplayName, DisplayVersion, InstallLocation |
  Format-Table -AutoSize

# The add-on services carry their own version line and their own update path,
# so the client number above does not answer for them.
$roots = 'C:\Program Files (x86)\TeamViewer', 'C:\Program Files\TeamViewer'
'ITbrain_Monitoring_Service.exe','MonitoringInstaller.exe','RM_PatchManagement_Service.exe' |
  ForEach-Object {
    Get-ChildItem -Path $roots -Filter $_ -Recurse -ErrorAction SilentlyContinue |
      Select-Object @{n='Component';e={$_.Name}},
                    @{n='FileVersion';e={$_.VersionInfo.FileVersion}},
                    FullName
  } | Format-Table -AutoSize

On macOS and Linux the client version is one command each: defaults read /Applications/TeamViewer.app/Contents/Info.plist CFBundleShortVersionString, or teamviewer --version. The macOS daemon to care about is MonitoringDaemon; on Linux it is teamviewer-monitoringd.

Where large organizations put the support session

Banks and other heavily regulated enterprises solved this class of problem years ago, and not by patching faster. They solved it by deciding that the workstation which reaches into other systems does nothing else. The support session runs from a dedicated administrative host: a locked-down desktop or jump server with no mail client, no browsing, no document editing, no credential vault mounted, and no privileged token cached on it. If that host is compromised in the middle of a session, the attacker lands on a machine that holds nothing and reaches nowhere interesting.

That control is normally sold as protection against a stolen admin password. CVE-2026-111585 shows the other thing it buys: it bounds what a malicious host can reach when the exploit runs on the technician's side. The expensive part of the enterprise version is the infrastructure, the hardened image, and the team that maintains all of it. The idea underneath costs nothing.

The small-business translation is a second machine, or a virtual machine on the one you have, used for one purpose. It runs the support client and nothing else. It signs in with a standard local account, not a domain administrator and not the account that opens your email. It has no saved passwords in a browser, because it has no browser profile worth the name. It holds no customer files. Setting that up is an afternoon, and it is the same afternoon that fixes the next remote-access CVE you have not read yet.

What to change this week

• Update the client to 15.83 on every machine that starts sessions, starting with the technician workstations. These are usually the last machines in an inventory report and the first ones that matter here.
• Confirm the Monitoring and Patch Management services actually moved to 26.10.1 and 26.9.1. Auto-update is the mechanism, not the evidence.
• Move outbound support sessions onto a dedicated host or virtual machine with a standard-privilege account. No vault, no mail, no client data.
• Write down which hosts your team is allowed to connect out to. The product's allow list governs who may connect in to you; nothing filters where you may connect out. That direction is a process control, and an unsolicited request to connect out to an unknown ID should end the conversation.
• Stop opening .tvs session recordings from anyone outside your team until the Linux and macOS clients are on 15.83. CVE-2026-92372 treats that file as hostile input.

What a failed attempt leaves behind

Memory corruption is unreliable before it is reliable. An attacker tuning this against an unpatched viewer crashes it, often several times, and Windows records every one of those crashes. That makes the denial-of-service half of CVE-2026-111585 the most useful detection you have for the code-execution half.

# Pull Windows Error Reporting records for TeamViewer client crashes.
# Repeated faults in the same session, or any fault tied to an unfamiliar
# partner ID, are worth a look at the connection log beside them.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    Id        = 1000, 1001
    StartTime = (Get-Date).AddDays(-30)
} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'TeamViewer' } |
  Select-Object TimeCreated, Id,
                @{n='Fault';e={ ($_.Message -split "`r?`n" | Where-Object { $_ })[0] }} |
  Sort-Object TimeCreated

# Then line those timestamps up against the outbound sessions the client logged.
Select-String -Path "$env:APPDATA\TeamViewer\Connections.txt",
                    'C:\Program Files (x86)\TeamViewer\Connections_incoming.txt' `
              -Pattern '\d{4}-\d{2}-\d{2}' -ErrorAction SilentlyContinue |
  Select-Object -Last 40 -ExpandProperty Line

A crash with no session around it is a bug. Three crashes inside one session with a partner you cannot account for is an incident, and the connection log is where you get the partner ID and the start time to hand to whoever asks next. Forward both of these to wherever your logs already go. A technician workstation is usually the least monitored machine in a small environment and the one with the broadest reach, which is a poor combination to discover after the fact.

Patch the technician's laptop before you patch the fleet

Nine CVEs across two bulletins, and the one that can run code with no credentials lands on the person doing the helping. Update the client to 15.83 on the machines that start sessions today, verify the two add-on services separately because the client number will not tell you, and spend the afternoon that moves outbound support onto a box that holds nothing. The last step is the one that still works when the next advisory arrives for a different product. If you want a second opinion on how your team's remote access is arranged, that is a conversation worth having before the advisory, not after.