Remote access tools are built around one direction of trust. When an IT admin or support engineer opens a session, the security controls (authentication, permission prompts, access rules) exist to protect the remote machine from the viewer. The technician’s workstation is treated as the safe side, a clean vantage point looking into a machine that may be broken, unmanaged, or hostile.
CVE-2026-111585 breaks that assumption. The data flowing back from the remote host can be used to attack the viewer. The flaw sits in TeamViewer’s remote-control screen processing and carries a CVSS 3.1 score of 8.8. A malicious or compromised host can trigger an integer overflow that leads to a heap-based buffer overflow, which can crash the client or run arbitrary code on the technician’s machine.
What is CVE-2026-111585?
Omri Dar of the security firm Remedio published the research in late October 2026. It describes a memory-safety failure in the screen-decompression pipeline. The bug has nothing to do with cryptography or session negotiation. It is an arithmetic error in how the TeamViewer client works out how much memory to allocate for incoming screen buffers.
An attacker who controls the host sends crafted screen geometry and tile updates. That pushes the viewer into a state where its idea of the image’s dimensions is far larger than the memory it actually reserved. The mismatch is a classic heap corruption primitive, and a dangerous one.
How remote screen reconstruction works
A remote desktop client does not usually receive a video stream. It receives graphical primitives, compressed pixel blocks, and dimensional metadata. At the start of a session the host reports its screen geometry, color depth, and display parameters. The viewer parses that metadata, calculates the frame buffer size, allocates the memory on the heap, and decodes later updates into it.
That pipeline only works if the validation math and the real memory boundaries agree. If the host lies about dimensions, or the viewer miscalculates their product, the security boundary is gone.
The root cause: a 32-bit integer overflow in CBitmapBuffer (CWE-190)
The overflow happens while sizing TeamViewer’s internal CBitmapBuffer object. In C and C++, the size of a two-dimensional buffer is width times height times bytes per pixel, often with extra padding for alignment. With fixed-width 32-bit unsigned integers, the result can never exceed 4,294,967,295. Anything larger wraps around modulo 2^32 and comes out far smaller than the true value.
A worked example of the wrap-around
Remedio’s scenario starts with a host reporting a 32,768 by 32,768 pixel display at 32-bit color depth, which is 4 bytes per pixel. According to Dar’s analysis, TeamViewer adds 16 units of padding during its stride and size calculations, so both dimensions become 32,784.
The row stride is computed safely: 32,784 pixels times 4 bytes gives 131,136 bytes per row. The trouble starts with the total size. Multiplying 131,136 by the adjusted height of 32,784 gives 4,299,162,624 bytes, roughly 4 GB.
That is more than the 32-bit maximum, so a 32-bit multiplication wraps and returns exactly 4,195,328 bytes, about 4 MB. The application asks the operating system for 4 MB of heap, believing it has reserved 4 GB. The allocator hands back a valid pointer to a 4 MB block, and the client goes on decoding screen updates as if it had a 4 GB canvas.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →Why casting the result to 64 bits does not fix it
Many developers assume that storing the product in a 64-bit size_t or uint64_t prevents this kind of overflow. In C and C++ it does not, because of integer promotion rules. If width, height, and bytes per pixel are all 32-bit integers, the compiler multiplies them in 32-bit arithmetic. The wrap-around happens before the assignment, so the 64-bit variable just receives the already corrupted value, zero-extended.
The fix is to cast at least one operand to a 64-bit type before the multiplication, or to use checked-arithmetic functions that detect the overflow and abort the allocation.
From undersized allocation to heap buffer overflow
The overflow becomes a memory corruption bug during decoding. Remote desktop protocols save bandwidth with tile-based or region-based updates. Instead of resending a 4 GB screen every frame, the host sends a small rectangle, say a 64×64 pixel block for a changed icon or a moved cursor, plus the X and Y coordinates where it belongs.
The malicious host sends a perfectly valid small tile and gives it a Y-coordinate deep inside the imaginary 4 GB canvas. The viewer computes the write offset as Y times the row stride plus the X offset. Because it believes the buffer is 4 GB, that offset can be enormous, and the real allocation is only 4 MB. The decoder writes the tile far past the end of the heap chunk and overwrites whatever objects or allocator metadata sit next to it.
Why the validation checks still pass
The decoder’s own checks do not catch this. A careful decoder confirms that each tile fits inside the declared logical boundaries of the screen, and here it does: the tile sits inside the 32,784 by 32,784 grid. The check compares the rectangle against the declared image dimensions, not against the capacity of the memory behind them.
That gap between logical geometry and physical allocation is what makes the out-of-bounds write succeed. The application trusts its own flawed arithmetic, then trusts the bounds derived from it.
From crash to code execution
In a complex application like a remote desktop client, a heap overflow can do much more than crash the process. A denial of service is the most common result, but the real risk is heap exploitation. Allocators such as ptmalloc on Linux, the Windows Heap Manager, mimalloc, and jemalloc keep metadata next to user chunks to track free lists, chunk sizes, and allocation state. Overwriting that metadata lets an attacker steer the allocator into returning overlapping regions or writing attacker-chosen data to chosen addresses during later allocations and frees.
Remedio’s proof of concept on Windows
Remedio went past a crash and demonstrated a path to arbitrary code execution on Windows. The researchers groomed the heap with specific sequences of allocations and deallocations so that a sensitive C++ object holding function pointers or virtual method tables landed directly next to the undersized bitmap buffer. When the overflow hit, the tile data overwrote a function pointer in that neighbor. Later, when the client called a method on the corrupted object, it followed the attacker’s pointer and redirected the instruction pointer to a location the attacker picked.
This had to get past Windows exploit mitigations. Control Flow Guard (CFG) limits indirect calls to a set of valid targets, and Data Execution Prevention (DEP) marks the heap and stack as non-executable. The demonstration suggests the researchers got around both, probably by overwriting a pointer with the address of a legitimate function that does something useful (a technique similar to Counterfeit Object-Oriented Programming, or COOP) or by corrupting a callback mechanism CFG does not closely watch.
Proof of concept versus weaponized exploit
A controlled proof of concept is not a weaponized network exploit. The published research used a host-side hook to deliver specific attack data reliably and to stabilize the heap layout during decoding. Turning the primitive into a reliable zero-click exploit delivered purely through standard TeamViewer protocol messages would take a great deal of network-based heap grooming. That is theoretically possible, but hard in practice, and it depends heavily on the allocator and OS version on the victim’s machine.
Who is at risk: MSPs and enterprise IT support
Managed Service Providers (MSPs) and enterprise support teams have the most to worry about. The usual security model treats the technician’s workstation as a hardened, privileged asset and the client machines as untrusted endpoints. Support engineers regularly connect to machines owned by customers, contractors, and remote employees to troubleshoot, remove malware, or change configurations.
If one of those machines is deeply compromised by an advanced threat actor, or if a malicious insider builds a honeypot, connecting to “fix” it hands the attacker a route into the support organization’s infrastructure.
The user interaction requirement (UI:R)
The CVSS vector includes UI:R because the technician has to start the remote session. In practice that requirement is the software’s normal use. A technician cannot do the job without connecting. Once the session is live, ordinary protocol traffic triggers the bug. The attacker does not need the technician to download an executable, open a booby-trapped document, or click a phishing link. The payload arrives through the legitimate, authenticated, encrypted session itself, because the viewer parses complex, externally supplied data without treating it as untrusted input.
Affected versions and the TeamViewer 15.83 patch
TeamViewer fixed the flaw in version 15.83 and published security bulletin TV-2026-1011 in late October 2026. The update covers the Full Client on Windows, Linux, and macOS, the Windows Portable edition, and the Android Remote Control app.
The Portable edition deserves attention. Portable copies often live on USB drives or network shares, outside normal deployment and patch management, so admins need to hunt them down by hand. TeamViewer also released fixed builds for older maintenance branches (15.64, 14.7, and 13.2), so organizations on older operating systems or strict change-management cycles can patch without moving to a new major version.
Other vulnerabilities fixed in the October 2026 bulletin
CVE-2026-111585 was not the only issue in this update cycle. The same bulletin covers several other high-severity flaws:
CVE-2026-92374 (CVSS 7.8) affects the privileged helper tool used by the Full Client and Host on macOS. It combines a time-of-check to time-of-use (TOCTOU) race condition with improper symbolic-link handling. A local attacker with low privileges could bypass package verification and escalate to root.
CVE-2026-92372 is an out-of-bounds write in the screen-image decoder on Linux and macOS clients. It can be triggered during a live session, and also by getting a user to open a crafted .tvs session recording file.
Reading the whole advisory matters. Fixing only the integer overflow would leave the environment exposed to the adjacent memory corruption and the local privilege escalation.
Lessons for developers: preventing integer overflow and heap corruption
This bug is a reminder of what manual memory management and unchecked arithmetic keep producing in C and C++. Any dimension, length, or size received from a network peer has to be treated as hostile.
Use checked arithmetic
Safe arithmetic is the first line of defense. Compiler intrinsics such as __builtin_mul_overflow in GCC and Clang, or SafeInt libraries on MSVC, detect wrap-around and stop execution before an invalid allocation request goes out.
Validate against physical capacity
Validation also has to look at real memory. Checking that a rectangle fits inside the logical image is not enough. The decoder must confirm that the calculated offset plus the length of the incoming data stays within the capacity of the allocated buffer. Logical protocol geometry and physical allocation size need to stay separate, and the physical limit has to be enforced at the moment of the write.
Fuzz with extreme values
Coverage-guided fuzzing combined with AddressSanitizer (ASan) is the best way to find these edge cases. Fuzzers should generate extreme dimensions, zero-sized regions, and malformed tile coordinates, so the allocator and decoder get pushed into the corners where overflows and bounds-checking failures hide.
How to protect your organization
Start by updating every TeamViewer client to version 15.83, or to the fixed build for your legacy branch. That means querying endpoint management systems, checking build numbers by hand on critical admin workstations, and searching for unmanaged portable executables.
Until the patch is everywhere, set strict policies for remote connections to untrusted or external environments. Network segmentation and endpoint detection and response (EDR) add a second layer against shellcode execution and secondary payloads, but they cannot reliably stop the initial memory corruption or the application instability that follows.
Conclusion
CVE-2026-111585 shows that the direction of a connection does not set the direction of the risk. A remote session exchanges complex, executable state in both directions, and the machine rendering the display is as exposed to incoming data as the machine producing it. Every coordinate and compressed block that crosses the network should be treated as potentially hostile, and viewer software should be written on the assumption that the remote host may already be compromised.
