2026-10-30 13:58:07 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

TeamViewer CVE-2026-111585 深度分析

Ots安全

2026年10月30日 09:05
广东

去阅读

2026 年 10 月 27 日，TeamViewer 发布安全公告 TV-2026-1011，一次修掉三个客户端高危漏洞。两天后，Remedio 研究员 Omri Dar 公开了其中一条的完整技术细节，而这条的方向与多数人对远程控制软件的想象正好相反：出事的不是被接管的那台机器，是发起接管的那台。技术员连过去提供帮助，对端把一帧做过手脚的屏幕数据送回来，攻击者的程序就跑在技术员的电脑上。全程不需要受害者点任何额外的东西，也不需要拿到任何密码，动作只有接受会话这一项。

对 IT 支持台来说，这个前提几乎等于没有前提。本文按 TeamViewer 官方公告、CVE 记录与研究方 writeup 三方核对后展开，机制部分只讲成因与判定逻辑，不给可利用的构造参数。

已关注

关注

重播分享赞

关闭

观看更多

退出全屏

切换到竖屏全屏退出全屏

Ots安全已关注

分享视频

，时长00:29

0/0

00:00/00:29

切换到横屏模式

继续播放

[ ]

进度条，百分之0

播放

00:00

00:29

倍速

全屏

倍速播放中

0.5倍0.75倍1.0倍1.5倍2.0倍

超清流畅

继续观看

TeamViewer CVE-2026-111585 深度分析

观看更多

转载

TeamViewer CVE-2026-111585 深度分析

Ots安全已关注

分享点赞在看

已同步到看一看写下你的评论

视频详情

一、先看问题：编号、评分与两种口径

1.1 编号与评分

漏洞编号 CVE-2026-111585，问题类型 CWE-190（整数溢出或回绕），CVSS 3.1 基础分 8.8，向量 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H。官方公告与研究方给出的编号、评分与向量完全一致，这一项没有分歧。

需要提醒一处笔误：Remedio 页面标题写的是 CVE-2026-11585，而该页正文、引用的 cve.org 记录链接、NVD 条目与 TeamViewer 官方公告全部写作 CVE-2026-111585。以 111585 为准，引用时按这个编号走，否则检索不到记录。

1.2 时间线与处置窗口

2026 年 8 月 14 日报告给 TeamViewer 产品安全团队，10 月 22 日厂商接受并分配编号，10 月 27 日随 15.83 发布修复与公告 TV-2026-1011，10 月 29 日研究细节公开。从报告到修复 74 天，从公告到技术细节公开 2 天。

研究细节晚于补丁发布，这一点对防守方是有利的：补丁先落地，细节后公开，中间没有留出无补丁的公开窗口期。

1.3 官方口径与研究方实测并列

两处的严重程度表述并不相同，应并列看而不是二选一。TeamViewer 的官方描述是\"可能导致拒绝服务，视平台而定可能以查看端进程的权限执行任意代码\"，措辞保留了平台差异。Remedio 的实测则限定在 Windows：绕过控制流防护（Control Flow Guard）与数据执行保护（Data Execution Prevention），把调用转到 WinExec，执行攻击者选定的程序。

前者是厂商面向全部受影响平台给出的保守表述，后者是单一平台上的实测结果，二者不冲突。把厂商的保守措辞套到已实测的平台上会低估风险，反过来把单一平台的实测外推成全平台结论又会高估，两种读法都不可取。

1.4 同一公告里的另外两条

TV-2026-1011 共修了三条，本条只是其中之一：CVE-2026-92372 是屏幕图像解码器的越界写（CWE-123），影响 Linux 与 macOS，同为 8.8 分，官方称还可通过诱导用户打开特制的 .tvs 会话录制触发；CVE-2026-92374 是 macOS 特权助手的检查时间与使用时间（time-of-check time-of-use）竞态叠加符号链接处理不当，7.8 分，本地低权限可提权到 root。

CVE-2026-92372 与本条同属屏幕解码路径、同分、同修复版本，容易被认为是同一个洞的两个平台入口。但两者的 CWE 不同、平台范围不同、触发方式也不同，官方按两条独立列出，是否同源公开信息未说明，本文不作归并。

在野状态方面：TeamViewer 称发布时未发现在野利用，公开渠道无已确认的 PoC，EPSS 约 0.29%，未列入 CISA 已知被利用漏洞目录。这三项是同一时间点的快照，会随 PoC 公开而变，不能当作长期结论。

二、影响范围：你处在会话的哪一端

TeamViewer 自述装机量超过 25 亿台设备，这是厂商口径的营销数字，未获独立核实，本文只作背景引用。部署面广是这类漏洞需要快速响应的理由，却不能替代对自身资产的清点，真正决定风险的是自己环境里有多少个安装、它们处于会话的哪一端。

2.1 版本与平台

受影响的是 15.83 之前的 TeamViewer 完整客户端（含便携版）与 Android Remote Control App，覆盖 Windows、Linux、macOS；维护分支 15.64（Windows 7 与 8）、14.7 与 13.2 各有自己的修复构建号，第六章给出可照抄的清单。完整的具体版本矩阵放在处置章，这一章只给出判定维度。

2.2 组件路径是否可达

漏洞位于查看端的 CBitmapBuffer，只在会话没有可用硬件视频解码器时才启用。这是判断实际暴露面时的关键一环：是否走这条路径不由查看端单独决定，主机端拒绝协商视频编解码器即可把会话推上去。加固时不能假设\"我们的机器有硬解所以不受影响\"，这个开关有一半在对端手里。

2.3 那个用户交互由谁完成

CVSS 把这条记为 UI:R，依据是受害者需要接受会话。对普通用户，这确实是一道门槛；对 IT 支持台，接受会话就是岗位动作本身，一天要发生几十次，且往往由工单系统驱动而非人工判断。

这是本条最容易被误读的地方：UI:R 在评分体系里是减分项，但在支持台的语境下它不构成任何防护。评估自身风险时，应当按\"会话一定会发生\"来计算，而不是按\"用户可能被拦住\"来计算。

三、原因导致：一次乘法算出的两个数

3.1 三行算术

会话建立时，主机端会通过 DisplayParams 消息告知即将推送的屏幕几何，其中包含宽、高与色深（bits per pixel，每像素位数）。查看端用这三个数计算解码表面的字节大小并分配内存。缩减到关键的三行，逻辑是这样的：

stride    = (bpp * (width + 0x10)) >> 3;byteSize  = (uint32)(stride * (height + 0x10));   // 32 位乘法，回绕buf       = operatornew[]( (ulong)(stride * (height + 0x10)) );

乘积先在 32 位上算完并回绕，之后才被加宽成 64 位交给 operator new[]。加宽发生在回绕之后，所以分配到的字节数可以是回绕后的任意小值，而 stride、声明宽度与声明高度都保留了完整未截断的值。

图 1：CBitmapBuffer 构造函数的算术与两个分岔的结果，本文绘制的机制示意图，依据 Remedio 公开的尺寸计算过程。

3.2 边界检查读的是另一个数

如果解码器把每笔写入对照真实分配字节数校验，上面这个回绕不会造成后果。行程编码（run-length encoding）解码器确实做了校验，但对照的是另一个数：

if ((D_height < y2) || (D_width < x2)) return\"invalid rectangle\";// D_width / D_height 是声明宽高，未经截断// 否则对 y 在 [y1, y2) 内：写入 base + y * stride + (x * bpp >> 3)

覆盖整块表面的矩形 (0, 0, 32768, 32768) 能通过这项检查，因为声明宽高就是这么大。写入地址按 stride 逐行推进，而缓冲区只够放约 31 行，第 32 行之后的每一行都落在分配之外。

整个漏洞可以归纳为一句话：分配与守卫它的检查读了两套不同的算术。排查时如果只盯着崩溃点，容易误判为解码器缺少边界检查，实际上边界检查存在，只是它问的对象不对。

3.3 两组尺寸的复算

先看一组大尺寸：width = height = 0x8000（32,768）、bpp = 32。按上面的公式：对齐宽度为 32,784，stride 为 131,136，应有字节数 131,136 乘 32,784 等于 4,299,162,624，对 2 的 32 次方取模后为 4,195,328 字节（约 4.0 MB）。这块内存按 stride 折算只够放约 31 行，而对象仍自称 32,784 行高。这组数字本文独立复算，与原文一致。

原文另给出一组小尺寸：width = 0xFFFFFFF5、height = 1、bpp = 8，称可把分配压到约 0x440 字节并落入可布置的小尺寸堆块。按同一公式复算，本文得到的是约 85 字节，与原文的 0x440 不符，出入原因公开信息未说明。这处出入不影响定性结论：攻击者确实能让分配落在远小于声明的尺寸上，且尺寸档位（size-class）可选。引用具体数字时应以前面那组为准。

四、漏洞触发：从接受会话到进程内代码执行

4.1 强制走位图路径

查看端只在没有可用硬件视频解码器时才使用 CBitmapBuffer，否则帧数据走 AV1 或 H.264 通道。研究方确认这条选择不是查看端单方面做出的：主机端拒绝协商这些编解码器，就能把会话推到位图路径，再挑选一种无损 tile 编码，更新被直接解写进这块表面。

这意味着在查看端禁用或限制编解码器并不能关掉这条路，防守重心只能放在版本与会话来源上。

4.2 从崩溃到代码执行

低端结果是稳定可复现的远程拒绝服务：送一帧覆盖整块声明表面的更新，解码器把整块表面写进只装得下一小部分的缓冲区，在标准 Windows 客户端上是一次干净的崩溃。

高端结果是代码执行。被破坏的表面是一个活动对象，查看端后续会通过它首字段里的指针发起调用，覆盖掉这个指针就能把调用引到别处。控制流防护与数据执行保护本应拦住这一类跳转，研究方称绕过了两者，把调用转到 WinExec。由于分配的尺寸档位可由攻击者选定，这不是差一字节的溢出，而是一次线性的、内容可控、落点尺寸可选的大范围堆溢出。

图 2：CVE-2026-111585 的会话方向与利用链逻辑，本文绘制的机制示意图，不含可利用代码与构造参数。

4.3 演示里被顶替的那一步

研究方在文中明确交代：演示里那批造成破坏的字节，是由主机端的一个钩子顶替线上 tile 载荷写入的，它驱动的是同一条代码路径，只顶替堆布局那一步，其余环节都跑在发行版二进制上。

这个交代是必要的，它把两件事区分开了：漏洞路径在真实会话中可达，已被证实；端到端利用的堆布局环节尚未在线上载荷下完整演示。读到\"已实现代码执行\"时应当按这个边界理解，它证明的是路径与后果，不是一份可直接复用的武器化链。

五、补丁分析：同类错误在别处也出现过

5.1 15.83 与仍然存在的构造函数

研究方的版本对照给出一条值得注意的观察：15.80.6.0 的查看端与主机端均为受影响，15.82.6.0 上那个有问题的构造函数仍然存在（观测到），修复落在 15.83。这与官方\"15.83 之前受影响\"的表述一致。

由此得到一条实操含义：停在 15.82 的用户即便已经处理过 9 月那批公告 TV-2026-1010，也不覆盖本条。两次公告的版本线相邻但不相交，按\"最近打过一次补丁\"来判断状态会漏掉这一条。

5.2 同一类错误的先例

Remedio 早前在 Adobe Acrobat 上报告过 CVE-2026-81983，同样是整数溢出导致越界写。两处相隔很远的产品与代码，犯的是同一类错误：大小的算术与边界的算术分属两处，二者没有被绑定。

5.3 一条可迁移的检查项

把三、四章的现象收敛成一句可以给开发与安全评审直接用的话：分配与守卫它的检查，不应读两套算术，且必须在真实分配的宽度上做校验。凡是\"先算一次大小用于分配，之后用另一个来源的维度做边界判断\"的结构，都值得单独审一遍。这条检查项不依赖任何特定产品或语言，成本也比逐个追 CVE 低。

六、自查与处置：版本之外还要清点的东西

6.1 升级目标

升到 15.83 或更新，覆盖完整客户端、主机端、便携版与 Android Remote Control App。维护分支按官方清单对应到各自的修复构建：

TeamViewer Full Client / Host（Windows、Linux、macOS）  15.83TeamViewer Portable（Windows）                          15.83TeamViewer Remote Control App（Android）                15.83Full Client / Host v15.64（Windows 7 与 8）             15.64.10Full Client / Host v14.7（Windows、Linux、macOS）       14.7.48868Full Client / Host v13.2（Windows）                     13.2.36231Full Client / Host v13.2（Linux）                       13.2.154008Full Client / Host v13.2（macOS）                       13.2.154007

官方公告未给出升级之外的替代缓解措施，因此临时规避只能落在会话来源管控上：不接受来源不明的协助请求，不打开来源不明的 .tvs 会话录制（后者对应同公告的 CVE-2026-92372）。

另一件容易被漏掉的事：同一天 TeamViewer 还发布了 TV-2026-1012，修的是 Remote Management 附加组件（监控、高级资产管理、补丁管理），含 CVE-2026-92375、92376、92377、111582、111583、111584，CVSS 上限 7.8 分。这是一次集中发版，清点时不应当只停在客户端本身，附加组件也要一并核版本。

6.2 无人值守 Host 的清点

无人值守的主机端安装是最容易漏的形态，它常常不在软件分发清单里，也不弹更新提示，却长期在线并保持可接受会话的状态。清点时应把这类安装单独列出来，并确认升级后实际运行的版本号，而不是只确认下发过升级任务。

6.3 可观测信号

可优先接入三类信号：查看端进程在会话期间或会话结束后崩溃；会话期间派生出非预期的子进程；来自未知对端的会话建立记录。远程控制软件本来就会派生子进程，告警阈值需要按本环境的基线校准，直接套通用规则会产生大量噪声。

七、结束语：远程控制工具要按浏览器的补丁节奏管

远程访问工具是一类被设计成可信的资产：它天生需要跨网络接受对端数据，部署面又极广，因此长期是初始接入与勒索团伙偏好的入口。TeamViewer 今年以来的公告已经接近月度节奏，把它纳入与浏览器同一档的快速更新环，比按季度软件维护流程处理更接近它的真实风险曲线。

更值得留意的是这次的方向。远程协助的流程本身就是一条信任通道，求助方天然占据向施助方输送数据的位置，这次送达的是屏幕帧，下一次可能是别的东西。真正能收敛这类风险的，是把对端送来的数据一律当作不可信输入落到每条解码路径上，而不是依赖\"我们只连自己人的机器\"这一层假设。那层假设在这次攻击里正是被利用的那一部分。

八、参考

Remedio 研究披露（Omri Dar，2026-10-29）https://remedio.io/research/vulnerability-disclosures/remote-code-execution-in-teamviewer/
TeamViewer 安全公告 TV-2026-1011（2026-10-27）https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2026-1011/
CVE-2026-111585 记录（CWE-190）https://www.cve.org/CVERecord?id=CVE-2026-111585
Remedio 早前同类研究 CVE-2026-81983（Adobe Acrobat 整数溢出致越界写）https://remedio.io/research/vulnerability-disclosures/cve-2026-81983-integer-overflow-vulnerability-enables-out-of-bounds-write-in-adobe-acrobat/
其他佐证：NVD 与 MITRE CVE 记录条目；SecurityOnline 对 TV-2026-1011 的报道（2026-10-28）；CERT.UG 对前一批公告 TV-2026-1010 的通报；EPSS 与 CISA KEV 目录查询记录