10 月 21 日至 22 日，我们先后处理了两个安全事件带来的风险：一是 PHP 官方修复的两个严重级别（Critical）漏洞；二是证书机构 eMudhra 的 8 张中间 CA 证书存在私钥生成缺陷，私钥可以被任何人从证书中还原。
这两件事都和 VilaVPN 有关：我们的会员中心等网站服务使用 PHP；我们的服务器和 VPN 节点也要通过 HTTPS 验证外部服务的身份。这篇文章按时间顺序记录我们做了什么、各用了多长时间，以及你可以做的一件事。
结论先放在前面：
- PHP 漏洞： 官方修复发布前 9 个多小时，我们已在所有运行 PHP 的服务器上关闭会话上传进度功能，作为临时缓解。修复版本发布后约 40 分钟，会员中心和计费系统完成升级；当晚 22:40 左右，所有仍对外提供服务的 PHP 运行环境都已切换到修复版本。
- eMudhra 证书事件： 从开始处理到最后一台 VPN 节点换上新版本程序，用时约 1 小时 45 分钟。服务器操作系统的信任列表和全部 VPN 节点程序，现在都已不再信任受影响的证书链。
- 你可以做的一件事： 及时安装手机、电脑系统和浏览器的安全更新，见第三节。
- 我们做得不够的地方： eMudhra 事件我们跟进得不够及时，见第四节。
操作时间根据服务器日志整理，官方发布时间参考官网及我们的监测记录；均已换算为北京时间（UTC+8），标注「左右」的为估算。
一、PHP 高危漏洞：先缓解，再升级
发生了什么
10 月 20 日，PHP 官方提前预告：将在 10 月 21 日发布紧急安全更新，修复两个 CVSS v4 评分 9.2（满分 10）的漏洞。修复发布时，官方公布了细节：CVE-2026-109618 和 CVE-2026-109619 在特定条件下，可能让攻击者无需身份认证，通过特制的网络请求在服务器上执行任意代码。所有用 PHP 处理网页请求的服务器都在影响范围内（PHP 官方公告）。
会员中心存放着账户和订阅信息。这次我们先采取临时缓解措施，再完成安全版本升级。
我们做了什么（北京时间）
| 时间 | 动作 |
|---|---|
| 10 月 21 日 12:10 | 在所有 PHP 服务器上关闭会话上传进度功能，并开启会话严格模式，逐台验证生效。这与官方针对 CVE-2026-109619 的缓解建议一致，但不能代替版本升级。 |
| 21:40 左右 | PHP 官方发布修复版本，并公布针对 CVE-2026-109618 的缓解建议。 |
| 21:45 | 检查 PHP 的 POST 请求体大小限制，下调原有上限较高的配置，作为升级前的补充缓解。 |
| 22:20 | 会员中心和计费系统升级到修复版本，距离修复发布约 40 分钟。 |
| 22:40 左右 | 所有仍对外提供服务的 PHP 运行环境都已切换到修复版本。 |
几点细节：
- 先测试，再上线。 升级前完成备份，并在测试环境检查页面响应和所需组件的加载。升级后，从外部复查了登录页、知识库、购物车入口和会话 Cookie。
- 停用旧版本运行环境。 PHP 8.1 及更早的版本已结束常规官方支持。我们停用了这次排查中仍在使用旧版本 PHP 的对外站点运行环境。此次停用不涉及会员中心、计费系统或 VPN 服务。
- 关于「8.2.35 修复不完整」的说法。 当晚有人在 X 上质疑修复不完整，该作者随后修正了最初的判断；其后续报告的特定测试场景，要求服务器关闭上传进度清理功能，我们的配置不满足这一条件。截至 10 月 22 日 05:48（北京时间），PHP 官方没有发布比 8.2.35、8.3.36 更新的 8.2、8.3 分支版本。
二、eMudhra 证书事件：只更新系统还不够
发生了什么
HTTPS 的安全建立在「证书机构值得信任」的前提上。根据事件通报，证书机构 eMudhra 在 2025 年 4 月生成的 8 张中间 CA 证书，私钥生成方式有缺陷，任何人都能从公开的证书中还原私钥。攻击者可以利用这些私钥为任意域名签发伪造证书；仍信任相关证书链的客户端，可能因此接受冒充的服务。
事件通报称，没有发现相关的证书透明度（CT）日志记录，因此判断执行 CT 验证的客户端（例如主流浏览器）没有受到这类攻击；对不执行 CT 验证的客户端，是否曾被利用尚不清楚。相关厂商在 10 月 17 日到 20 日之间陆续开始分发拦截措施。不少非浏览器客户端不执行 CT 验证，它们的证书信任来源，可能是系统信任库，也可能是程序自带的证书库。
对 VilaVPN 意味着什么
我们的服务器和 VPN 节点也需要验证外部 HTTPS 服务的身份，因此同样需要处理这次的证书信任风险。排查后，要处理的地方有两类：
- 服务器操作系统的信任列表。 我们通过系统更新（例如 Ubuntu 的修复）或等效的不信任配置，阻断对受影响证书链的信任，并逐台验证两条测试链都因证书校验失败而被拒绝。
- VPN 节点程序内置的证书列表。 这一处更隐蔽：节点程序在编译时内置了一份根证书列表，更新系统对它不起作用。我们更新了节点程序，使它改用运行环境中的系统信任列表；在打包节点运行环境时增加了检查：如果其中仍包含指定的受影响根证书，打包就会失败。部署后，我们又在每台节点上逐台检查，确认信任列表中已没有这些根证书。
我们做了什么（北京时间 10 月 22 日）
| 时间 | 动作 |
|---|---|
| 03:46 | 开始逐台处理服务器的信任列表。 |
| 04:00 左右 | 服务器操作系统的信任列表处理完成；会缓存信任列表的后台服务随后重启生效。 |
| 04:43 | 证书服务完成程序更新。 |
| 05:04 | 新版节点程序先在一台节点上部署，确认节点上报成功、证书正常，并已加载用户配置。 |
| 05:31 | 全部 VPN 节点运行新版本。 |
本次节点更新会中断当时已有的连接，需要客户端重新连接。如果你在这段时间遇到过短暂断线，可能与这次更新有关，给你带来不便了。
三、你可以做的一件事：安装系统和浏览器的安全更新
我们已经完成了上述服务器信任列表调整和 VPN 节点程序更新。你的设备这一侧，请及时安装手机、电脑系统和浏览器提供的安全更新，厂商已经陆续推送了相关的拦截措施。
懂一点技术的话，也可以用这两条命令检查电脑上 curl 的证书信任配置：
sh
curl -q --connect-timeout 10 --max-time 20 https://dv-g3b-emudhra.we-have-a-problem.com/
curl -q --connect-timeout 10 --max-time 20 https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
两条都报证书校验错误，说明 curl 当前使用的信任配置已经拒绝这两条测试链；如果能正常连接，就需要更新 curl 使用的证书信任库。超时或网络错误不能作为判断依据。这个检查只代表 curl 本身，不代表浏览器、其他 App 或整台设备；也请不要加 -k 跳过校验。
四、我们做得不够的地方
根据事件通报，这件事在 10 月 17 日已报告给各根证书计划，通报页面标注的日期是 10 月 20 日。我们在北京时间 10 月 22 日凌晨才开始处理，跟进不够及时。
这次处理也统一了节点程序的证书信任来源：节点程序不再使用编译时内置的根证书列表，而是使用运行环境中的系统信任列表，便于后续维护。
参考来源
- PHP 官方公告：php.net 2026 年新闻归档、PHP 8.2.35 发布说明
- 漏洞公告：GHSA-w8hw-w9fx-j79w（CVE-2026-109618）、GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- eMudhra 事件通报：emudhra.we-have-a-problem.com
- Ubuntu 修复说明：ubuntu.com
- Chrome 证书透明度政策：googlechrome.github.io
- curl 证书说明：curl.se
