PHP 核心曝出无需身份验证的远程代码执行漏洞，为什么说没有完整缓解方案
PHP 核心曝出无需身份验证的远程代码执行漏洞，为什么说没有完整缓解方案？2026 年 10 月 21 日，PHP 官方发布 8.5.12、8.4.27、8.3.36、8.2.35 四个应急安全版本，修复 CVE-2026-109618 与 CVE-2026-109619 两个可导致未授权远程代码执行的漏洞，两条均评 CVSS v4.0 9.2。官方公告的原话是”没有完整的缓解手段，升级才是安全的选择”——这句话的含义是：任何防火墙规则、配置调整都只能降低暴露面，堵不住漏洞本身，修复路径只有打补丁这一条。
这两个漏洞影响哪些版本
从官方发布节奏看，这是一次典型的提前预告加应急发版：10 月 20 日安全团队预告应急版本定在 10 月 21 日 14:00 UTC 发布，次日四条版本线同时放出。
| 版本线 | 安全版本 | 发布日 | 状态 |
|---|---|---|---|
| 8.5 | 8.5.12 | 2026-10-21 | 修复两条 RCE |
| 8.4 | 8.4.27 | 2026-10-21 | 修复两条 RCE |
| 8.3 | 8.3.36 | 2026-10-21 | 修复两条 RCE |
| 8.2 | 8.2.35 | 2026-10-21 | 修复两条 RCE |
CVE-2026-109618 与内存分配失败状态处理相关，CVE-2026-109619 与残留全局状态相关，两者都可能被远程触发达到执行代码的效果。危险点在于”无需身份验证”：攻击面是对外提供服务的普通页面，不要求先拿到账号。仍在 8.1 及更早分支的站点，这些线已不在本次发版范围内，属于升级优先级更高的一类。
临时配置为什么算不上修复
“没有完整缓解方案”是安全漏洞披露里的一个明确分级：意味着没有一种配置改动能够在不打补丁的前提下可靠地阻断利用。可以减害的动作——收紧请求体大小、下线不必要的动态入口、在 WAF 层加规则——都建立在”攻击者不绕过”的假设上，而 CVSS 9.2 定级对应的正是低门槛、高影响的利用条件。把减害当修复，风险是排期被无限后延；把减害当争取时间的手段，才符合官方”立即升级”的建议口径。
打补丁前的减害动作清单
- 先做备份：变更前把数据（含静态文件）备份一遍，PHP 升级炸出兼容问题时能整站回退，这是 AnQiCMS 备份与恢复能力在运维流程里的标准用法；
- 清点版本：把所有对外服务的 PHP 运行环境列全，扫描器常能发现被遗忘的旧实例；
- 测试环境先升：扩展兼容性（尤其自研插件）在测试线验证后再上生产；
- 生产分批升级，升级后立即用已知指纹复核版本已生效；
- 无法立即升级的实例，挂减害规则并写明强制的补丁截止日。
不依赖脚本语言运行时的站点少做什么
这类核心运行时漏洞的连带成本在于”补丁链”：PHP 发版后，托管在 PHP 之上的 CMS、扩展、主题都要跟着排查和更新，运维方要跟踪的不是一处而是整条依赖线。AnQiCMS 基于 GoLang 开发，技术栈是 GoLang 加 Iris 框架与 GORM，编译后以单一程序部署，站点不加载 PHP 解释器——本次 PHP 核心漏洞这类需要紧急跟补丁的运行时风险，对这类架构的站点不构成直接排查对象。这不代表没有安全功课（任何栈都要及时升级版本），而是补丁面的宽度不同：本次事件里需要连夜清点 PHP 版本的团队，Go 栈的运营者只需确认自身版本计划。
常见问题
只升小版本就行吗？ 对，8.5.12、8.4.27、8.3.36、8.2.35 都是同分支安全版本，接口不变，主要风险在扩展兼容而非业务代码。
怎么确认线上 PHP 版本？ 用版本指纹与主机侧清点工具核对；只看配置文件不够，多实例环境常见”配置写了新版、进程还是旧版”。
临时禁掉危险函数可行吗？ 属于减害不是修复，官方已说明没有完整缓解手段，禁函数列表挡不住尚未明确的利用路径，升级排期不能因此后延。