Canonical在2026年8月25日发布USN-8678-1安全公告，为Ubuntu 26.04、24.04和22.04 LTS提供OpenSSL更新。此次公告覆盖10个CVE，问题涉及QUIC、DTLS、CMP、CMS解密和AEAD认证等多个加密处理环节。
OpenSSL不仅被命令行工具调用，也常被Web服务器、邮件服务、数据库客户端、反向代理和应用运行时动态加载。系统显示OpenSSL包已经升级，并不代表所有长期运行的进程已经使用新库，因此Canonical明确要求更新后重启系统。
此次更新覆盖三个Ubuntu LTS版本
安全公告列出的受支持版本包括Ubuntu 26.04 LTS、24.04 LTS和22.04 LTS。不同漏洞的影响范围并不完全相同，其中多项QUIC和Raw Public Key问题只影响26.04。
修复后的OpenSSL与libssl版本分别为26.04的3.5.5-1ubuntu3.4、24.04的3.0.13-0ubuntu3.15，以及22.04的3.0.2-0ubuntu1.29。
管理员应按发行版核对实际包版本，不要直接拿其他版本号判断。使用Ubuntu衍生镜像、云厂商定制镜像或延迟更新源时，还需要确认安全仓库是否已经同步。
主要风险包括拒绝服务与内存破坏
多项漏洞会让远程攻击者触发OpenSSL崩溃或消耗过量资源，造成拒绝服务。受到影响的处理环节包括QUIC初始数据包、QUIC ACK保留、DTLS未来Epoch记录和CMP证书缓存。
CVE-2026-63072涉及CMS密钥解包时的堆缓冲区溢出，官方说明可能导致拒绝服务或任意代码执行。CVE-2026-75803则影响特定AEAD密码通过EVP_Cipher接口进行认证标签验证，可能被用于伪造攻击。
并不是所有安装OpenSSL的服务器都会暴露相同攻击面。是否启用QUIC、DTLS、CMP或CMS，以及上层程序采用哪条API路径，都会影响实际风险。
普通网站也不能只检查openssl命令
Nginx、Apache、Postfix、数据库连接器和许多语言运行时可能链接libssl。即使网站没有直接执行openssl命令，HTTPS、邮件TLS或后端API连接仍可能依赖系统库。
管理员可以先检查系统发行版、已安装包和待更新列表，再排查哪些进程加载了旧版libssl。容器中的OpenSSL来自镜像文件系统，宿主机更新不会自动修复容器内部的软件包。
静态链接OpenSSL的应用也不会随着系统libssl包更新。此类程序需要由供应商发布新版，或重新编译并部署，不能只依赖apt升级。
标准系统更新完成后必须重启
Canonical给出的处理方式是执行标准系统更新，并在完成后重启。重启可以确保Web服务、代理、数据库客户端以及其他长期进程重新加载修复后的libssl。
生产服务器应先确认备份、可用磁盘空间和控制台访问正常，再安排维护窗口。集群环境可以分批重启，并在每一批完成后检查负载均衡健康状态、TLS握手和业务错误率。
只重启Nginx不一定覆盖所有受影响进程。云服务器上可能同时运行监控代理、Docker守护进程、邮件服务和自建应用，完整重启更符合官方公告的要求。
重启后还要验证版本与服务状态
服务器恢复后，应再次确认openssl和libssl包已经达到对应修复版本，并检查系统是否仍提示需要重启。HTTPS站点需要重新测试证书链、TLS协议和主要接口。
使用HTTP/3或QUIC的业务应单独验证新连接、并发请求和异常数据包处理。依赖CMP、CMS或自定义加密流程的企业应用，也应运行专门回归测试。
最终验证不能只看服务器能够开机。系统日志、Web服务状态、容器健康检查和外部监控都恢复正常，才能确认这次OpenSSL更新已经安全完成。
