【TechWeb】10月22日消息，昨日深夜，PHP爆出核心RCE两个极高危远程代码执行漏洞。其CVSS 4.0评分高达9.2，被PHP项目安全工程师称为“十多年来PHP面临的最严重安全事件”。
PHP 是服务器端脚本语言，WordPress、Laravel、Drupal 等大量网站都运行在其上面。据 公开统计数据，全球使用PHP语言的网站占比近70%，这也意味着全球7成的网站受到影响。
更棘手的是，漏洞细节与利用工具在官方补丁发布前就已泄露，将全球数以百万计的Web服务器推入了一个几乎没有缓冲期的危险窗口。
PHP的这个惊天漏洞，真可谓把全球运维吓醒，连夜挑灯夜战。据外媒报道，包括荷兰、芬兰、法国在内的多个国家因漏洞而预防性关闭或暂停政府网站及相关公共服务。
PHP爆出极高危漏洞：两个“9.2分”的核心RCE
这两个漏洞编号分别为 CVE-2026-109618 和 CVE-2026-109619，官方评级均为CVSS v4.0 9.2（严重），类型是未经认证的远程代码执行（RCE）。
漏洞位于PHP解释器内核，而非某个扩展或框架层。这意味着无论应用是用WordPress、Laravel还是任何其他PHP框架构建的，只要底层PHP运行时未修复，风险就存在。
根据官方披露，两个漏洞的具体机理略有不同：
CVE-2026-109618：由内存耗尽（OOM）处理过程中的内存损坏引发。内存不足的致命错误可能在内部状态仅部分初始化时中断PHP运行，后续请求的清理流程可能将无效数据误判为有效数据，从而触发代码执行。
CVE-2026-109619：由残留的全局状态（stale global state） 导致。请求专属的内部状态在其支撑内存被释放后仍然残留，同一工作进程处理的下一个请求可能在正常初始化重置状态之前，调用了这份“过期”状态，进而被利用。
要命的是，利用这些漏洞不需要任何账号或后台入口，攻击者仅凭一个精心构造的Web请求，就有可能在服务器上运行自己的代码。
漏洞是怎么发现的？一次被AI加速、被泄露打乱的披露
这次PHP安全漏洞发现和披露过程，与传统安全事件截然不同。
据外媒披露，PHP核心开发者在2024年就曾注意到相关内存问题的早期迹象，但当时未能找到具体的利用路径，修复工作一度停滞。真正的突破发生在2026年8月。加州安全公司Calif的研究员Ryan Austin在对PHP源码进行审计时，借助OpenAI的GPT-5.6 Sol模型，成功将这一潜伏多年的内存缺陷转化为可工作的远程代码执行链。与此同时，安全公司Wiz使用其AI代理结合Gemini 4 Argon与GPT-5.6 Sol，在2026年8月19日独立发现了第一个漏洞，次日便实现了针对Drupal的未认证代码执行。
要命的是，官方原计划于10月22日进行协调披露，但在10月20日，匿名消息开始在Hacker News和社交平台上流传，附带两个CVE编号。随后，包含“php2shell”攻击链的演示视频出现，安全公司watchTowr也确认复现了CVE-2026-109618。
面对细节已经公开的局面，PHP安全团队被迫将补丁发布时间提前一天至10月21日14:00 UTC，并罕见地保留了“若细节公开或出现野外利用，将提前发布”的条款，这一条款在公告发出时就已经兑现了。
漏洞影响几乎“全场景”
此次漏洞影响范围之广，源于PHP在Web生态中的基础性地位：PHP在已知服务端编程语言中的占比长期维持在七成以上。
漏洞本身位于解释器内核，因此所有处理Web请求的PHP部署形态均受影响，包括PHP-FPM、Apache的mod_php、php-cgi、FrankenPHP和LiteSpeed。
具体到应用层面，主流的CMS、电商系统和建站面板几乎无一幸免。在流传的利用演示中，WordPress、Drupal、Joomla、Laravel、MediaWiki、Magento、Symfony、WHMCS等均出现在受影响范围内。
仅以WordPress为例，全球可探测到的资产就超过7200万。一旦漏洞被武器化，攻击者可能窃取数据库凭据、API密钥等敏感信息，篡改网站内容、植入恶意软件，甚至完全接管服务器。
美国CISA、澳大利亚网络安全中心、英国NCSC等机构在补丁发布后迅速发布了紧急警告，要求组织立即升级。
解决方案是什么？升级是唯一安全的选择
PHP官方已在2026年10月21日发布修复版本。唯一彻底的安全方案是升级至以下任一版本：
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
对于无法直接升级的场景，需要特别注意：
PHP 8.1及更早版本已停止官方支持，不会获得正式更新。PHP团队为PHP 7.4、8.0、8.1提供了最小化的源码向后移植补丁，供有能力从源码编译的用户使用。使用Linux发行版或LTS厂商打包版本的用户，应联系对应厂商获取移植补丁。
对于使用mod_php的Apache配置，风险被认为最高，应优先处置。
部分临时缓解措施（如设置 `session.upload_progress.enabled=0`）只能减少特定攻击路径的暴露面，PHP基金会明确指出这些措施 “并不能使安装变得安全” 。WAF规则同理，只能作为补丁上线前的后备防线。
升级或打补丁后，必须重启Apache、PHP-FPM以及所有长期运行的PHP工作进程，否则残留的旧进程仍可能处于易受攻击状态。
还有哪些风险存在？
网络安全行业人士认为，即便修复版本已经发布，PHP该漏洞的“长尾风险”仍然显著，主要体现在几个层面：
第一，“补丁窗口”被极度压缩，甚至已经消失。 传统漏洞披露中，防守方通常有数天时间在攻击者逆向补丁之前完成升级。但PHP的漏洞细节和利用工具在补丁发布之前就已经公开。有安全公司判断，补丁发布后约15分钟大规模攻击就可能开始。watchTowr在补丁落地前后已经观察到利用尝试，Cloudflare也报告了攻击流量，攻击者正在调整载荷以绕过WAF规则。防守方与攻击者这一次几乎是同时起跑。
第二，大量“被遗忘的PHP”根本无法获得官方补丁。 PHP 8.1及更早版本没有官方安全更新，而现实是，仍有大量服务器运行在这些旧分支上。互联网扫描数据显示，在可识别版本的PHP实例中，PHP 7.4是占比最高的单一分支。这些系统往往嵌入在遗留应用、共享主机或被遗忘的虚拟机中，运维者甚至不知道自己有一台PHP服务器在运行。有取证专家指出，大量嵌入式场景中的PHP“永远不会打上补丁”，这意味着漏洞的影响周期会非常漫长。
第三，AI改变了攻防的时间经济学。 此次漏洞的发现和利用代码的生成，都深度借助了AI模型。近期研究显示，AI可以将安全补丁转化为可工作的利用代码，耗时不到一小时，成本仅为数千美元的算力。当补丁公开的那一刻，攻击者可以立刻用AI比对旧代码与新代码，定位缺陷并生成攻击载荷。这意味着，依赖“补丁发布后再慢慢分析”的传统防守节奏，在AI时代正在失效。
第四，WAF和临时配置只是“减速带”，不是安全边界。 Cloudflare等厂商的WAF规则可以在已知攻击路径上提供拦截，但攻击者已经在调整载荷以绕过规则。PHP基金会自身也强调，临时缓解措施不能替代升级。对于尚未打补丁的系统，任何依赖单一WAF规则或配置开关的策略，都建立在攻击者不改变手法的假设之上。
PHP漏洞事件的本质，是一个潜伏在互联网基础层中的旧缺陷，在AI的放大效应和提前泄露的催化下，被推到了极短的攻防窗口之中。对于仍在运行未修复PHP的系统而言，风险并未随着补丁的发布而消散，只是从“未知的威胁”变成了“已知且正在被积极尝试利用的威胁”。
