Node.js, PHP and eMudhra: what to patch (October 2026)Node.js、PHP 与 eMudhra:该升级什么(2026 年 10 月)
Node.js security releases, two critical PHP remote-code-execution bugs and eight distrusted eMudhra intermediates: what changed, what to update, and what monitoring can and cannot tell you.Node.js 安全版本、PHP 的两个严重远程代码执行漏洞,以及被撤销信任的八个 eMudhra 中间证书:发生了什么、该升级什么,以及监控能告诉你什么、不能告诉你什么。
Three separate things landed within days of each other: Node.js shipped security releases on October 21, PHP patched two critical remote-code-execution bugs, and eight intermediate certificates from eMudhra were found to have private keys that anyone could recover from the public certificates. This post sums up what happened, what to update, and which parts uptime monitoring can and cannot help with.几天之内连着出了三件事:Node.js 在 10 月 21 日发布安全版本,PHP 修复了两个严重的远程代码执行漏洞,eMudhra 的八个中间证书被发现私钥可以直接从公开证书里算出来。这篇文章梳理发生了什么、该升级什么,以及哪些环节监控帮得上忙、哪些帮不上。
The eMudhra intermediateseMudhra 中间证书事件
Eight intermediate CAs under the emSign brand were affected: six issue TLS certificates and two sign code. According to eMudhra's preliminary explanation, a flaw in a key-generation script meant weak keys were used by mistake, and Mozilla and others recovered the private keys. The issue was reported to the Chrome Root Program on October 17, Chrome and Firefox blocked the intermediates the same day, and eMudhra revoked all eight the next morning. Apple and Microsoft platforms followed on October 19 and 20, according to the community incident tracker; neither has published a notice.受影响的是 emSign 品牌下的八个中间 CA,其中六个签发 TLS 证书,两个用于代码签名。据 eMudhra 的初步说明,密钥生成脚本有缺陷,错误地使用了强度很低的密钥,Mozilla 等人已经成功还原出私钥。问题在 10 月 17 日报告给 Chrome 根证书计划,当天 Chrome 和 Firefox 就屏蔽了这些中间证书,eMudhra 在第二天上午吊销了全部八个。据社区事件追踪站记录,苹果和微软平台在 10 月 19 日和 20 日跟进,两家都没有发布公告。
Browsers are the easy case. The harder one is everything that does not follow the browser's distrust list: language runtimes, containers, command-line clients and agents. Several of them have shipped updated CA data:浏览器是最容易的一类。麻烦的是不跟随浏览器屏蔽列表的那些:语言运行时、容器、命令行客户端和各种代理程序。其中不少已经发布了更新过的 CA 数据:
- Node.js 22.23.4, 24.22.1 and 26.12.1 update the bundled certificates. A public-key blocklist for the eight intermediates, so that chains through them are rejected even when they reach a trusted root, was merged into Node.js on October 20 (PR #66871); check the release notes for your line.Node.js 22.23.4、24.22.1 和 26.12.1 更新了内置证书。另有一项公钥黑名单变更已在 10 月 20 日合入 Node.js(PR #66871),让经过这八个中间证书的证书链即使能追溯到受信任根也会被拒绝;具体请对照你所用版本线的发布说明。
- Go 1.27.3 and 1.26.10 (programs must be rebuilt), Python certifi 2026.10.19, Rust webpki-roots 1.0.10, NSS 3.131.1, Composer ca-bundle 1.6.0 and 1.4.16, and Debian's ca-certificates.Go 1.27.3 和 1.26.10(程序需要重新编译)、Python 的 certifi 2026.10.19、Rust 的 webpki-roots 1.0.10、NSS 3.131.1、Composer 的 ca-bundle 1.6.0 和 1.4.16,以及 Debian 的 ca-certificates。
What Node.js fixedNode.js 修复了什么
The October 21 releases fix ten CVEs, four of them rated high:10 月 21 日的版本修复了十个 CVE,其中四个为高危:
- An out-of-bounds write in the Brotli decoder that allows remote code execution.Brotli 解码器的越界写入,可导致远程代码执行。
- Two TLS hostname-verification bypasses: one when an IP address is written with full-width digits (24.x and 26.x), one when a host loosely resolves to an IP address (all three lines).两个 TLS 主机名校验绕过:一个是 IP 地址用全角数字书写时(24.x 和 26.x),另一个是主机名被宽松地解析成 IP 地址时(三条版本线都受影响)。
dns.resolvetruncating a name that contains a NUL character.dns.resolve会截断包含 NUL 字符的域名。
A medium-severity fix covers non-canonical IPv4 hostnames that let a DNS name in a certificate authenticate an IP endpoint. These bugs do not depend on the attacker controlling a trusted CA, but they do need a way to put crafted data in front of a client that has not been patched. Upgrade to 22.23.4, 24.22.1 or 26.12.1 and rebuild any image that embeds Node.js.另有一个中危修复,针对非规范写法的 IPv4 主机名,它会让证书里的 DNS 名称通过对 IP 端点的校验。这些漏洞不依赖攻击者掌握受信任的 CA,但需要他有办法把构造好的数据送到未打补丁的客户端面前。请升级到 22.23.4、24.22.1 或 26.12.1,并重新构建内置 Node.js 的镜像。
PHP: two critical RCEsPHP:两个严重的远程代码执行漏洞
CVE-2026-109618 and CVE-2026-109619 both score CVSS 9.2 and allow unauthenticated remote code execution; one crafted request can be enough in the riskiest setups. They affect PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and PHP rates mod_php as the highest risk. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older have no official fix; move to a release line that is still supported.CVE-2026-109618 和 CVE-2026-109619 的 CVSS 评分均为 9.2,无需认证即可远程执行代码;在风险最高的部署方式下,一个构造好的请求就够了。受影响的有 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 和 LiteSpeed,PHP 官方把 mod_php 列为风险最高。修复版本为 8.5.12、8.4.27、8.3.36 和 8.2.35。PHP 8.1 及更早版本没有官方修复,应尽快迁移到仍受支持的版本线。
Where monitoring fits监控能做什么
Patching is what closes these holes; monitoring tells you whether the upgrade broke something. When a runtime starts rejecting a chain, or a rebuilt image fails to start, the first sign is usually a failing health check or a jump in errors, not a CVE number.补丁才能堵上这些漏洞;监控告诉你的是,升级之后有没有把什么弄坏。运行时开始拒绝某条证书链,或者重新构建的镜像起不来,最先出现的信号通常是健康检查失败或错误率上升,而不是某个 CVE 编号。
- An HTTP monitor with an expected status code and keyword shows whether an endpoint still answers correctly after you roll new Node.js or PHP images.给 HTTP 监控设置期望的状态码和关键词,就能看出在滚动发布新的 Node.js 或 PHP 镜像之后,接口是否仍然返回正确内容。
- If a service calls another one over TLS, monitor an endpoint that exercises that call. A trust-store mismatch between two services only shows up when the call is made.如果某个服务要通过 TLS 调用另一个服务,就监控一个会真正走到这次调用的接口。两个服务之间的信任库不一致,只有在调用发生时才会暴露。
- On the hosted plans from Lite, an SSL monitor warns before a certificate expires and flags one that is not trusted. It reads the certificate your hostname presents, from outside; it does not see which CAs your own runtimes trust.托管版 Lite 及以上套餐的 SSL 监控会在证书到期前提醒,并标出不受信任的证书。它是从外部读取你的域名出示的证书,看不到你自己的运行时信任哪些 CA。
OpenUptime is open source (MIT) and also hosted, and its MCP server lets an AI agent add monitors or update a status page for you. For the certificate side, see how to monitor SSL certificate expiry.OpenUptime 是开源的(MIT),也提供托管版,它的 MCP 服务器可以让 AI 助手替你添加监控或更新状态页。证书方面可以看如何监控 SSL 证书到期。
Checklist处理清单
- Upgrade Node.js to 22.23.4, 24.22.1 or 26.12.1 and rebuild images that embed it.把 Node.js 升级到 22.23.4、24.22.1 或 26.12.1,并重新构建内置它的镜像。
- Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or move off 8.1 and older.把 PHP 升级到 8.5.12、8.4.27、8.3.36 或 8.2.35,或者从 8.1 及更早版本迁移走。
- Update ca-certificates (or your language's CA bundle) in every base image and rebuild Go programs, so the eMudhra intermediates are distrusted.更新所有基础镜像里的 ca-certificates(或所用语言的 CA 证书包),并重新编译 Go 程序,让 eMudhra 的中间证书不再被信任。
- After rolling out, check from outside your network that the endpoints you care about answer correctly and present valid certificates.发布之后,从你的网络之外确认关心的接口响应正确、证书有效。
Sources资料来源
- Node.js: October 21, 2026 security releases
- Node.js PR #66871: reject chains containing blocked public keys
- Rescana: eMudhra intermediate CA key compromise
- Server Side Up: what to patch this week
- easyDNS: customer security advisory
Common questions常见问题
- Do I need to act if I only use browsers?我只用浏览器,需要处理吗?
- No. Chrome, Firefox, Apple and Microsoft platforms already block the eight eMudhra intermediates. The work is for software that ships its own trust store or reads an old CA bundle: runtimes, containers, command-line tools and agents.不需要。Chrome、Firefox、苹果和微软的平台已经屏蔽了这八个 eMudhra 中间证书。要处理的是自带信任库、或读取旧 CA 证书包的软件:运行时、容器、命令行工具和各类代理程序。
- Can an uptime monitor tell me my server trusts a bad CA?监控能发现我的服务器信任了有问题的 CA 吗?
- Not by itself. A monitor sees the certificate your hostname presents and whether your endpoints respond. It cannot see which CAs your own runtimes trust, so patching comes first and monitoring confirms nothing broke afterwards.单靠监控不行。监控能看到你的域名出示的证书,以及接口是否正常响应,却看不到你自己的运行时信任哪些 CA。所以先打补丁,再用监控确认升级后没有出问题。