2026年10月21日（北京时间），PHP官方发布紧急安全公告，修复编号为CVE-2026-109618、CVE-2026-109619的两个PHP核心漏洞，安全圈将这一组合称为"PHP2Shell"。两者均为CVSS v4.0评分9.2分的严重级未授权远程代码执行（RCE）漏洞，攻击者无需任何账号即可拿下服务器。漏洞曝光后，芬兰国家IT服务机构Valtori宣布政府公共服务网站"作为预防措施"下线，荷兰出现大面积连锁反应；在日本，游研社等游戏媒体确认，多家游戏与网站宣布为保障系统安全实施紧急维护。对全球约七成依赖PHP运行的网站而言，这是一次当晚就必须响应的应急事件。知乎知乎微博微博
对没有专职安全团队的个人站长和小微企业，现在最重要的一句话是：补丁已经发布，但"点了升级"不等于"修好了"——只有处理Web请求的旧进程全部退出，修复才算生效。知乎
这个漏洞为什么躲不掉
PHP2Shell的两个问题都出在PHP引擎底层，而不是某个框架或插件里。官方描述，一个漏洞发生在内存耗尽（OOM）时：请求数据结构只初始化了一半，内存分配中断会让PHP在清理流程中把无效数据当成合法对象处理，造成内存破坏进而可执行任意代码；另一个漏洞是"陈旧全局状态"残留——前一个请求的内部状态在对应内存释放后没有被清干净，同一个常驻Worker处理下一个请求时，可能在正常重置前就复用了这段过期状态。知乎
这带来两个直接后果。
其一，应用层的自救手段全部失效。升级WordPress插件、改业务代码、加一道路由过滤，都挡不住在应用代码执行之前就触发的攻击——官方明确提示，由于该漏洞在请求到达应用代码层之前便已触发，单纯依赖应用程序层面的修改无法抵御攻击。知乎
其二，所有对外提供Web服务的PHP形态都在打击范围：PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed，官方特别提示mod_php因多进程特性受威胁评级最高；官方同时明确，不存在完整的配置缓解方案，升级是唯一安全选择。更严峻的是，漏洞技术细节与验证代码（PoC）此前已在公开渠道流出，Cloudflare首席技术官Dane Knecht确认攻击已经出现，公司正随新攻击向量持续更新防火墙规则，但强调这只是权宜之计，应尽快打补丁。知乎知乎
攻击者不需要逐个挑目标，扫描互联网就能成批发现存在漏洞的服务器，而这次事件的发现过程中也有AI模型参与的报道。伦敦国王学院访问学者Lukasz Olejnik警告，随着AI辅助攻击手段扩散，漏洞利用可能在大规模、即时的层面上迅速蔓延；WordPress母公司Automattic则表示，其团队已做好准备，正与PHP安全团队协作确保更新完成。知乎知乎
自查第一步：别被php -v骗了
应急中最常见的错误，是登录一台服务器执行`php -v`，看到版本号合格就宣布修复完成。这里有三个容易踩的坑：
命令行的PHP不等于干活的PHP。CLI、PHP-FPM、Apache mod_php可能来自不同软件包、不同版本，容器里装的PHP与宿主机没有必然关系；必须先查实际处理线上请求的服务进程，记录PID、启动时间和二进制路径，一台主机上可能有多个FPM主进程，要逐个核对监听端口和对应的站点。知乎
发行版软件包的版本号会"骗人"。Linux发行版或LTS厂商可能把安全补丁反向移植进旧版本、同时保留原来的主版本号，不能只看`php -v`的输出，要结合发行版安全公告和软件包变更记录判断。
资产清单比单台机器更重要。跑在Docker/Kubernetes里的站点，先导出Deployment、StatefulSet、Job、CronJob的镜像清单，按镜像摘要去重后再逐一检查；用虚拟主机或建站服务的用户，则要向主机商确认服务器端PHP是否已更新到修复版本、站点当前切换的PHP版本是否也在修复范围内——这部分你自己无法打补丁，也最容易漏掉。
修复与验证：升级之后必须重启
官方已在10月21日发布四个安全修复版本：PHP 8.2.35、8.3.36、8.4.27、8.5.12，各分支源码包与Windows二进制均已上线官方下载中心。生产环境优先使用系统包管理器或发行版官方源的安全更新，不建议直接拿源码编译覆盖系统包；容器环境要重新构建或拉取基础镜像后重建应用，而不是只在容器里敲一条升级命令。知乎
升级完成后务必完整重启Web服务器和PHP进程（`systemctl restart php-fpm`或`systemctl restart apache2`/`httpd`），使内存中常驻的旧版工作进程彻底退出并加载修补后的新版本——只reload不重启，旧Worker可能仍在对外服务。验证的标准不是"命令存在"，而是所有处理请求的Worker启动时间都晚于升级重启时间；多实例环境建议先从负载均衡摘除单台、等连接排空再重启，逐台推进。知乎
PHP 8.1及更早版本（含大量仍在线上跑着的PHP 7.x、5.x）已停止维护，官方不发预编译包，只在源码仓库为自行编译者和LTS发行版维护者提供最小化的反向移植补丁。这类"老站点"的正确处置是：优先安排迁移到受支持的8.2+分支；确实做不到、又不能立刻下线的，用下一节的临时缓解撑过窗口期，并把它当作限时状态而非长期方案。知乎
来不及升级时，官方认可的临时缓解（有代价）
补丁到位之前，以下配置只能降低已确认攻击路径的风险，不能把主机重新标记为安全，且必须写入php.ini、FPM Pool或服务器端配置——写在应用代码`ini_set()`或`.user.ini`里无效，因为漏洞路径可能在应用代码执行前就已触发。
将`memory_limit`设为`-1`并放在应用无法覆盖的位置，去掉攻击者可利用的"内存限制失败"触发路径；代价是失控请求可能吃满内存拖垮服务器，必须同时用容器或cgroup划定资源边界，且不要用RLIMIT_AS/RLIMIT_DATA替代——官方特别提醒，这两类限制本身可能制造漏洞所需要的内存分配失败条件。知乎
收紧上传与请求体：不需要文件上传的业务把上传大小压到最小，需要上传的按真实业务统计后设置，并在Nginx层同步限制请求体大小、multipart分段数、表单字段数与Header数量，变更前先备份配置。
关闭会话上传进度功能（`session.upload_progress`）；PHP 8.5临时关闭致命错误回溯。
WAF、IP白名单、关闭后台入口可作为额外防线，但目前不存在能证明覆盖全部攻击变体的通用WAF规则；`disable_functions`同样修不了PHP内核的内存破坏，即使禁用了`exec`、`system`，攻击者仍可能通过其他PHP能力读写文件、连接网络或窃取进程凭据。
修完之后：检查是否已经"中招"
日志里出现PHP内存耗尽（OOM）类错误只能作为线索，不能单独写进事故报告当作入侵证据——大数组、图片处理、批量导入同样可能把内存打满，正确方法是建立关联：同一时间段、同一入口的异常请求模式、陌生计划任务、被修改的文件、新增的异常进程，多项同时出现才升级判断。一旦怀疑已被入侵，标准处置是断网隔离而非直接重启掩盖现场，保留日志做取证；网站若有数据库账号、密钥等凭据在服务器上，应视为已泄露并全部轮换。知乎
接下来几天值得普通站长持续关注的信号：发行版和云厂商的包更新公告是否已覆盖你的环境、主机商是否推送了修复后的PHP版本选项，以及PHP官方对EOL分支补丁的进一步说明。这次事件真正改变的是容错空间：当漏洞出在所有网站的共同底座上，"等有空再升级"的习惯，代价已经从一次宕机变成了整台服务器。
