Proxmox VE 7：攻击者无需密码即可以 root 身份登录

发生了什么

2026 年 9 月 1 日，Proxmox 发布了安全公告 PSA-2026-00043-1。促成这份公告的并不是内部测试，而是求助。Proxmox 自己写道，他们是通过「many independent reports within the last two days, which also report exploitation in the wild」才得知这个问题的。换句话说：漏洞之所以曝光，是因为已经有人被入侵了。

事情从 8 月 31 日的 Proxmox 论坛开始。一位用户报告，他的 Proxmox VE 7 安装被加密，对方要求支付赎金才肯解密，而所有日志都被删除了。一天之内，又有多名受害者报告了相同的情况。截至目前，这个漏洞还没有分配 CVE 编号。

问题所在：一个参数让密码验证被跳过

Proxmox API 的登录通过 POST /api2/json/access/ticket 完成。这个调用接受一个用于第二因素的参数 tfa-challenge。对于没有配置第二因素的账户，这个参数从未被校验——更关键的是，只要它出现，系统就会完全跳过对所提交密码的验证。

实际后果是：只要在请求中带上这个参数并填入任意值，就能以任何已启用、且未配置双因素认证的用户身份登录。默认情况下 root@pam 就属于这一类。不需要密码，不需要爆破，也不需要猜测。一位受害者在论坛中这样描述：攻击者「straight away opened up a root Shell with no seemingly prior auth」。

唯一的前提，是能够访问 8006 端口上的 Web 界面或 API。把这个端口暴露在公网上，就等于把门敞开着。

三年无人察觉——而修复纯属偶然

受影响的是软件包 libpve-access-control，版本自 7.0-7 起，直到 8.0.4 之前。8.0.4 于 2023 年 7 月 20 日发布，并修复了这个问题。只是当时没有人知道这一点。

那次修复是重构双因素登录时的副产物。没有人意识到它是一个安全修复，因此既没有发布公告，也没有回溯移植到当时仍在维护的 Proxmox VE 7 分支。漏洞在那里一直敞开着，而在较新的版本中早已关闭——整整三年多，直到攻击者发现了它。

这才是这次事件真正的教训：一个不再获得安全支持的版本，并不是「虽然旧但稳定」。它是一个漏洞迟早会被别人先发现的版本——而发现的人不会通知你。Proxmox VE 7 自 2024 年 7 月起已经结束生命周期。

你受影响吗？这样检查

在 Proxmox 主机上执行一条命令即可：

dpkg-query -W -f '${Version}\n' libpve-access-control

如果输出的版本号大于或等于 7.0-7 且小于 8.0.4，系统就是易受攻击的。想查看全部软件包的版本，可以使用 pveversion -v。

如何判断是否已被入侵

从受害者的报告中可以归纳出一些具体痕迹。看上去至少有两拨人在行动：一拨加密系统并索要赎金，另一拨植入挖矿程序。需要留意的迹象：

• 文件 /var/lib/systemd/PVE-1——这就是挖矿程序。
• systemd 配置中出现名为 PVE-1.service 的服务。
• 本应是真实文件的日志，却指向了 /dev/null：auth.log、btmp、lastlog、wtmp、secure。痕迹在产生之前就被抹掉了。
• 指向挖矿池 gulf.moneroocean.stream 20004 端口的出站连接。
• 日志缺失或突然中断、Proxmox 权限管理中出现陌生用户、无法解释的负载。

只要发现其中任何一项，就应当把该系统视为已被完全接管。在攻击者取得 root 权限之后，清理并不是可靠的选择——只能重装，并从一份确认早于入侵时间的备份中恢复数据。

现在该做什么

第一：把 8006 端口从公网上撤下来。这是立竿见影的措施，而且与版本无关。只允许通过 VPN、内部网络或固定的地址白名单访问。对一个管理界面来说，这本来就是正确的运行方式。

第二：升级。按照 Proxmox 的说法，迁移到仍在维护的版本是唯一持久的解决办法。对 Proxmox VE 7 而言，这意味着连同底层的 Debian 一起跳到当前分支。

第三，如果前两条暂时都做不到：Proxmox 给出了一个应急补丁，让这个参数重新受到校验。

sed -i.bck 's/^\t# This is the 2nd factor, use the password for the OTP response.$/\tverify_ticket($tfa_challenge, 0, $username);\n\t# This is the 2nd factor, use the password for the OTP response./' /usr/share/perl5/PVE/AccessControl.pm

随后检查改动是否生效——下面这条命令必须输出 3：

grep -n 'verify_ticket($tfa_challenge, 0, $username)' /usr/share/perl5/PVE/AccessControl.pm | wc -l

然后重新加载服务：

systemctl reload-or-restart pvedaemon pveproxy

这只堵上了这一个漏洞，并不能替代升级：一个没有安全支持的系统仍然是一个没有安全支持的系统，而下一个漏洞未必还能靠手工打补丁解决。

Prepaid-Host 的客户受影响吗？

不受影响。我们的虚拟化运行在 Proxmox VE 9 上，所使用的 libpve-access-control 版本远高于已修复的 8.0.4。公告发布之后，我并没有抽查，而是逐台检查了我们机群中的每一台主机，并额外针对上文列出的入侵痕迹做了排查。所有主机都是干净的。

此外还有一点，而这恰恰是这个漏洞的关键：我们的 Proxmox 管理界面从公网上根本无法访问。管理完全走内部地址——而访问 8006 端口正是这次攻击的前提。对于你在我们这里的服务器，你什么都不需要做。

但如果你自己运行 Proxmox，比如在我们的根服务器上，情况就不同了。那样版本掌握在你自己手里，上面的检查步骤对你适用。

来源

• Proxmox Security Advisories — PSA-2026-00043-1
• Proxmox 论坛：「Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth」