网络安全与密码学 · 托管服务器与备份安全

Acronis 备份插件遭利用，低权限账号可能获得服务器高权限

漏洞处置队列里，有一类条目很容易被往后放：评分没有到 10 分，攻击向量写着“本地”，还要求攻击者先有一个低权限账号。

CVE-2026-87886 就长这样。Acronis 将它评为高危，CVSS 3.0 分数为 7.8。问题来自不安全的文件权限，影响 Linux 上用于 cPanel & WHM、Plesk 和 DirectAdmin 的部分 Acronis Backup 集成。[1][3][4]

但它已经不是“理论上也许能用”的漏洞。Acronis 表示，已在针对 cPanel & WHM 部署的有限、定向攻击中观察到利用；美国 CISA 也在 9 月 16 日把它加入已知遭利用漏洞目录（KEV），目录页面当前显示的到期日是 9 月 19 日，并标注需要取证分诊。[1][2]

今天是 9 月 20 日。这个日期不是所有机构、所有资产统一适用的法律期限；BOD 26-04 对适用的美国联邦文职行政部门系统按资产确定时限：机构逐资产判断是否公开暴露，并结合 CISA 按漏洞发布的 KEV 状态、可自动化性和技术影响套用时限表。对其他机构，KEV 收录本身仍说明：继续把这枚漏洞留在普通补丁队列里，已经没有证据依据。[2]

先把三项事实摆清楚

本地提权从已有低权限访问开始；公开资料没有说明最初入口。

这是一枚本地提权漏洞

公开记录中，向量的可利用性指标为 AV:L/AC:L/PR:L/UI:N：攻击者需要已经能在目标系统上以较低权限活动，利用过程不要求另一名用户点击或确认。完整向量还记录了作用域与机密性、完整性、可用性影响。[3]

因此，它不能被写成“陌生人从互联网直接、无需登录接管服务器”。公开资料没有交代攻击者最初怎样获得低权限，也没有公布受害者数量、攻击者身份或完整攻击链。

“本地”不等于“影响只在本机”

在共享托管服务器上，低权限账号并不罕见。服务器本来就可能同时承载多个网站、客户账号和自动化任务。一个已被攻陷的网站应用、泄露的面板账号或恶意租户，都可能成为本地立足点——这是根据漏洞前提与托管场景作出的风险推断，不是 Acronis 已确认的初始入侵路径。

Acronis 的 cPanel 集成可备份整台服务器，并恢复网站、文件、邮箱、账号和数据库。[5]一旦低权限边界被突破、攻击者获得服务器高权限，调查范围就不能只停留在某一个网站目录。

受影响，不等于已经证实遭利用

官方披露把多个托管面板集成列入受影响范围，但现有公开利用表述具体指向 cPanel & WHM 部署。[1][4]

这一区分必须保留：Plesk 和 DirectAdmin 需要按受影响版本修复，但不能因为它们出现在同一公告里，就写成已经观察到针对这两类部署的真实攻击。

三个误区，会把处置带偏

分数、攻击向量和修复状态，必须结合真实利用证据一起读。

误区一：需要低权限，所以可以等

“需要低权限”描述的是攻击起点，不是影响终点。CISA 将漏洞列入 KEV，说明已有真实利用证据；在多租户主机上，低权限入口也可能比单用途服务器更常见。[2]

正确的优先级判断不是只看 CVSS 总分，而是同时看三件事：有没有真实利用、你的服务器上是否存在低权限用户或易受攻击的网站、插件是否低于修复构建。

误区二：软件显示最新版，就算修好

这次要核对的是完整构建号，而不只是大版本名称。Acronis 公告与政府安全通告列出的最低修复构建为：[1][4]

• cPanel & WHM：1.9.3.1021，对应 1.9.3 HF3；
• Plesk：1.8.11.638；
• DirectAdmin：1.2.3.238。

如果管理界面只显示 1.9.3 或 1.8.11，还不足以证明补丁已经落地。应从软件包或扩展信息中取得完整构建号，并把结果留在变更记录里。

误区三：升级完成，历史风险就消失

升级能修复这个已知文件权限缺陷，却不能回答升级前是否有人用过它。对曾经运行受影响构建的主机，至少要把版本修复和事件排查分开记录。

目前公开的一手资料没有给出专用入侵指标，不能凭空编一条文件名、进程名或网络地址当作确定证据。更稳妥的做法，是围绕本机权限边界回看：异常的高权限进程、新增或提升权限的账号、可疑的计划任务与服务、SSH 密钥变化、插件目录的所有者与权限变化，以及备份任务和恢复操作的异常时间线。

如果已有失陷迹象，先保存易失性数据、日志与必要的主机证据，再决定重建、凭据轮换和恢复顺序。不要让一次覆盖安装把调查线索一并抹掉。

今天按两条路径分流

最低限度的记录包括完整构建号、升级时间线、历史排查结论和非生产恢复结果。

没有发现异常，但版本受影响

1. 盘点所有 cPanel & WHM、Plesk、DirectAdmin 主机上的 Acronis Backup 集成。
2. 记录完整构建号，升级到上述修复构建或厂商支持的更新版本。
3. 复核插件文件权限与所有者是否回到厂商默认状态。
4. 对升级前的受影响时段做一次有记录的历史排查，至少覆盖高权限账号、计划任务、服务、SSH 密钥、插件目录权限以及备份与恢复操作。
5. 收紧不必要的低权限登录、面板账号和外部管理入口。
6. 在非生产环境完成一次恢复测试，确认备份可读取、内容完整、恢复流程可执行。

已出现可疑高权限活动

1. 立即进入事件响应，由负责人权衡持续危害与证据保全：风险允许时，先记录网络连接和登录会话，并采集内存等易失性证据，再有序隔离；若攻击仍在扩散，则先隔离。避免直接关机，并记录每一步操作。
2. 查清最早的低权限立足点，而不是把这枚提权漏洞当成全部攻击链。
3. 评估主机、其他租户、插件配置、备份目的端凭据和管理账号的影响范围。
4. 从经过验证、时间点合适的备份恢复到干净环境，并在上线前检查持久化与账号变化。
5. 按证据轮换可能暴露的凭据，持续监测恢复后的主机。

NIST 面向托管服务商的备份指南强调，备份不仅要创建和保存，还要维护并测试；CISA 也建议定期验证备份的可用性与完整性。[6][7]这里的恢复测试不是为了证明这次漏洞已经改过备份，而是为了避免在真正需要重建时，才第一次发现恢复链路不可用。

今天最低限度要在每台托管主机上留下四项证据：完整插件构建号、升级前后的时间点、历史排查结论、一次在非生产环境完成的恢复结果。对于适用 BOD 26-04 的美国联邦文职行政部门系统，还需要按 CISA 的资产级时限与取证分诊要求执行，不能用这四项记录替代正式流程。[2]

修复构建修复的是这个已知文件权限缺陷；调查和恢复测试，才决定这台服务器能否重新被信任。

资料来源 · 访问日期 2026-09-20。利用范围按厂商原始表述保留，未推断攻击者、受害规模或初始入口。

[1] Acronis：SEC-10986 — Local privilege escalation due to insecure file permissions

[2] CISA：Known Exploited Vulnerabilities Catalog

[3] 匈牙利国家网络安全研究所：CVE-2026-87886

[4] 法国 CERT Santé：Acronis — CVE-2026-87886

[5] Acronis：cPanel & WHM 集成功能说明

[6] NIST NCCoE：面向托管服务商的备份文件维护与测试指南

[7] CISA：#StopRansomware Guide