从 PHP2Shell 到 emSign：互联网安全的两次警报

2026年10月，PHP 核心远程代码执行漏洞与 eMudhra 数字证书安全事件相继曝光。从网站运行环境到 HTTPS 信任体系，两起事件涉及的都是互联网基础设施。

前言

今天（2026年10月21日），互联网安全领域接连传来两条令人关注的消息。

一条是被称为 PHP2Shell 的 PHP 核心远程代码执行漏洞，两项漏洞的 CVSS v4.0 评分均达到9.2分。另一条则来自印度数字证书颁发机构 eMudhra，其旗下8张中间 CA 证书的私钥存在极其严重的安全缺陷，可能被攻击者用于伪造受信任的 HTTPS 证书。

两件事并没有直接联系，却在短时间内集中进入公众视野。更值得关注的是，它们涉及的不是某个网站插件或应用程序，而是无数网站赖以运行和建立信任的基础设施。

今天恰好也给自己的 Debian 服务器进行了软件更新。看到这些消息后，又专门查阅了一些官方安全公告，就依据相关消息将这两起事件记录下来。

一、PHP2Shell：一次发生在 PHP 核心的严重漏洞

PHP 是互联网发展过程中最具代表性的服务端脚本语言之一。从早期的个人博客、论坛，到今天仍然广泛使用的 WordPress、Discuz、Flarum 等程序，背后都有 PHP 的身影。

10月20日，PHP 安全团队罕见地提前发布公告，预告将在次日推出紧急安全更新，修复两项 CVSS v4.0 评分均为9.2分的严重漏洞。

10月21日，官方正式公布了漏洞详情：

• CVE-2026-109618：与内存耗尽处理过程中的数据损坏有关，可能导致远程代码执行。
• CVE-2026-109619：与请求处理后的全局状态残留有关，也可能被利用实现远程代码执行。

两项漏洞均可能在无需身份验证的情况下被利用。

此次问题比较特殊，因为漏洞位于 PHP 自身的内部处理逻辑，而非某个网站程序的业务代码。官方特别指出，Apache mod_php 环境的风险较高，已经验证存在攻击在应用程序代码运行之前触发的情况。

这意味着，即使网站程序本身没有明显漏洞，也不代表运行环境就是安全的。

10月21日晚，PHP 官方正式发布修复版本：

官方明确表示，没有能够彻底消除漏洞风险的临时缓解措施，及时更新 PHP 才是可靠的解决办法。

对于仍在使用 PHP 8.1 及更早版本的服务器，则需要关注 Linux 发行版或长期支持服务商是否提供安全补丁，或者考虑升级到受支持的 PHP 版本。

二、eMudhra：一个私钥竟然只是数字“4”

如果说 PHP2Shell 的严重程度尚在一般服务器管理员的理解范围之内，那么这次数字证书事件，就多少有些令人难以置信了。

10月17日，安全研究人员向浏览器厂商报告，印度数字证书颁发机构 eMudhra 旗下8张中间 CA 证书的私钥存在严重问题。

正常情况下，采用 P-384 椭圆曲线算法的私钥，应该是一个具有足够随机性的384位数字，几乎不可能通过穷举计算得到。

然而，研究人员发现，这8张证书对应的私钥竟然分别是：

4、56、66、115、155、156、230、237。

没错，其中一把私钥就只是数字“4”。

如此简单的数字，根本谈不上有效的密码学保护。研究人员可以在极短时间内，从公开证书中恢复出这些私钥。

问题的根源可能出在2025年4月30日的一次密钥生成过程中。根据 eMudhra 于10月21日发布的声明，相关操作在生成正常密钥的同时，又因密钥封装和解封装环节出现异常，产生了另一组极其脆弱的密钥，而后者被错误地用于公开的证书体系。具体技术原因仍在调查。

这8张受影响的证书中，6张用于 TLS 网站证书签发，另有2张用于代码签名。

要理解这件事为什么严重，需要先了解 HTTPS 的信任机制。

我们平时访问一个带有小锁标志的网站，浏览器之所以相信对方的身份，是因为网站提供的数字证书能够追溯到系统信任的证书颁发机构。

可以简单理解为：根 CA 是受信任的权威机构，中间 CA 获得授权后，可以继续为网站签发证书。

而这次出现问题的，恰恰是拥有签发权限的中间 CA。

如果攻击者掌握这些私钥，就可能伪造某个网站的数字证书。对于仍然信任受影响证书链的客户端，如果攻击者还能控制或拦截网络连接，就可能冒充网站，进而读取或篡改通信内容。

不过，需要强调的是，这并不意味着全球 HTTPS 流量突然全部变成了明文，更不意味着仅凭这些私钥就可以解密所有历史通信。

这次事件暴露的是网站身份认证体系的严重风险。实际实施中间人攻击，还需要具备相应的网络控制条件。

三、浏览器迅速响应，但服务器和老旧设备怎么办？

好在这次事件被发现后，主流浏览器厂商反应很快。

根据 Google 和 Mozilla 官方公布的信息：

10月17日，Chrome 在确认问题后迅速下发 CRLSet 更新，阻止受影响的 TLS 中间证书继续获得信任；Firefox 也在当天通过 OneCRL 完成证书封锁。

这种处理方式不需要用户等待完整的浏览器版本更新，就能够将风险较快地控制在一定范围内。

Google 还表示，在封锁措施生效前，没有发现通过这些受影响中间 CA 签发并进入证书透明度日志的 TLS 网站证书。因此，至少对于默认强制执行证书透明度要求的 Chrome 而言，相关风险得到了较好的控制。

但问题在于，互联网并不只有 Chrome 和 Firefox。

Linux 服务器、嵌入式设备、路由器、物联网产品，以及大量依赖系统证书库的应用程序，并不一定具备浏览器那样迅速的证书撤销更新机制。

有些设备长期无人维护，有些已经停止厂商支持，还有些虽然正常运行，却可能几个月甚至几年都没有更新过证书信任库。

10月20日，Debian 官方发布了 DSA-6572-1 安全公告，通过更新 ca-certificates 软件包，移除相关受信任根证书。

其中，Debian 13 的修复版本为 20250419+deb13u1，Debian 12 的修复版本为 20250419~deb12u2。

四、两起事件，暴露的是不同层面的安全风险

把这两件事情放在一起看，其实挺有意思。

PHP2Shell 暴露的是运行环境的安全风险。

即使网站代码没有问题，底层解释器发生漏洞，也可能直接威胁服务器安全。

eMudhra 事件暴露的则是数字信任体系的安全风险。

即使服务器本身没有遭到入侵，如果客户端依赖的证书信任机制存在缺陷，用户仍然可能面临身份冒用和通信被拦截的风险。

前者需要及时升级运行环境，后者则需要浏览器、操作系统和相关应用共同更新证书信任信息。

五、写在最后

这两起事件让我联想到2014年的 Heartbleed（心脏出血）漏洞。

当年 OpenSSL 的严重安全缺陷，也让人们意识到，互联网中一些看似不起眼的底层组件，一旦出现问题，影响范围可能远远超过我们的想象。

当然，PHP2Shell、eMudhra 证书事件与 Heartbleed 的技术原理和实际影响并不相同，不能简单地将它们等同起来。

但它们有一个共同点：互联网安全依赖的不仅是每个网站自身的防护，更是大量基础软件、密码学实现以及信任机制的可靠运行。

参考资料

1. PHP 官方：2026年10月21日安全公告及修复版本
2. Google：Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
3. Mozilla：Protecting Firefox users following the compromise of eMudhra intermediate certificates
4. eMudhra：关于证书安全事件的官方声明
5. Debian：DSA-6572-1 ca-certificates security update
6. Ars Technica：The Internet goes on high alert after discovery of 8 compromised TLS certs

插图说明： 本文正文插图借助 中文小黑怪诞正文配图生成 Skill 生成。该工具经 故事的程序猿 推荐后了解并使用，在此一并致谢。插图仅用于辅助理解文章内容，并非官方技术示意图。

本文整理于2026年10月21日晚，依据截至发稿时的官方公告及公开资料。相关事件的调查和后续处置仍在进行，具体情况以官方最新信息为准。