- OpenSSL 项目于 2026 年 9 月 29 日发布了关于 CVE-2026-84782 的安全公告,按 CVSS 3.x 的严重程度为:8.8(高危)。
- 漏洞存在于 DTLS 重传逻辑中:对端可能以明文形式拿回堆内存中的数据,或者进程崩溃。
- 受影响的分支有 4.0、3.6、3.5、3.4、3.0、1.1.1 和 1.0.2。修复版本见下表。
- 更新之后,你必须重启所有加载了 OpenSSL 的服务。否则旧代码仍会继续留在内存中运行。
一个已经安装、却从未被加载的更新,对你的保护效果与没有更新完全一样。这个陷阱正是 OpenSSL 漏洞中的经典问题,因此值得仔细看一看 2026 年 9 月 29 日的这份安全公告。
到底发生了什么
OpenSSL 项目于 2026 年 9 月 29 日发布了一份安全公告,并同时发布了修复后的版本。Günter Born 在 2026 年 10 月 2 日的博客中报道了此事,The Hacker News 也对该话题做了整理。涉及的是 CVE-2026-84782,按 CVSS 3.x 评分为 8.8,即“高危”。
该漏洞在公告中的名称为“DTLS Retransmits Handshake Messages From a Stale Buffer Offset”。简单来说:DTLS 是 TLS 面向无连接传输(UDP)的变体。握手过程中如果有内容丢失,OpenSSL 会重新发送消息。如果某条握手消息的写入操作在中途被中断,重传逻辑就无法正确处理这种情况。结果出现两个问题:
- 越界读取:重新发送的消息可能会读取到消息缓冲区之外。对端随后会以明文握手数据的形式看到堆内存中的内容。
- 状态被覆盖:重传会覆盖内部状态,而被中断的写入操作需要这些状态才能正确继续。
- 崩溃:如果读取操作触及未映射的内存区域,进程就会崩溃。这已足以造成拒绝服务(Denial-of-Service)。
堆内存中可能包含进程刚刚处理过的各种内容。具体泄露出什么,无法预测。正因如此,你不应该低估这类漏洞。
哪些版本受影响,以及更新到哪个版本
受影响的分支多达七个。公告中给出的修复版本如下:
| OpenSSL 分支 | 更新到 | 说明 |
|---|---|---|
| 4.0 | 4.0.3 | 公开可用 |
| 3.6 | 3.6.5 | 公开可用 |
| 3.5 | 3.5.9 | 公开可用 |
| 3.4 | 3.4.8 | 公开可用 |
| 3.0 | 3.0.23 | 仅限 Premium Support 客户 |
| 1.1.1 | 1.1.1zj | 仅限 Premium Support 客户 |
| 1.0.2 | 1.0.2zs | 仅限 Premium Support 客户 |
我到底受不受影响?
使用 HTTPS 的经典 Web 服务器是通过 TCP 使用 TLS,而不是 DTLS。但你不能由此推断这件事与你无关。Rootserver 上运行的服务往往比你记得的要多:VPN 软件、媒体和电话服务器、IoT 网关。其中有些会使用 DTLS。某个服务是否接收 DTLS 流量,可以在它的文档以及开放的 UDP 端口中找到答案。
我们的建议:无论如何,请在所有地方更新这个库。付出的代价很小,而不更新的风险却难以估计。如果你在自己的 Rootserver 上运行 VPN,无论如何都应该把这件事放在清单的最前面。
分步操作:检查、更新、验证
- 确定版本。首先查看系统登记的 OpenSSL 是什么版本:
openssl version -a - 列出开放的 UDP 服务。这样你就能知道哪些程序有可能使用 DTLS:
ss -ulpn - 更新软件源并安装。在 Debian 或 Ubuntu 上:
该库的软件包名称取决于你的发行版。在 RHEL 系发行版上,请使用apt update apt install --only-upgrade openssl libssl3dnf upgrade openssl。 - 找出受影响的进程。仍在内存中保留旧库的进程,可以通过 needrestart 工具查看,或者不装额外软件包,用以下命令:
grep -l 'libssl.*(deleted)' /proc/*/maps 2>/dev/null - 重启服务。把第 4 步中出现的所有服务都重启,例如:
拿不准的时候,重启整台服务器也是个办法。systemctl restart nginx - 检查自行构建的软件。如果某个程序是针对 OpenSSL 静态编译的,或者自带一份副本(很多容器镜像都是这样),系统更新就没有用。这时你需要重新构建的镜像或新版本的程序。
apt upgrade 对此没有任何影响。请重新拉取镜像,并重启容器。如果你在 Rootserver 上运行容器,可以在我们的 Rootserver 上的 Docker 页面找到基础知识。如何确认已经成功
仅看版本输出是不够的,因为许多发行版会把修复合并进现有的版本号中。因此请检查两件事:
- 软件包的 changelog:
apt changelog openssl会显示其中是否提到了 CVE-2026-84782。 - 已加载的库:重启之后,第 4 步的检查不应再有任何结果。
- 服务的可达性:快速测试一遍 VPN、Web 服务器和邮件。如果重启后某个服务没有重新启动起来,往往要等到有人抱怨时才会发现。
只有当正在运行的进程加载了新代码,漏洞才算被堵上,而不是软件包安装完成的时候。
这对虚拟主机客户意味着什么
如果你使用的是虚拟主机,也就是没有自己的服务器,系统库由服务商负责维护。你不需要安装任何东西。如果你是自己在 Rootserver 上运营虚拟主机,例如使用某个面板,情况就不同了:这时操作系统由你负责。具体是什么样子,请看我们的 Rootserver 上的虚拟主机 页面。关于面板,我们最近还写过一篇文章:Froxlor 安全漏洞。那里适用同样的原则:在有人利用漏洞之前,定期更新。
常见错误
- 只更新了软件包:不重启服务,存在漏洞的代码就会继续运行。
- 只盯着宿主机:容器、chroot 以及自行编译的程序都有各自的副本。
- 读错版本号:公告中的 3.0.23 与你的发行版的版本号不一定一致。决定性的是 changelog 条目。
- 等得太久:公告是公开的,而攻击者恰恰喜欢利用公告之后的这段时间窗口。
如果你反正要在系统上操作,就顺手把访问入口也一起处理:如何 用密钥和 fail2ban 加固 SSH,我们有一篇专门的文章。
