AnyDesk Linux 内存破坏漏洞（CVE-2026-109390）应急处置：版本核验、临时缓解与回滚准备

CVE-2026-109390 值得远程运维团队立刻处理，原因不在于分数高，而在于它的触发条件几乎与日常使用方式重合。据公开漏洞情报，AnyDesk 8.0.3 之前的版本在会话协议处理中存在堆缓冲区溢出，未经身份认证的远程攻击者可在 linux 上以 root 权限执行任意代码，且不需要受害者确认连接；CVSS 3.1 评分为 9.8，EUVD 与 vFeed 均收录该编号（别名 GHSA-p2jv-fpmf-jqjw），奇安信 CERT 已发布复现通告，GitHub 上也已有针对 8.0.2 构建的公开 PoC。对把 AnyDesk 当作“随时可连的备用通道”的团队而言，这意味着暴露在公网上的主机可能在无人值守时被直接接管。

影响范围与暴露面判断

先把边界划清楚，再动手。公开资料中的验证与利用演示集中在 Linux 客户端，受影响版本为 8.0.3 之前；其他平台的受影响情况、各发行版仓库中的实际版本号，以及修复版本是否已被下游仓库收录，都应以厂商公告和包仓库信息为准，不要仅凭二手汇总下结论。

判断自身是否暴露，看三个条件是否同时成立：

1. 主机上安装了 AnyDesk，且版本低于 8.0.3；
2. 该主机的会话端口对不可信网络可达，包括公网直连、端口映射、云安全组放行，或经由中继服务器被外部发起连接；
3. 无人值守访问处于开启状态（多数远程运维场景正是如此）。

其中第 2 条是关键变量。由于漏洞位于认证之前的会话协议处理环节，攻击者不需要口令、不需要 ID 白名单通过、也不需要用户点击接受，端口可达本身就构成风险。反过来，只要能在网络层把可达性收窄，即使暂时无法升级，也能显著降低被利用的概率。

资产发现与版本核验

应急第一步不是打补丁，而是拿到准确清单。建议同时从配置管理系统和主机侧两条线核对：CMDB 或终端管理平台给出的“已安装版本”经常滞后于实际运行版本。

快速核验命令

Debian/Ubuntu 系：

dpkg-query -W -f='${Package} ${Version}n' anydesk 2>/dev/null

RHEL/CentOS/Fedora 系：

rpm -q anydesk

无论哪种发行版，都应再确认实际运行的程序版本，避免“包已升级但旧二进制仍在跑”或“便携版绕过包管理”的情况：

anydesk --version
systemctl status anydesk --no-pager
ps -eo pid,user,comm,args | grep -i '[a]nydesk'
ss -lntup | grep -i anydesk

最后一条命令同时回答了暴露面问题：确认 AnyDesk 实际监听的协议与端口（默认会话端口为 7070 TCP/UDP，若改过配置以实际输出为准），以及是否监听在 0.0.0.0、:: 这类所有地址上。

版本比对与判定

把收集到的版本与 8.0.3 逐台比对，按状态分类处置：

便携版是最容易被漏掉的一类：/opt、用户家目录、/tmp 下解压运行的二进制不会出现在包查询结果里，需要按文件名补充一次全盘排查，例如 find / -xdev -type f -name 'anydesk*' -perm -u+x 2>/dev/null。

临时缓解：把攻击面收到最小

升级通常需要变更窗口和业务确认，但暴露面收敛可以立刻做。原则是：先切断不可信来源，再谈连接便利性。

关闭不必要的常驻与中继路径

如果某台主机只是偶尔需要被远程协助，最彻底的缓解是让它平时不提供服务：

sudo systemctl stop anydesk
sudo systemctl disable anydesk

需要时再临时启动、用完即停。对于必须保持可连的关键主机，退一步做连接路径治理：关闭“始终经中继”一类选项，优先采用直连或经 VPN、堡垒机的私有路径；在安全设置中收紧访问控制，仅允许指定 ID 或指定账户接入，并明确禁止匿名请求。各版本设置界面文案不同，修改时应以本机实际界面与官方文档为准，改完记录到变更单里，避免下一个人不知情地改回去。

用防火墙限制来源

这是最有效、也最容易验证的一层。nftables 示例，只放行运维跳板网段访问会话端口：

table inet anydesk_guard {
  set ops_nets { type ipv4_addr; flags interval; elements = { 10.20.30.0/24, 192.168.50.10/32 } }
  chain input {
    type filter hook input priority filter; policy accept;
    tcp dport 7070 ip saddr != @ops_nets drop
    udp dport 7070 ip saddr != @ops_nets drop
  }
}

习惯 iptables 的环境可等价实现：

iptables -A INPUT -p tcp --dport 7070 -s 10.20.30.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 7070 -j DROP
iptables -A INPUT -p udp --dport 7070 -s 10.20.30.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 7070 -j DROP

两点必须提醒：规则要落盘持久化（netfilter-persistent save 或写入 /etc/nftables.conf 并 systemctl enable nftables），否则重启即失效；放行顺序上 DROP 必须在最后，写反了等于没做。云主机还要同步收紧安全组，别只改主机内规则而把入方向留在 0.0.0.0/0。

缓解有效性的验证

改完不等于生效。至少做两侧验证：从白名单外的地址执行 nc -zv <目标IP> 7070，应超时或被拒绝；从跳板机发起真实连接，应能正常建立会话。同时回看 AnyDesk 自身日志与系统日志，确认没有异常连接尝试堆积。若发现历史日志中存在来自未知外部地址的会话记录或进程异常派生（例如 AnyDesk 进程拉起 shell），应按入侵事件处理，而不是简单升级了事。

升级路径与验证清单

优先使用发行版仓库或官方软件源升级，并核对包签名与来源，不要从论坛或网盘下载安装包。升级前先留好回滚物料（见下一节），升级后按下表逐项确认：

升级完成后建议用 apt-mark hold anydesk 或 versionlock 把版本固定在已验证的修复版，防止后续不受控的自动降级或跨大版本跳变，同时保留定期复核机制。

回滚准备：先想好怎么退

远程桌面客户端升级失败会直接切断运维通道，因此回滚方案必须在升级前就绪，而不是出事时现场找包。

准备三样东西：旧版本安装包（apt-get download anydesk=<旧版本> 或从官方仓库取对应 rpm/deb，存到本地制品库并记录哈希）、完整配置备份（/etc/anydesk、~/.anydesk 或 ~/.config/AnyDesk 下的 system.conf、user.conf、service.conf）、服务单元与启动方式记录（systemctl cat anydesk）。

回滚本身不复杂：

sudo systemctl stop anydesk
sudo dpkg -i /var/backups/anydesk/anydesk_<旧版本>_amd64.deb   # 或 rpm -Uvh --oldpackage
sudo cp -a /var/backups/anydesk/etc-anydesk/. /etc/anydesk/
sudo systemctl start anydesk && anydesk --version

真正的风险在回滚之后：旧版本重新带回 CVE-2026-109390。因此回滚必须附带三个约束——网络层白名单继续生效且不得放宽；回滚窗口设定时限（例如 24 小时）并登记原因；回滚主机列入高优先级观察名单，明确下一次升级的时间点。如果升级失败原因不明，宁可在保留防火墙限制的前提下继续排查，也不要为了恢复便利而临时开放公网端口。

闭环：记录、观察与复盘

一次合格的应急不止于“升完版本”。建议在处置记录中固定四类信息：受影响主机清单与判定依据（版本、端口、可达性）、所采取的临时缓解及其验证证据、升级与回滚操作的时间线及执行人、以及剩余风险说明（例如便携版未覆盖、某台主机因业务原因暂缓升级）。

观察指标也应提前定好：会话端口的新增外部连接尝试、AnyDesk 进程的异常子进程、非工作时间的连接建立、以及配置文件的非预期变更。把这些指标接入现有日志平台或主机监控，比事后翻日志更可靠。

最后回到漏洞本身：预认证、无需确认、可拿到 root，这三点叠加说明“把远程桌面端口暴露在公网”这一长期习惯的成本已经很高。借这次处置顺手清理一遍遗留的端口映射、临时开放的云安全组和早已无人认领的便携版客户端，比单纯升一个版本号更有价值。所有验证与测试都应在获得授权的主机和网络范围内进行，涉及生产变更时保留回滚路径与复核记录。