远程桌面软件不用对方点同意，就能被拿到最高权限

原创

tcode
tcode

字节脉搏实验室

2026年10月10日 10:56
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

补丁六月就发了，利用代码十月才公开

二〇二六年十月八日，安全团队 V12 在代码托管平台公开了一枚针对 AnyDesk Linux 的完整利用代码。它的定性是预认证、无需受害者批准的远程代码执行：在对方还没有点接受桌面连接之前，攻击者就能在目标主机上执行任意命令。

事情的起点要往前推到六月。据安全媒体报道，V12 在六月二十二日披露了这处漏洞，AnyDesk 次日确认，并在六月推送了新版本完成修复。问题出在修复说明上：官方更新日志只写了一句，说修复了一个可能导致崩溃的缺陷，既没有分配漏洞编号，也没有发布安全公告。于是不少运维人员即使升级了，也不知道自己修掉的其实是一个远程代码执行漏洞。

到十月八日利用代码公开，仍运行旧版本 Linux 客户端的机器重新被推到台前。这里有一处边界要讲清楚：公开的利用代码针对的是八点零点二这个具体构建，偏移量也是为它算的，换到别的版本需要重新调整，所以它不等于所有 Linux 版本都能被同样方式打穿。

它为什么危险：不用对方批准，服务还是最高权限

根因在会话协议里。据 V12 发布的技术说明，处理某类流数据包的代码会先读取远端声明的载荷长度，再给这个长度加上十六字节的对象头，而这一步用的是三十二位运算，没有做溢出检查。攻击者只要把声明长度设成一个接近四吉字节的极大值，加上十六之后就会回绕成零：程序因此只分配了极小的缓冲区，对象里却仍然记着那个很大的长度。接下来哪怕只发一个字节，写入也会越出缓冲区。

真正放大风险的是两个环境条件。第一，这条代码路径在用户批准连接之前就能走到，所以攻击者不需要偷到密码，也不需要对方点同意。第二，在 Linux 上，这项服务默认以最高权限运行。两者叠加，一次成功的内存破坏就直接换成目标主机的最高权限。

边界同样要写清楚。已公开的完整利用链只跑通了直连七零七零端口这一种方式，而且带概率性：内存布局不配合时，服务会直接崩溃，而不是执行命令。V12 也提到，通过中继服务器同样能触达这条存在缺陷的代码路径，他们是靠调试插桩验证的，但并没有完整跑通中继场景下的利用链。厂商的说法是，该问题仅限 Linux 上的直连场景，Windows 和 macOS 不受影响。因此目前可以确认的高风险场景，是 Linux 主机加上七零七零端口暴露这一个组合。

要理解这条边界，得先知道这类软件怎么连上：两台机器能直接打通时走直连，打不通时借助厂商的中继服务器牵线。这解释了为什么目前被完整验证的利用链落在直连端口上，中继场景要先把流量引到正确的会话里，工程难度更高。这条差异直接决定优先级，把七零七零端口从不可信网络里收掉，等于掐断了眼下唯一被完整跑通的路径。

顺带说一句历史。同一款产品在二〇二五年修复过另一处堆缓冲区溢出，成因是用户图像处理里的整数溢出，与这次不是一回事；二〇二四年初，该厂商的生产系统也曾被入侵，导致证书吊销和强制改密。

按暴露面、版本、连接方式排一遍

排障的第一步不是升级，而是先把范围划出来，再顺着一棵决策树往下走。

先看暴露面：这台 Linux 主机上的七零七零端口，能不能从公网或者不可信的办公网访问到。能访问到的，按随时会被扫到来处理；只能在本机或严格隔离的网段访问的，风险等级立刻下降，但不等于没有风险。

再看版本：任何低于八点零点三的 Linux 客户端都在受影响范围内，当前最新版本是八点一点零。注意别只看有没有打过补丁，要看具体版本号，因为六月那份日志写得含糊，很可能有人以为升级过一次就没事了。

最后看连接方式：如果这台机器既暴露了七零七零端口，又因为网络隔离根本走不了中继，那么中继那条尚未完全验证的路径对它并不适用，风险集中在直连；反过来，如果中继可达，就要把它当成一个尚未完全排除的隐患来对待。

处置顺序，和一条可以核对的判断

处置顺序建议这样安排：先收暴露面，再打补丁，最后回头查有没有已经发生的事。

第一，先把不可信网络到七零七零端口的入站访问收掉。这一步在防火墙、云安全组和远程接入网关上都要看，不能只改一处。它不消除漏洞，但能立刻降低被扫中的概率。

第二，把受影响主机升级到八点零点三或更高版本。这是唯一从根上解决的动作，端口限制只是缓兵之计。

第三，回看痕迹。可以核对的判断是，在这些主机上，如果同时出现七零七零端口对外可达、客户端版本低于八点零点三、服务进程以最高权限运行这三项条件，同时又在服务日志里看到异常连接之后紧接着的服务崩溃或自动重启，就应当按可能已经被尝试利用来处理。除此之外，还可以检查有没有非预期的最高权限子进程，以及主机在非常用时间段向外发起的陌生连接。

盘资产这一步，不少单位会卡住。可行的做法是三条线索并行：从包管理器与安装记录里列出装了该软件的 Linux 主机和版本；从资产台账与配置管理库里找漏登记的机器；再从防火墙和负载均衡规则反向查，找出暴露了七零七零端口的主机。三条线索彼此对不上，正说明台账本身需要补。

这起事件还留下一个更普遍的教训：厂商的更新日志不能当作安全风险清单来用。这一次，危险等级在日志里被降级成了可能导致崩溃的缺陷；只靠日志判断轻重缓急，就可能把可被远程接管的问题当成普通稳定性修复。稳妥的做法是让版本变更和安全公告分两条线核对：涉及远程访问和对外服务的组件，只要有版本变更，就去对应的安全公告页和漏洞库里再查一遍。

日志可以更具体，重点看三处：一是该服务自身的日志，找异常连接之后紧接着的服务退出与自动重启；二是主机上以最高权限运行的可疑子进程，看它们的父进程是不是这个远程桌面服务；三是主机在夜间或非维护时段向外发起的陌生连接。日志干净不等于没被尝试过，一次失败的利用可能只留下一次崩溃和重启。

反过来也有几种情况能降低风险：服务不是以最高权限运行，利用成功后的权限会被限制在较低级别；主机只允许本机访问七零七零端口，外部根本连不上；已经升级到修复版本以上的机器不在受影响范围内。

一个可以拿去直接问的诊断问题是，我们服务器里有多少台装了 Linux 版远程桌面软件、版本低于八点零点三，而且七零七零端口能从公网或办公网访问。这个问题可以用资产台账、包管理器里的版本记录和防火墙规则的导出结果三份材料来对。

最后说明证据边界。本文的事实来自研究团队公开的技术说明与安全媒体报道，厂商对影响范围的表述是这些报道的转述；公开渠道尚无独立确认的受害样本，该漏洞也没有分配编号。

来源

1. V12 Security（GitHub 公开仓库 anydesk/README.md）：《AnyPwn: AnyDesk Pre-auth Heap Buffer Overflow RCE》；发布时间：2026-10-08；时区：UTC；URL：https://github.com/v12-security/pocs/tree/main/anydesk ；一手研究，支撑预认证、无需批准即可远程代码执行、会话协议长度校验缺失导致三十二位回绕、直连七零七零端口与中继路径的差异、中继仅经调试验证未跑通完整利用链、利用依赖特定构建与内存布局、Linux 服务默认以最高权限运行。

2. The Hacker News：《Researchers Publish Working Exploit for Pre-Auth AnyDesk Linux Flaw That Gives Root Access》；发布时间：2026-10-09；时区：UTC+5:30；URL：https://thehackernews.com/2026/10/researchers-publish-working-exploit-for.html ；安全媒体，支撑六月二十二日披露、厂商次日确认、八点零点三修复、更新日志仅描述为可能导致崩溃的缺陷、无漏洞编号与安全公告、最新版本八点一点零、厂商关于仅影响 Linux 直连场景与 Windows/macOS 不受影响的表述，以及二〇二五年另一处堆溢出与二〇二四年初生产系统被入侵的历史。

3. FreeBuf：《AnyDesk Linux曝高危漏洞，无需认证可远程执行Root级代码》；发布时间：2026-10-09；时区：北京时间（UTC+8）；URL：https://www.freebuf.com/news/505607.html ；中文安全媒体，用于交叉核对根因描述、受影响版本、端口暴露建议与日志与高权限进程检查项。

4. AnyDesk 官方更新日志（Linux 版本历史）：URL：https://anydesk.com/en/changelog/linux ；厂商一手页面，用于核对八点零点三的修复条目表述与后续版本号，并留存“该问题未被写成安全公告”的记录。