2026 年 10 月安全事件汇总：PHP 严重 RCE、Node.js 高危漏洞与 eMudhra 证书信任危机-苏晨拾光

文章摘要

scbkw

文章最后更新时间：2026-10-22 00:18:00，若内容有误或已失效，可点击进行反馈。

2026 年 10 月中旬，开发者和网站运维人员需要重点关注几条安全事件线索：PHP 官方紧急修复两个可能导致未认证远程代码执行的严重漏洞；Node.js 发布包含多个高危修复的安全版本；与此同时，印度证书机构 eMudhra 的部分中间 CA 证书被发现存在严重的私钥安全问题，Chrome、Firefox 等浏览器生态迅速采取处置措施。

这几件事涉及不同的技术层面：服务器端语言运行时、JavaScript 运行环境、TLS 证书信任链。它们并不意味着所有使用这些技术的网站都已经遭到攻击，但确实提醒我们：及时更新运行时、正确管理证书信任，以及建立安全补丁流程，都是网站和服务端运维不可忽视的工作。

本文按公开事件时间线梳理，并尽量区分官方已经确认的事实、技术风险分析和仍需进一步调查的部分。

一、先看结论：哪些系统需要关注？

需要注意：Go 的证书验证调整与 eMudhra 事件存在关联线索，应放在同一条证书安全事件链中理解，而不是简单当作两个毫无关系的事故。

二、时间线：事件是如何发展的？

以下时间均以公开公告所标注的时间为依据。不同机构使用的时区可能不同，因此跨机构事件的先后顺序应结合原始公告判断。

10 月 14 日：Node.js 预告安全更新

Node.js 项目提前宣布，将在 10 月 21 日前后为 22.x、24.x 和 26.x 发布安全更新。

当时的预告指出，本次更新涉及多个安全问题，最高严重程度为 High。预告并未完整披露每个漏洞的技术细节。

官方来源：

“Node.js：October 2026 Security Releases” (https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)

10 月 17 日：eMudhra 中间证书问题被报告

Google Chrome Root Program 于 10 月 17 日 18:05 UTC 收到研究人员的报告，涉及 eMudhra 的八张下级证书颁发机构证书，也就是中间 CA 证书，对应的私钥存在问题。

Chrome 团队随后验证了相关发现，并更新了其证书阻断机制。

Mozilla 也在当天收到相关报告，并对 Firefox 用户采取了保护措施。

官方来源：

“Google Chrome Security：eMudhra 证书事件” (https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/)
“Mozilla Security：eMudhra 证书事件” (https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)

10 月 19 日：Go 发布证书相关安全更新

Go 官方发布安全公告，涉及 “crypto/x509” 对特定中间证书的信任处理，并建议用户升级至修复版本。

这项更新与当时正在调查的证书信任问题有关。理解这项更新时，需要区分两件事：Go 运行时本身的证书验证逻辑，以及浏览器、操作系统和其他软件各自维护的证书信任库。

官方来源：

“Go 官方安全公告” (https://groups.google.com/g/golang-announce/c/66pojueaQek)
“Go 官方问题追踪：#82345” (https://github.com/golang/go/issues/82345)

10 月 20 日：PHP 提前发布紧急更新预告

PHP 官方提前宣布，将于 10 月 21 日发布安全更新，修复两个严重漏洞。官方给出的 CVSS v4.0 评分均为 9.2。

在正式公告发布前，官方建议使用者提前准备升级工作。

官方来源：

“PHP 官方公告” (https://www.php.net/archive/2026.php#2026-10-20-1)

10 月 20 日：浏览器厂商公布证书处置措施

Mozilla 公布了 Firefox 侧的处理情况，包括通过 OneCRL 阻断受影响证书，并发布相应的 Firefox 和 ESR 更新。

Chrome 团队也公布了相关处置措施。对于部分依赖 Chrome Root Store 的其他设备和应用，Chrome 还宣布计划移除签发相关中间证书的根证书。

这意味着，证书事件的影响不只涉及单个网站，也可能影响依赖相关根证书的合法证书链。

官方来源：

“Mozilla Security Blog” (https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)
“Google Chrome Security Blog” (https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/)

10 月 21 日：PHP 与 Node.js 正式发布安全版本

PHP 发布多个分支的修复版本，解决两个可能导致未认证远程代码执行的严重漏洞。

Node.js 也发布了 22.x、24.x 和 26.x 的安全版本，修复包括 Brotli 依赖项问题在内的多个安全问题。

同一天，eMudhra 发布进一步的事件说明，披露其调查到的密钥生成流程问题。

官方来源：

“PHP 官方网站” (https://www.php.net/)
“Node.js 22.23.4 发布说明” (https://nodejs.org/en/blog/release/v22.23.4/)
“Node.js 24.22.1 发布说明” (https://nodejs.org/en/blog/release/v24.22.1/)
“Node.js 26.12.1 发布说明” (https://nodejs.org/en/blog/release/v26.12.1/)
“eMudhra 官方声明” (https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca)

三、PHP：两个可能导致未认证远程代码执行的严重漏洞

PHP 是大量网站、CMS、管理后台和 API 服务使用的服务器端语言。此次事件值得重视的原因，并不只是漏洞评分高，而是 PHP 官方明确指出，相关漏洞可能允许未经身份验证的远程攻击者在特定条件下实现远程代码执行。

3.1 漏洞编号与修复版本

此次涉及两个漏洞：

“CVE-2026-109618”
“CVE-2026-109619”

PHP 官方给出的 CVSS v4.0 评分均为 9.2，属于严重风险。

官方发布的修复版本如下：

PHP 分支| 修复版本 PHP 8.5| 8.5.12 PHP 8.4| 8.4.27 PHP 8.3| 8.3.36 PHP 8.2| 8.2.35

PHP 8.1 及更早版本已经不再由 PHP 项目提供常规安全更新。部分 Linux 发行版或长期支持供应商可能会自行回移补丁，因此应以所使用发行版的安全公告为准。

官方来源：

“PHP 官方安全公告与下载入口” (https://www.php.net/)
“PHP 下载页面” (https://www.php.net/downloads.php)
“CVE-2026-109618” (https://www.cve.org/CVERecord?id=CVE-2026-109618)
“CVE-2026-109619” (https://www.cve.org/CVERecord?id=CVE-2026-109619)
“CERT-EU 安全公告” (https://cert.europa.eu/publications/security-advisories/2026-018/)

3.2 两个漏洞分别是什么问题？

CVE-2026-109618：内存耗尽处理过程中的数据损坏问题

PHP 官方将其描述为与内存耗尽（Out-of-Memory，OOM）处理有关的远程代码执行漏洞。

在特定异常处理过程中，PHP 内部请求数据可能尚未完全初始化，后续清理流程却将不完整的数据当作有效数据处理，从而产生内存安全问题。

这里的关键不只是“内存不足”，而是异常处理和资源清理流程对内部状态的处理不够安全。

CVE-2026-109619：过期的全局状态问题

该漏洞涉及请求拥有的内部状态。在相关内存已经释放后，某些状态仍可能残留，后续由同一工作进程处理的请求可能在正常初始化重置状态之前使用这些过期数据。

这类问题与已释放内存仍被使用、内部状态生命周期管理不当有关。

需要强调：上述解释是对 PHP 官方公告的概括，不等于完整的漏洞利用分析。具体可利用性还取决于运行环境、请求处理方式以及相关条件。

3.3 哪些 PHP 环境需要优先排查？

PHP 官方指出，风险涉及处理 Web 请求的 PHP 安装，包括：

PHP-FPM
Apache “mod_php”
“php-cgi”
FrankenPHP
LiteSpeed

官方特别指出，使用 Apache “mod_php” 的环境风险最高。官方公告提到，存在一种可以在应用程序代码运行前触发攻击的利用方式。

这也是为什么不能只检查网站业务代码有没有调用某个危险函数：问题位于 PHP 运行时内部，不能仅依靠修改业务逻辑来确保安全。

3.4 应该如何处理？

建议按以下顺序执行：

确认线上实际运行的 PHP 版本，而不是只看开发环境版本。
根据实际分支升级至官方修复版本，或者安装发行版供应商提供的对应安全补丁。
重启或滚动重启相关 PHP 工作进程，确保新版本真正生效。
检查容器镜像、计划任务、后台进程和备用节点，避免遗漏仍在运行的旧版本。
在变更后再次核对运行版本，并检查服务日志和可疑异常。

PHP 官方明确表示，没有完整的替代缓解措施可以取代升级。对于暂时无法打补丁的互联网暴露服务，应考虑隔离或限制外部访问，并尽快完成修复。

如果你已经单独发布过 PHP 漏洞文章，这里可以作为该文章的后续更新，不必重复整篇技术分析。

四、Node.js：CVE-2026-111497 与 Brotli 依赖项安全更新

Node.js 不仅用于后端 API，也常见于 SSR 服务、构建工具、自动化任务、机器人和各种开发者平台。

2026 年 10 月 21 日，Node.js 发布多个安全版本，其中包括 “CVE-2026-111497″。官方将这一项列为 High，修复内容涉及 Brotli 依赖项。

4.1 官方确认了什么？

Node.js 24.22.1 的官方发布说明将该漏洞列为：

漏洞编号：”CVE-2026-111497″
涉及组件：Brotli 依赖项
严重程度：High
修复方式：将对应修复提交合并到 Node.js 发布分支

官方发布说明也列出了同批次的其他 TLS、DNS、HTTP、加密和权限模型问题。

这意味着，升级时不应该只关注一个 CVE，而应该安装对应分支的完整安全版本。

官方来源：

“Node.js 24.22.1 发布说明” (https://nodejs.org/en/blog/release/v24.22.1/)
“Node.js 22.23.4 发布说明” (https://nodejs.org/en/blog/release/v22.23.4/)
“Node.js 26.12.1 发布说明” (https://nodejs.org/en/blog/release/v26.12.1/)
“Node.js 2026 年 10 月安全更新公告” (https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)

4.2 Brotli 是什么？为什么依赖项漏洞值得关注？

Brotli 是一种数据压缩算法，常用于 HTTP 内容压缩等场景。

压缩与解压缩代码会处理外部输入的数据。如果实现存在边界检查、长度计算或内存管理问题，在特定条件下就可能引发安全风险。

不过，需要区分通用技术原理与这次漏洞的已确认细节。

截至本文整理时，Node.js 官方发布说明确认了 “CVE-2026-111497” 与 Brotli 依赖项修复有关，并将其评为 High；但仅凭这条发布说明，不能直接断言漏洞一定能实现远程代码执行，也不能将某种具体的越界写入利用路径当成已经由官方确认的事实。

因此，本文不把未经充分核实的利用细节写成确定结论。

4.3 哪些项目需要排查？

重点检查：

直接使用 Node.js 运行的生产服务；
处理用户上传文件、压缩内容或外部数据的服务；
使用 Node.js 的 SSR、API、机器人和自动化任务；
Docker 镜像、CI/CD 构建环境和长期运行的工作进程；
已停止维护或仍使用旧 Node.js 主版本的项目。

即使项目代码没有直接调用 Brotli，也不代表一定不受影响，因为相关功能可能来自运行时或依赖组件。

4.4 修复建议

截至 2026 年 10 月 21 日，官方公布的修复版本包括：

分支| 修复版本 Node.js 22.x| 22.23.4 Node.js 24.x| 24.22.1 Node.js 26.x| 26.12.1

实际升级时，应以对应官方发布页面和当前维护状态为准。已结束维护的版本不能简单认为安全，因为它可能不会获得相应的安全修复。

建议升级后重新构建部署镜像、重启进程，并核实线上 “node –version” 输出。对于使用版本管理工具或容器编排的项目，还要确认运行时没有继续引用旧镜像。

五、Go：crypto/x509 对特定中间证书的信任处理调整

Go 这条安全线索与证书信任体系有关。

Go 的 “crypto/x509” 提供 X.509 证书解析和验证能力，许多 Go 应用会依赖它验证 HTTPS 连接中的证书链。

5.1 这次更新的核心是什么？

Go 官方发布了安全更新：

Go 1.27.3
Go 1.26.10

相关更新调整了证书验证过程：对于特定的中间证书，验证流程会过滤包含这些证书的证书链，避免将其作为有效验证结果返回给调用方。

官方来源：

“Go 官方安全公告” (https://groups.google.com/g/golang-announce/c/66pojueaQek)
“Go 官方问题追踪” (https://github.com/golang/go/issues/82345)
“Go 下载页面” (https://go.dev/dl/)
“CVE-2026-111943” (https://www.cve.org/CVERecord?id=CVE-2026-111943)

5.2 为什么要调整证书验证？

HTTPS 不只是“服务器有一张证书”这么简单。

浏览器或客户端通常需要验证从网站证书到可信根证书之间的证书链。中间 CA 证书承担着连接信任根与终端证书的作用。

如果某个中间 CA 的私钥不再可信，攻击者就可能利用它签发伪造的终端证书。在信任链尚未被正确阻断的客户端上，这些伪造证书可能被错误地接受。

因此，安全修复不仅可以通过撤销证书完成，也可能通过更新验证逻辑、过滤特定证书链或更新信任库来完成。

5.3 Go 开发者需要做什么？

建议：

检查项目使用的 Go 版本，并升级至官方修复版本或供应商提供的修复版本。
对使用自定义证书池、自定义验证逻辑的项目进行专项测试。
确认部署环境中的系统证书包和运行时版本均符合安全要求。
对 HTTPS 客户端、代理、网关及其他依赖 “crypto/x509” 的服务进行回归测试。

特别要注意：更新 Go 运行时和更新操作系统证书包不是同一件事。一个 Go 服务即使完成了编译，也仍需要确认它在实际运行环境中采用了预期的信任配置。

六、eMudhra：八张中间 CA 证书对应的私钥出现严重问题

这条事件是本轮安全消息中值得深入理解的一部分，因为它触及 HTTPS 信任体系的基础。

6.1 中间 CA 证书为什么如此重要？

正常情况下，HTTPS 证书的信任链大致如下：

浏览器或系统信任库 | v 可信根 CA | v 中间 CA | v 网站 TLS 证书 | v 浏览器验证网站身份

中间 CA 通常拥有签发下级证书的能力。如果攻击者掌握了某个受信任中间 CA 的私钥，就可能尝试签发其他域名的伪造证书。

当客户端仍然信任相关证书链时，攻击者在具备合适网络位置或流量拦截条件的情况下，可能冒充目标网站。

这不代表攻击者可以无条件解密所有 HTTPS 流量。实际风险还取决于证书用途、客户端信任状态、撤销检查、证书链选择以及攻击者是否能够拦截或控制连接。

6.2 这次发生了什么？

Google 和 Mozilla 于 2026 年 10 月公布的公告指出，研究人员发现八张 eMudhra 中间 CA 证书对应的私钥存在问题。

CERT-In 在 10 月 21 日发布的公告进一步指出，受影响的 P-384 椭圆曲线私钥数值过小，可以根据对应公钥几乎立即恢复。

这不是正常意义上的“加密算法被破解”。P-384 本身并没有因此失去安全性；问题在于相关密钥生成过程产生了严重缺陷，导致本应难以推导的私钥可以被恢复。

官方来源：

“CERT-In：eMudhra 中间 CA 证书事件” (https://www.cert-in.org.in/s2cMainServlet?CACODE=CICA-2026-3649&pageid=PUBADV01)
“Google Chrome Security Blog” (https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/)
“Mozilla Security Blog” (https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)
“eMudhra 官方声明” (https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca)

6.3 问题出在什么环节？

根据 eMudhra 于 10 月 21 日发布的声明，问题涉及其在 2025 年 4 月 30 日进行的密钥生成仪式。

公司表示，密钥生成流程中的 wrap/unwrap 环节存在缺陷，导致在原本的强密钥之外产生了另一组弱密钥，而弱密钥被发布到了浏览器信任体系中。

这里需要区分两类信息：

**已经公开确认的情况：**浏览器厂商报告了八张受影响的中间 CA 证书，CERT-In 说明了私钥随机性不足及可快速恢复的问题。
**来自 eMudhra 自身的调查说明：**公司将问题指向特定密钥生成流程，并表示正在调查根本原因。

后续调查可能进一步解释缺陷是如何产生的，以及哪些内部控制未能及时发现它。不能因为公司已经给出初步解释，就认为所有根因和责任问题都已经调查完毕。

6.4 浏览器厂商采取了哪些措施？

Chrome

Google 表示，Chrome 团队在核实相关报告后，通过 CRLSet 阻断受影响中间 CA 的公钥标识。此类更新能够在不要求用户立即升级或重启浏览器的情况下，为接收更新的 Chrome 用户提供保护。

Google 还宣布，计划从 Chrome Root Store 中移除签发相关受影响中间证书的根证书 “emSign ECC Root CA – G3″。这一措施可能导致依赖该根证书的部分合法证书链不再被 Chrome 接受，因此相关网站运营者需要及时迁移至其他受信任的证书链。

具体实施时间和后续状态，应查看 Google 的原始公告。

Firefox

Mozilla 表示，Firefox 通过 OneCRL 阻断了受影响证书，并发布了相关版本更新：

Firefox 158.0.1
Firefox ESR 115.43.1
Firefox ESR 153.5.1

Mozilla 还宣布更新 NSS 信任库，以帮助那些使用 Mozilla 信任库、但不接收 OneCRL 更新的其他应用获得保护。

官方来源：

“Google：Protecting Chrome and Android Users” (https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/)
“Mozilla：Protecting Firefox Users” (https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)

6.5 这是否意味着所有 eMudhra 证书都不可信？

不能这样下结论。

公开信息针对的是特定的中间 CA 证书及其关联信任链。eMudhra 在声明中表示，事件涉及其全球 TLS 业务中的八张中间 CA 证书，并称印度国内数字签名证书和 eSign 业务未受影响。

CERT-In 的公告也将其说明的影响范围限定在国际浏览器信任体系中的相关证书业务，而不是印度所有数字签名服务。

但要注意，eMudhra 关于业务影响范围的陈述属于公司公告。运营方和依赖方仍应结合浏览器厂商、系统供应商以及后续调查公告判断自己的具体影响。

同样，也不应该把此次事件概括成“所有印度证书都不可信”。这既不符合公开证据，也会错误扩大事件范围。

七、Go 与 eMudhra 事件之间是什么关系？

这两条线索都涉及中间 CA 证书信任问题，因此有必要放在一起理解。

eMudhra 事件的核心是：特定中间 CA 证书对应的私钥存在严重弱随机数问题，可能使攻击者恢复私钥并伪造证书。

Go 的相关安全更新则从证书验证实现层面调整对特定中间证书的处理方式，避免相关证书链继续作为有效验证结果返回。

它们的共同点是保护客户端免于信任存在安全问题的证书链，但采取措施的层面并不相同：

因此，不能只升级浏览器就假设所有应用都已得到保护，也不能只升级 Go 就假设操作系统中所有使用者都已更新。

不同应用可能使用各自的信任库、证书验证实现或缓存机制。修复是否生效，应以具体产品和运行环境的安全公告为准。

八、网站管理员与开发者的实际检查清单

面对这几条安全事件，最实用的做法不是恐慌，而是把核查工作落到具体资产上。

PHP 网站

确认生产环境 PHP 版本。
升级到对应分支的修复版本，或安装供应商提供的修复包。
检查 PHP-FPM、Apache、LiteSpeed、容器及备用节点。
重启或滚动重启相关工作进程。
检查异常请求、服务崩溃和其他可疑日志。

Node.js 服务

确认线上 Node.js 主版本和完整版本号。
升级到对应安全版本。
重新构建并发布容器镜像。
检查所有长期运行的进程和自动化任务。
对同批次 TLS、DNS 和其他安全修复进行整体评估。

Go 应用

检查 Go 工具链版本。
升级至官方修复版本或供应商提供的修复版本。
检查自定义证书池和自定义验证代码。
确认生产系统的信任库处于最新状态。
对依赖 HTTPS 的客户端、网关和服务进行回归测试。

HTTPS 证书与系统信任库

检查网站当前证书的完整证书链。
关注浏览器和操作系统厂商关于受影响证书的后续公告。
确认客户端和服务器采用的信任库已获得相关更新。
如果证书链依赖被移除或被阻断的 CA，联系证书供应商并尽快更换。
不要通过关闭证书验证来解决连接报错。
对生产环境的证书变更进行测试，避免合法业务中断。

九、这几件事说明了什么？

这几条事件表面上分属不同技术领域，背后却有一个共同点：安全问题不一定出在业务代码本身，也可能出在运行时、底层依赖、密钥生成流程或信任体系中。

PHP 事件提醒我们，运行时内部的内存安全问题可能影响整个 Web 服务。Node.js 事件提醒我们，底层依赖同样属于生产环境的攻击面。Go 与 eMudhra 事件则说明，HTTPS 的安全性不只取决于是否使用 TLS，还取决于证书如何签发、私钥如何生成、客户端如何验证，以及相关信任信息能否及时更新。

对网站运营者而言，真正重要的不是看到高危漏洞后立刻认定网站已经被入侵，而是尽快确认：