10月21日晚，PHP 官方正式发布紧急安全公告，披露两个严重的 PHP 核心远程代码执行漏洞：CVE-2026-109618 和 CVE-2026-109619，CVSS v4.0 评分均为 9.2。
官方同步发布了 PHP 8.2.35、8.3.36、8.4.27 和 8.5.12 四个安全修复版本，并明确建议所有使用 PHP 处理 Web 请求的用户立即更新。
这次漏洞引起广泛关注，原因很简单：PHP 依然运行着大量网站和业务系统，而此次问题出现在 PHP 核心内部。即使应用本身没有明显的代码漏洞，也可能因为底层运行环境受到影响。
更值得注意的是，官方补丁刚刚发布，相关扫描流量就已经出现在实际网络环境中。
今天，我在日常安全监测中，通过微步 TDP 流量威胁检测设备捕获到了多条涉及 PHP Session 上传进度功能的可疑请求，其中一条还直接使用了 php2shell-scan/1.0 作为 User-Agent。
结合 PHP 官方刚刚披露的技术细节，这些流量值得进一步分析。
一、PHP 官方终于公布了漏洞细节
在10月20日的提前预警中，PHP 安全团队只公布了两个漏洞的严重程度和补丁发布时间，没有公开具体的漏洞原理。
直到10月21日正式公告发布，两个漏洞的技术细节才得到确认。
CVE-2026-109618：内存耗尽处理过程中的内存损坏。
当 PHP 发生内存耗尽（OOM）时，某些内部请求数据可能尚未完成初始化。后续清理过程如果将这些异常数据当作正常数据处理，就可能造成内存损坏，并在特定条件下导致远程代码执行。
CVE-2026-109619：请求结束后的全局状态残留。
PHP 在请求处理结束后，部分内部状态可能仍然保留，但其对应的内存已经释放。后续请求如果再次使用这些残留状态，就可能触发内存安全问题，最终造成远程代码执行。
官方确认，这两个漏洞均存在未经身份验证实现远程代码执行的风险。
受影响的部署方式包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed 等。其中，官方特别强调 Apache mod_php 的风险最高，已有演示表明，攻击者可能通过单个未经认证的请求，在应用代码运行之前触发漏洞。
这意味着，即使网站使用了成熟的 CMS 或框架，也不能因此忽视底层 PHP 运行环境的安全更新。
下图为PHP官方公告截图：
二、补丁发布当天，我捕获到了真实扫描流量
在正式补丁发布之前，我就开始关注 PHP2Shell 的相关技术信息。
由于当时漏洞细节尚未公开，能用于流量检测的可靠特征非常有限。考虑到一些公开讨论涉及 PHP Session 上传进度功能，我先在微步 TDP 中配置了一条临时监测规则，检测 HTTP 请求体是否包含：
PHP_SESSION_UPLOAD_PROGRESS
这是 PHP Session 上传进度功能使用的默认字段名。它本身并不代表恶意行为，也不是 PHP2Shell 的专属攻击特征。
因此，这条规则主要用于收集可疑流量，帮助观察是否有攻击者正在尝试相关技术，而不能直接作为漏洞攻击成功的判定依据。
规则上线后，很快就有了告警。
最初捕获到的请求主要针对后台验证码接口，采用 multipart/form-data 格式提交数据。其中一段内容比较特别：
jz|admin|a:6:{...}
从报文结构看，这段数据包含疑似管理员身份信息及 PHP 序列化内容。同一外部来源还对多个目标发送了相似请求，具有明显的自动化攻击特征。
不过，进一步分析后发现，这类请求更接近历史上已有的 PHP Session 注入或身份伪造攻击手法。目前没有足够证据证明它们与新披露的 PHP2Shell 漏洞直接相关。
部分请求返回了 HTTP 302，响应头指向 HTTPS 地址，说明流量可能在负载均衡层被重定向。但是否真正进入后端 PHP 应用，还需要结合反向代理及服务器日志确认。
这也说明，在高危漏洞刚刚披露时，检测规则命中和漏洞利用之间，往往还有很长一段分析工作要做。
三、随后出现了明确标识 PHP2Shell 的扫描请求
相比第一批告警，后面捕获到的一条请求更值得关注。
它的 User-Agent 直接写着：
php2shell-scan/1.0
请求采用 multipart/form-data 格式，并在请求体中重复提交了两个名为 PHP_SESSION_UPLOAD_PROGRESS 的字段，同时附带一个名为 a.txt 的测试文件。
部分报文结构如下：
User-Agent: php2shell-scan/1.0
Content-Type: multipart/form-data; boundary=...
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"
a|b|c
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"
k|v
Content-Disposition: form-data; name="f"; filename="a.txt"
Content-Type: application/octet-stream
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA从这些特征来看，请求具有较明显的专项扫描性质：工具名称指向 PHP2Shell，multipart 请求中包含重复的上传进度字段，上传文件内容也主要是用于测试的重复字符。
但这里仍然需要保持谨慎。
首先，User-Agent 可以由请求发起方任意设置，不能仅凭这个字段确认实际使用了哪一款扫描工具。
其次，重复提交 PHP_SESSION_UPLOAD_PROGRESS 并不等于成功触发漏洞。当前这条请求更适合归类为疑似 PHP2Shell 专项探测流量。
最后，流量中没有出现明显的命令执行载荷，也没有后端主机行为证据，因此无法据此判断攻击者已经实现远程代码执行。
对于安全运营人员来说，这类扫描请求的价值在于提供了明确的调查线索：哪些目标正在被探测、请求是否到达 PHP 后端、目标是否运行受影响版本，以及扫描之后有没有出现进一步的攻击行为。
四、官方补丁已经发布，哪些版本需要升级？
PHP 官方已经公布四个安全修复版本：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需要注意的是，PHP 8.1 及更早版本已经停止 PHP 项目的常规安全维护。官方针对 PHP 7.4、8.0 和 8.1 提供了最小源码回补，部分 Linux 发行版及长期支持厂商也可能提供补丁，但具体是否修复，需要以对应发行商的安全公告和软件包信息为准。
如果暂时无法完成升级，PHP 官方也公布了几项临时缓解措施。
针对 CVE-2026-109619，可以关闭 Session 上传进度功能：
session.upload_progress.enabled = 0修改后需要重启相关 PHP 工作进程。该措施可以阻断已经确认的部分 Session 攻击路径，但无法覆盖其他可能的利用方式。
针对 CVE-2026-109618，官方提出可以考虑设置：
memory_limit = -1这能够减少 PHP 内存限制触发的特定失败路径，但也可能增加内存耗尽风险。生产环境必须结合容器资源限制、业务负载和可用性要求进行评估。
此外，合理限制 POST 请求大小、上传文件大小以及 multipart 请求复杂度，也有助于降低部分攻击面。
需要强调的是，官方明确表示这些措施都无法提供完整防护，及时升级才是可靠的修复方式。
五、漏洞刚披露，安全运营该关注什么？
回顾这次 PHP2Shell 漏洞披露过程，有一个很直观的感受：从提前预警、技术信息传播，到出现疑似专项扫描流量，整个过程非常快。
对于安全运营人员来说，官方补丁发布之前，需要尽可能收集有效的攻击线索；补丁发布之后，工作的重点则应迅速转向资产排查、版本核查和修复验证。
这次实际捕获的流量也提醒了我，不能因为请求中出现了某个热门漏洞的关键词，就直接给它贴上新漏洞攻击的标签。
同样是 PHP_SESSION_UPLOAD_PROGRESS，有的请求更像历史 Session 注入攻击，有的则带有 PHP2Shell 专项扫描特征。两者的攻击意图、技术依据和后续排查方向并不完全相同。
而且，流量设备只能提供攻击链中的一部分证据。判断目标是否真正受到影响，还需要结合 PHP 版本、Web 服务器配置、反向代理日志和主机行为。
对于这次 PHP2Shell，当前最重要的事情已经很明确：尽快确认受影响的 PHP 资产，优先修复公网暴露系统，并持续关注已经出现的扫描流量。
官方补丁已经发布，留给高风险系统的修复窗口值得认真对待。
ㅤ