北京时间10月21日晚10点，PHP官方把四个修复版本8.5.12、8.4.27、8.3.36、8.2.35一次推齐，修补的是两个CVSS评分9.2的高危远程代码执行漏洞。"抢跑"本身就是事件的全部重点：这批原定周四发布的补丁提前了一天，因为漏洞细节在官方公告发出前早已外泄，PHP当时还明说，细节继续扩散或出现真实攻击，发布时间还会再提前。知乎
这对被外界统称"PHP2Shell"的漏洞，当地时间10月21日由《华尔街日报》报道为可能使黑客控制基于PHP运行的服务器、窃取信息、对访问相关网站的用户发动网络攻击，且是研究人员借助AI工具发现的。到了10月22日，AWS确认这对漏洞正在实际攻击中被广泛利用。CNN则称全球多个政府和公司网站一度短暂宕机，矛头都指向这个AI参与发现的严重漏洞。对普通用户，这条热搜的意义可以压缩成一句话：全球约七成网站赖以运行的引擎层漏了水，而考卷早在补丁落地前就摆上了台面。微博知乎微博
360等企业已开放免费安全体检，供站长主动排查风险。知乎
泄露链条：抢走的不是数据，是防守方的时间
UTC时间10月20日下午三点，两个CVE编号先在论坛和社交媒体上传开，还带着一个错误的评分——传的是10.0，实际是9.2。错误的评分和真假混杂的细节，正是站长们在补丁落地前最难消化的一批信息。知乎
同一晚八点，参与发现漏洞的公司Calif误发了一段针对真实目标的PoC演示视频，视频很快删除，截图却一直在流传；PHP2Shell这个统称，正来自泄露截图里显示的那款漏洞利用工具。知乎
最后一环出在防守方内部：距离约定的发布时间还有六个多小时，发行版厂商Chainguard单方面把带补丁的镜像发了出去，理由是判断野外已经出现利用，此事在安全社区引发两派争议。协同披露留给防守方的静默窗口，本来是各方拿时间换出来的安全垫，一轮轮泄露把它变成了攻击者的预读材料。知乎
洞在引擎里：为什么插件、WAF和你的代码都拦不住
两个CVE对应PHP处理请求时的两种失效方式。CVE-2026-109618是内存耗尽损坏：请求跑到一半被打断，内部数据只初始化了一半，清理环节又把这份半成品当成有效数据接着用。CVE-2026-109619是残留全局状态：某个请求的内部状态在它背后的内存释放之后还活着，同一个worker处理的下一个请求可能在正常初始化把它重置之前就用上——这意味着打补丁之前的每一次请求，都可能是在给下一次请求埋雷。知乎
官方划定的影响面异常之宽：所有处理Web请求的PHP安装都受影响，包括PHP-FPM、Apache加mod_php、php-cgi、FrankenPHP和LiteSpeed。知乎
官方明确认为mod_php风险最高，而且已经存在能用的演示：一个未授权的请求，可以在任何应用代码运行之前触发攻击。 这就是为什么常规防御直觉集体失效——WordPress安全插件靠auto_prepend_file加载，等它跑起来时PHP早已解析完请求体；disable_functions、关掉file_uploads、应用层中间件、登录校验，全都排在解析阶段之后；WAF只在服务器不能被直接访问时有用，攻击者拿IP直连就绕过了。知乎
暴露面同样不乐观。据安全公司Mallory对Shodan数据的统计，10月20日对外暴露且HTTP头里报告PHP版本的主机约150万台，其中约88.4万台报的是8.1或更老版本，占59%。这批主机恰好落在官方二进制补丁之外：PHP安全组对7.4、8.0、8.1只提供"最小化源码backport"，只修这两个CVE、需要自己打补丁编译，共享主机用户拿不到；志愿者维护的remi仓库也被官方劝退，当天不提供更新包。CERT-EU的建议更直接：升不了，就把对外的PHP应用先摘下线。知乎知乎
AI挖出了老漏洞，泄露让攻击者抄了近道
这个洞不是新长出来的。2020年就有人报过超长变量名引发OOM的同类问题，当时只绕开了具体触发点；2024年OSTIF出资、Quarkslab执行的审计也摸到过同一处，结论停留在"理论上能利用、没有可用的利用路径"，于是继续压着。知乎
变局发生在今年夏天：Calif研究员8月11日报出漏洞，OpenAI同天独立报告了同一根因；另一条线上，安全公司Wiz用Wiz Atlas、Gemini 4 Argon与GPT-5.6 Sol的组合，8月19日找到第一个缺陷，8月20日即在Drupal上打出未授权RCE，8月21日在WordPress上复现，8月24日上报PHP安全组。OpenAI表示，过去两个月该公司联合开源维护者、研究人员及安全服务商协助修复了这个漏洞，Calif正是其安全计划下获得模型访问支持的团队之一。知乎36氪
真正的新意在这里：从"理论上危险"到"可用的利用链"，过去靠人类研究员难以跨越的那道成本墙，AI几周就拆完了；而泄露又让这道成果在补丁落地前摆上了台面。防守方抢跑的24小时，被原样还给了进攻方。
现在该做什么：升级是唯一完整答案，缓解只是买时间
官方对缓解清单的态度写得很明白：只有更新才是完整解决方案，其余措施只能降低特定攻击路径的暴露面，不会让安装变得安全。升不动时按清单止血：memory_limit设为-1，且要用php_admin_value写进FPM pool或服务器配置，防止被站点里的.user.ini改回去；post_max_size压到8M、确需上传的压到32M，upload_max_filesize保持更低；关掉session.upload_progress.enabled并重启所有worker；PHP 8.5再加fatal_error_backtraces=0；用容器或cgroup兜住可用性，别用RLIMIT_AS，它反而会把漏洞路径触发出来。两个最容易踩的坑：关session.upload_progress只挡得住CVE-2026-109619的session路径，对109618完全无效，关错开关比不关更危险。另一个坑是升了版本不重启worker，109619的残留状态还留在内存里。知乎知乎
最后一步是倒查，把时间回拨到10月20日15:00 UTC、第一个爆料帖出现之前开始查起：看Web服务器和PHP日志里有没有异常的multipart请求、有没有PHP-FPM worker崩溃。再查上传目录、插件目录、mu-plugins有没有新增或改动过的文件，有没有多出来的.user.ini、auto_prepend_file有没有被改，cron、systemd里有没有新条目、有没有新SSH密钥，后台有没有多出来的管理员账号。查到异常就断网隔离、保住日志、重建服务器，并把PHP用户能读到的全部密钥——.env、数据库密码、API key——轮换一遍。共享主机用户不能只问"PHP升了吗"，要确认版本号精确到8.3.36、8.2.35这一级。知乎
最后交代边界：截至发稿，"PHP 5.x打了官方补丁仍被入侵"之类说法只来自个别维护商，尚无官方验证；可以确认的是8.1及更早版本拿不到官方二进制补丁，而AWS披露的在野利用正在发生。这次锅不在你的代码、插件或CMS，在PHP引擎本身——能做的只有升级，然后重启。
