安全事件背景

2026年10月21日，PHP官方提前一天发布安全更新，涉及8.5.12、8.4.27、8.3.36、8.2.35四个版本。这次修的是两个编号为CVE-2026-109618和CVE-2026-109619的严重问题，安全圈里把它们合在一起叫PHP2Shell。名字听起来吓人，说白就是：别人不用你的账号、不用登录后台，只要向你的网站发一条精心构造的访问请求，就有机会在服务器上执行系统命令，也就是常说的RCE，远程代码执行。PHP官方给两条漏洞的CVSSv4.0评分都是9.2。

这和平时说的WordPress插件漏洞、主题漏洞不是一类事。WordPress、Laravel、Discuz这些程序跑在PHP上面，像房子里的装修；这次出问题的是PHP语言本身，相当于地基有问题。站点里哪怕只有一页最简单的PHP页面，只要对外能访问，而且服务器上的PHP还没升到修复版，就都在风险范围内。Wiz、Calif、OpenAI旗下CodexSecurity等团队先后把细节报给了PHP安全组。研究人员还演示过：即使不控制你的网站代码，也可以从PHP工作进程的内存里读到别的请求留下的密码、登录令牌、API密钥、证书片段，所以危害不只是“能不能执行一条命令”这么简单。

发布时间也被搅乱了。10月20日傍晚，两个CVE编号连同错误的发布时间和错误的分数先出现在论坛和社交媒体上；PHP当晚发预告，把原订10月22日的补丁改到10月21日发出。Calif误发的一段PoC演示视频、以及Chainguard在正式披露前大约六小时就放出带补丁的容器镜像，都让外界更早琢磨怎么利用。补丁出来前后，Cloudflare和watchTowr都说过，已经看到针对这两个漏洞的扫描和利用尝试。到公开信息更新时，还没有哪家权威机构点名说“某台生产服务器已被攻陷”，但荷兰部分政务网站、BambooHR薪酬平台等已经预防性下线，说明各方都不敢赌。

漏洞技术原理

只要有人打开你网站上的页面，服务器里的PHP会执行一套流程,即:先把运行环境准备好，再读浏览器这次发来的内容，然后执行页面里的程序，最后把这一次访问占用的资源清理掉。PHP2Shell的两个漏洞，问题就出在这条主流程里，并不是某个插件单独的安全问题。

第一个漏洞CVE-2026-109618，和内存上限有关。 PHP可以用配置项memory_limit限制一次请求最多用多少内存，防止单个页面把服务器拖死。真要用超了，引擎会强行中断当前流程，转去清理、报错。问题出在时机上：如果中断发生在“请求内部数据只建了一半”的时候，清理代码可能误把还没建完的东西当成正常数据继续用，内存就被搞乱了，攻击者才有机会往下做远程执行。Apache常用的mod_php模式里，PHP和网页服务器绑得很紧，恶意请求有时在你自己的index.php、WordPress入口文件运行之前就进了引擎，所以官方把mod_php标成风险最高。PHP-FPM是另一种常见部署方式，进程和网页服务器分开一些，同样存在被利用的路径，只是部分情况还要结合站点自己的代码。

第二个漏洞CVE-2026-109619，和“上一次请求留下的烂摊子”有关。某个访问如果在半路致命报错、超时，或者卡在上传处理等环节就异常退出，PHP进程里有时还会留着指向旧内存的指针，像一张没擦干净的草稿。同一个工作进程接着处理下一次访问时，若新请求还没来得及把这些内部状态全部重置，后面的代码就可能误读上一次访问留下的内容；底层术语叫use-after-free，意思是去用已经释放掉的内存。和这个漏洞关系较密切的是Session上传进度功能session.upload_progress：它默认处于开启状态，而且会在整条请求完全准备好之前就参与会话相关处理，所以已公开的利用演示里经常提到它。补丁出来前，网上也流传“把session.upload_progress关掉就没事”的说法。PHP官方的意思是：关闭这项配置，只能减少CVE-2026-109619里与上传进度相关、已被写进公告的那几条路径，对另一条CVE-2026-109618完全不起作用；就算只谈619，攻击者仍可能走别的触发方式，因此关配置只能算临时减风险，不能代替升级PHP。

两条漏洞可以看成同一类老问题：PHP为了快、为了兼容老代码，在内存管理和出错恢复上用了不少全局状态和“先跳出去再清理”的写法，几乎每个Web请求都会经过。Calif追溯其中一条线索，发现2004年前后的PHP研究里就有类似影子，说明不是哪个新版本才出问题的，而是引擎里存在了很多年。补丁除了改逻辑，还给memory_limit加上了一个比较强硬的兜底机制:一旦触发，整个PHP进程直接退出，后面的收尾脚本不再跑。升完级后，如果你以前把memory_limit或post_max_size调得很大，最好对照业务实际需求再看确认一下，别盲目沿用旧配置。

攻击者如何利用

攻击者不需要账号，也不必弄清你用的是WordPress还是自写PHP。站点只要能从公网打开，PHP版本又还在受影响范围内，就可能先被扫描，再收到带有攻击意图的请求。安全社区讨论和厂商流量监测里，已经记录过多种攻击手法：multipart表单格式故意写错、POST请求体特别大、单次请求把内存用到接近配置上限，以及围绕session.upload_progress相关参数构造的访问。已公开的案例和演示里，Apache的mod_php部署方式出现得最多。

各安全厂商的通报也在增多。Cloudflare在10月21日UTC凌晨三点左右已为相关WAF规则默认开启防护，并观察到攻击者不断更换载荷试图绕过拦截；该公司仍说明防火墙只能争取时间，根本办法还是安装补丁。watchTowr同日下午更新了判断，从“尚未观察到野外利用”改为“已看到针对两个CVE的主动攻击尝试”。美国CISA在10月21日警报中要求机构先清点环境中的PHP、优先修复面向公网的系统；若短期内无法升至受支持且已修复的版本，建议暂时下线PHP相关服务，而不是仅靠修改应用配置应付。

如果你已经安装补丁，仍担心此前是否遭受过扫描或攻击，可关注这些迹象：短时间内大量multipart请求后出现内存报错、同一网站反复返回HTTP500、响应中出现异常偏大的PHPSESSID登录Cookie、PHP工作进程无故重启。借助AI辅助分析，从“理论上存在风险”到“手头有可用PoC”的周期被明显缩短；Calif提到有研究人员大约用一周就做出了可用利用，过去同类工作常需团队花费数月。今后遇到PHP安全公告，不宜当作普通小版本更新，也不要默认“下周再升”，应与系统内核、OpenSSL等安全更新同样对待。

如何防御

完整修复只有一条捷径:把真正处理网站请求的那套PHP升到官方已修复版本，然后重启Apache、PHP-FPM、FrankenPHP、LiteSpeed等所有长期跑着的PHP进程。只更新WordPress主题、Composer依赖，或者只换Docker里应用层镜像，底层PHP包若还是旧的，站点仍然危险。

各活跃分支应升到的首个修复版本如下。Linux发行版有时用自家包名和版本号打包同一补丁，要以软件包更新说明里是否写到这两个CVE为准，不能只看表面版本号。

PHP8.1及更早版本，官方不再发常规安全小版本，但安全组为7.4、8.0、8.1准备了最小源码回溯补丁，给自行编译或等厂商回溯的人用。8.2将在2026年12月31日停止支持，长期仍建议规划升到8.3或8.4。

(1).宿主机与容器维护人员

第一步先确认：这台机器上的PHP是什么版本，又是通过mod_php、PHP-FPM还是php-cgi和Web服务器对接。命令行可以执行php -v，也可以查包管理器记录或资产扫描结果。排升级顺序时，建议优先处理能从公网直接访问的站点，以及允许上传文件、带后台管理、多台站点共用同一套PHP环境的机器，内网且暴露面较小的可以放在后面。

补丁安装完成后，一定要重启Apache、PHP-FPM等PHP相关进程。不重启的话，内存里仍在运行的还是旧代码。如果短期内确实无法完成升级，官方提供了若干只能降低风险、不能代替补丁的临时配置。针对CVE-2026-109618，可在Apache或FPM池里用php_admin_value将memory_limit设为-1，并避免应用再改回有限值；同时适当减小post_max_size，在Nginx或反向代理上限制请求体大小和multipart分段数量。不要用RLIMIT_AS或RLIMIT_DATA替代上述做法，PHP官方说明那样仍可能触发同类问题。针对CVE-2026-109619，可在php.ini或池级配置中将session.upload_progress.enabled设为0，并重启全部worker；PHP8.5还可将fatal_error_backtraces设为0。PHP核心开发者在发布前已说明，真正可靠的做法只有升级，这些配置无法覆盖全部攻击方式。

(2).网站与业务负责人

站点如果托管在虚拟主机或SaaS平台，需要向服务商确认PHP版本和补丁计划，不能认为控制面板里WordPress已经最新就没有问题。自行管理VPS的用户，除了更新网站程序，还要更新操作系统中的php-fpm或libapache2-mod-php等组件，宝塔、LNMP等一键环境里的PHP版本也要单独核对。薪酬、政务、电商类系统在补丁窗口短暂停服，业务上会有影响，但一般仍比长期被入侵、数据持续外泄更容易善后。

(3).安全分析与蓝队

日常监测可以重点留意：PHP工作进程是否频繁重启，www-data等Web运行账户是否异常调用sh或curl，是否在较短时间内出现大量HTTP500并伴随格式异常的multipart请求。WAF能够拦截部分已知攻击流量，但不能因此认为系统已经安全。部分攻击以读取进程内存为主，磁盘上未必留下传统WebShell文件，需要结合进程行为、异常的对外网络连接一并分析。

(全文完)

阅读原文：点击这里​