PHP 最新零日漏洞怎么没人讨论

好多业务都还在 php7 环境跑呐这下官方都不支持修补完蛋了

 [紧急安全预警] 关于 PHP2Shell (CVSS 9.2) 核心级 RCE 漏洞的修复指南

尊敬的客户：

您好！针对即将在北京时间 10 月 21 日（周三） 22:00 公开的 PHP 核心严重安全漏洞，我们在此向您发布最高级别的安全预警。

据国际安全机构 Sansec 披露，此次爆发的漏洞被称为 PHP2Shell 。目前该漏洞的自动化利用工具截图已在安全社区泄露，预计官方补丁发布后 15 分钟内，全网将出现大规模的无差别扫描与攻击。

漏洞核心情报
漏洞代号/编号：PHP2Shell (CVE-2026-109618, CVE-2026-109619)

危险等级：CVSS 9.2 （极度危险）

漏洞类型： 远程代码执行（ RCE ），攻击者可直接接管服务器获取 Shell 。

受影响版本：PHP 5.4 及以上所有版本。Magento 、Shopware 、WooCommerce 等电商系统及各类 CMS 将受严重威胁。

补丁发布时间： 北京时间 10 月 21 日（周三） 22:00 （ 14:00 UTC ）

⚠️ 核心警告：无法在代码层防御
该漏洞存在于 PHP 的底层架构中。这意味着任何代码级别的修改、面板加固或常规的应用层防护插件都无法拦截此攻击。防御的唯一有效方式是在服务器基础设施层面（环境底层）直接更新 PHP 版本。

紧急应对与修复建议
官方将仅为 PHP 8.2 、8.3 、8.4 和 8.5 发布修复补丁。请您立即采取以下行动：

1. 正在使用 PHP 8.2 - 8.5 的用户（需今晚紧急操作）：

随时待命： 请通知您的运维团队在今晚 22:00 前做好准备。

抢占黄金 15 分钟： 补丁一旦发布，请务必在第一波自动化攻击到来前，通过包管理器（ apt/yum ）或重新编译升级 PHP ，并立刻重启相关服务（ Nginx/Apache/PHP-FPM ）。

2. 正在使用 PHP 8.1 及以下旧版本（含 5.6 、7.x 等）的用户：

官方已明确不会为这些版本发布补丁。继续使用这些版本将让您的服务器完全裸露在 PHP2Shell 的攻击火力之下。

短期缓解： 立即排查并收紧服务器安全组及防火墙（ iptables/firewalld ）策略，开启高级别 WAF ，并在 php.ini 中禁用高风险命令执行函数。

长期建议： 请即刻安排业务环境迁移，将底层升级至受官方支持的 PHP 8.2+ 版本。

Supplement 1 · 12h 21m ago

临时措施修改 php.ini (非可信来源：

session.upload_progress.enabled = Off
session.upload_progress.cleanup = On
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_httponly = 1

漏洞

PHP

安全

103 replies • 2026-10-22 05:03:36 +08:00

1 2

❮

❯

101

jetttt

3h 28m ago

@loserc6 #71 得自己编译吗

102

vibbow

2h 58m ago

https://repos.zend.com/zendphp/
不方便升级 php 大版本的，可以用 zend 的修复版的

103

quu

53 mins ago

1 、紧急升级（首选措施）

PHP 官方已发布修复版本。预期修复版本为：PHP 8.5.12 、8.4.27 、8.3.36 、8.2.35 （以 PHP 官方安全公告实际发布为准）。

升级操作要求：

1. 定位所有 PHP 实例：逐个清点服务器、容器镜像、虚拟机及第三方设备中内嵌的 PHP 运行时，记录版本号（可通过 php -v 获取）。

2. 升级至修复版本：根据业务所运行的 PHP 分支，分别升级至 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 ，并确认升级后版本号与官方修复版本一致。

3. 重启服务进程：升级完成后，重启 PHP-FPM 池与 Web 服务器进程，确保新运行时生效；对于容器化部署，需重新构建镜像并滚动更新。

4. 验证生效：通过实际请求确认运行中的 PHP 版本已更新，不能仅以文件替换完成作为依据。

使用操作系统发行版、托管服务或云厂商提供的 PHP 时，应立即向供应商确认其已包含上述修复版本的安全更新，并按其指引完成升级与重启。PHP 8.1 及更早版本不会获得官方修复，必须迁移至受支持的 PHP 8 分支，或确认供应商已提供回移补丁。

2 、升级前的临时缓解（仅限无法立即升级的场景）

如果因业务约束无法在修复发布后立即完成升级，应在升级窗口前采取以下临时缓解措施，但不得以缓解措施替代最终升级：

· 禁用 session.upload_progress：将 session.upload_progress.enabled 设置为 0 。该设置可在一定程度上减少攻击面，但 PHP 官方尚未确认其对该漏洞的完整防护效果。

· 启用严格会话模式：将 session.use_strict_mode 设置为 1 。需注意，若应用使用自定义会话处理器且未实现会话 ID 校验，该措施可能不生效。

· 收缩网络暴露面：对非公开的 PHP 应用，限制为仅可信网络或管理网络可访问；对无法及时升级的互联网暴露 PHP 应用，评估临时隔离或下线处置。

· PHP-FPM 特殊注意：上述会话配置需应用于每一个 serving pool ，并 reload worker 后通过实际请求验证生效配置。

3 、修复后的“假定失陷”检查

由于该漏洞为未经认证的 RCE ，且信息在官方修复发布前已提前泄露，修复发布后存在被快速利用的现实可能。完成 PHP 运行时升级后，建议立即开展以下检查：

· 排查 Web 服务器进程是否在非预期路径下启动了子进程（如 /bin/sh 、curl 、wget 等异常派生）；

· 检查 Web 根目录及可写目录中是否出现新近创建或修改的可疑文件（ webshell 常见落地位置）；

· 审阅 Web 访问日志中是否存在针对 session.upload_progress 参数或异常 multipart 请求的可疑探测行为；

· 对曾暴露在互联网且未能及时升级的 PHP 实例，考虑按已失陷开展凭据轮换与主机取证。

来源： https://mp.weixin.qq.com/s/Gpt2ouEwYiYjeQMmELvcTw

1 2

❮

❯