PHP2Shell 到底发生了什么？
2026 年 10 月 21 日，PHP 发布了针对 CVE-2026-109618 和 CVE-2026-109619 的安全更新。在满足相关条件时，这两处漏洞均可能允许攻击者在未经身份验证的情况下远程执行代码。两者的 CVSS v4.0 评分均为 9.2。这一评分反映技术严重程度，并不代表某家企业已经遭受攻击的概率。
PHP Foundation 说明了内存问题修复中的延误，以及协调披露过程中的问题。信息提前公开，促使修复版本比原计划提前一天发布。对于运维负责人，眼下最重要的是确认：哪些正在运行的系统已经真正应用修复。 [1] [3] [4]
哪些 PHP 版本包含修复？
下表列出针对 10 月 21 日披露的两处漏洞，PHP 项目首次发布修复的版本。它不代表系统已经解决 10 月 23 日新增披露的 CVE-2026-115560。还应持续核对厂商后续公告。
Linux 发行版和托管服务的软件包可能保留较旧的 PHP 版本号，同时回移安全修复。这种情况下，应以完整的软件包版本和厂商安全公告为依据。PHP 8.1 及更早分支已不再获得 PHP 项目的常规更新；厂商回移补丁或已提供的最小源码补丁，需要单独核验。它们不能替代迁移到受支持分支的计划。 [1] [4]
左右滑动可查看完整表格。
| PHP 分支 | 修复版本 | 所需依据 |
|---|---|---|
| 8.2 | 8.2.35 | 已生效的网站运行软件包，或有据可查的厂商回移补丁 |
| 8.3 | 8.3.36 | 已生效的网站运行软件包，或有据可查的厂商回移补丁 |
| 8.4 | 8.4.27 | 已生效的网站运行软件包，或有据可查的厂商回移补丁 |
| 8.5 | 8.5.12 | 已生效的网站运行软件包，或有据可查的厂商回移补丁 |
单独核查 10 月 23 日的会话补充公告
PHP 建议暂时设置 session.upload_progress.enabled=0，直至下一个常规缺陷修复版本发布。该公告涉及 CVE-2026-115560，触发条件是配置与应用代码的一种不常见组合。它应与已经修复的前两处漏洞分开处理。
公告给出的条件很具体：session.serialize_handler 初始值为 php_binary 或 php_serialize；应用在调用 session_start() 之前，通过 ini_set() 将其在运行时改为 php；与此同时，会话上传进度功能处于启用状态。PHP 表示，从不在运行时更改该处理器的应用，可以保留此功能。
请管理员核查实际生效的设置。作为预防措施关闭此功能时，应在请求解析之前生效的服务器或 PHP 配置中设置，并重启受影响的工作进程。应用代码中较晚执行的 ini_set() 不能替代这一配置。已经应用该设置的系统应继续保留。公告尚未给出常规修复版本的发布日期或新版本号。本文核查时间为 2026 年 10 月 24 日。 [1] [2]
为什么只更新 WordPress 还不够
内容管理系统与 PHP 运行环境是不同的组件。因此，WordPress、Drupal 或 Joomla 已更新，并不能证明网站服务器正在使用修复后的 PHP。网站能够正常打开，也不能证明补丁已经生效。
除了主站，还应检查商城、客户门户、子域名和旧安装实例。逐一确认各系统实际使用的网站执行环境。PHP-FPM 并不自动排除在影响范围之外；PHP 公告还提及 mod_php、CGI、FrankenPHP 和 LiteSpeed。命令行使用的 PHP 安装可能与网站服务器不同。不要为了核查而发布任何可公开访问的 phpinfo() 页面。 [1] [5]
确认系统
记录域名、应用、托管负责人，以及实际处理请求的 PHP 运行环境。
启用修复
安装适用的软件包，更新受影响的工作进程，并单独核查会话配置。
验证运行
记录已生效的软件包、功能检查结果和时间。尚未查清的系统继续跟进。
以可核验的结果结项
每套系统都需要明确负责人、厂商依据，以及对运行实例的检查。仅凭命令行显示的版本号还不够。
原创示意图。这些核查用于记录系统运行状态，不能证明系统此前从未遭到入侵。
应向托管服务商索取哪些确认
“我们的服务器已是最新版本”这样的笼统回复，无法回答关键问题。请服务商针对您的具体系统作出确认。可以参考以下措辞：
请确认我们网站实际使用的 PHP 运行环境与完整软件包版本、CVE-2026-109618 和 CVE-2026-109619 的修复状态，以及如何落实 PHP 于 2026 年 10 月 23 日针对 CVE-2026-115560 发布的公告。请同时提供生效时间，以及对应的厂商或发行版安全公告。
左右滑动可查看完整表格。
| 核查问题 | 所需依据 | 仍未解决的情况 |
|---|---|---|
| 涉及哪些系统？ | 域名及其对应的网站运行环境 | 只列出了主站 |
| 应用了哪项修复？ | 软件包版本与涵盖两项 CVE 的厂商公告 | 只回答“PHP 8”或提到内容管理系统更新 |
| 修复已经生效吗？ | 生效时间，以及工作进程已更新的确认 | 软件包仅处于可安装状态 |
| 会话公告是否已核查？ | 实际生效的设置，或不受影响的书面依据 | 只提到 10 月 21 日的更新 |
| 应用功能是否正常？ | 登录、表单、上传及相关任务的检查结果 | 仅确认首页能够打开 |
WAF 告警和攻击尝试能够说明什么
网站应用防火墙可以针对部分攻击路径提供额外保护，但不能替代 PHP 更新，也不能替代对实际配置的核查。如果暂时无法更新，应与负责的管理员商定限制访问等措施，或临时隔离系统；具体应遵循厂商完整指引。
AWS 在 MadPot 遥测数据中记录到了公开披露前的攻击尝试。AWS 同时说明，尚不清楚这些尝试是否能在真实系统上成功。因此，攻击尝试次数不能当作已被入侵的企业数量。同样，监控面板没有异常，也不能证明实例从未受到影响。 [1] [5] [6]
怎样才算完成这次核查
为每套系统记录负责人、实际生效的软件包、厂商依据、生效时间和功能测试结果。将补丁验证与事件调查分开：今天已经修复的系统，并不能解释更新之前发生了什么。
如果出现异常文件变更、意外进程或可疑访问等入侵迹象，应保全现有日志，并联系负责的事件响应团队。外部安全评估可以核查对外可见的系统和异常；如果没有额外证据，不能最终确认内部软件包状态，也不能对是否遭到入侵作出定论。
- 已登记相关 PHP 网站系统及其负责人。
- 已在运行实例中验证前两项 CVE 的修复生效。
- 已单独核查并记录 10 月 23 日会话公告的处理结果。
- 已在变更后检查关键业务功能。
- 已为尚未解决的系统明确下一步措施与期限。
- 可疑事件已单独调查，未将安装补丁当作取证层面的安全结论。
参考来源
- PHP · Critical remote code execution vulnerabilities (21 October 2026)
- PHP · Session upload progress advisory (23 October 2026)
- PHP Foundation · Security release and disclosure background (21 October 2026)
- NHS England · Critical Vulnerabilities in PHP, CC-4875 (21 October 2026)
- NCSC · Critical security issue affecting PHP (21 October 2026)
- AWS · PHP2Shell attempts observed in MadPot (21 October 2026)