PHP 8.2.35

原文 ↗ Hacker News 讨论 ↗

PHP 8.2–8.5 的紧急安全更新旨在修补两个严重的“PHP2Shell”漏洞，这些漏洞可在几乎任何由 PHP 驱动的 Web 服务器上实现未认证远程代码执行，包括 WordPress 和共享主机平台等常见栈。评论者交换了短期缓解手段（禁用上传进度、阻止 multipart 表单数据、收紧内存限制、激进重启 worker），同时等待来自发行版、云提供商和第三方仓库的已修补软件包与 Docker 镜像。此次事件也引发了更广泛的担忧：AI 辅助漏洞挖掘时代的协调披露、部分厂商缓慢的补丁发布，以及仍支撑着大部分网络的未受支持 PHP 5/7 安装所留下的长尾问题。

新版本与漏洞

  • 安全更新：PHP 8.2.35、8.3.36、8.4.27、8.5.12；此外还有针对 7.4、8.0、8.1 的最小化源码回补。
  • 两个严重漏洞（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）可通过内存不足处理和 multipart 解析实现 RCE；据称所有 web SAPI 都存在风险（FPM、mod_php、CGI 等）。
  • 漏洞与请求初始化期间的 OOM、基于 longjmp 的错误处理以及 multipart/form-data 解析有关；代码库中新增了许多针对 OOM 的防御性检查。

缓解措施与运维响应

  • 常见的临时缓解措施：
    • 禁用 session.upload_progress.enabled。
    • 在 Web 服务器层阻止 multipart/form-data 请求，但这会破坏文件上传。
    • 在 FPM 中设置 pm.max_requests=1，避免复用陈旧状态。
    • 降低 post_max_size 和 max_input_nesting_level。
    • 确保上传目录中不提供任何 .php 文件，并移除 phpinfo.php。
  • 一些运维人员在补丁可用前让 PHP 站点下线或关闭前端 Web 服务器；另一些则在 Web 服务器与 FPM 之间临时加上反向代理/过滤器。
  • 关于 CGI/经典的一请求一进程模式在实践中是否可被利用存在争论；官方公告将所有 SAPI 都视为有风险。

发行版、PPA 与 Docker 的补丁滞后

  • Debian（包括 oldstable 以及部分 PHP 7 回补）和 Gentoo 很快进行了更新；Ubuntu 的安全更新则较慢，而且在各 LTS 版本之间不够一致，但最终也已落地。
  • Ondřej Surý 的 Debian/Ubuntu 仓库以及其他第三方仓库（包括针对 PHP 5.6/7.4 的仓库）较早发布了已修补构建；Launchpad 和 PECL 一度过载。
  • PHP 以及热门应用（WordPress、Matomo、Nextcloud）的官方 Docker 镜像明显偏慢，或短暂发布了仍使用易受攻击 PHP 的镜像，导致许多人改为自行重建镜像或直接使用发行版软件包。

旧版 PHP 与共享主机

  • 生态中很大一部分仍在运行 PHP 5/7；一些发行版和社区维护者已回补修复，但官方 PHP 仅对 7.4 提供了最小补丁。
  • 托管 WordPress 和共享主机提供商的做法不一：有些强制关闭所有 PHP 站点；另一些则在数小时后才推送修补版本，令用户感到沮丧。

AI 的角色与披露过程

  • 这一漏洞链被归因于使用 LLM 的安全公司所做的工作；关于协调与禁运是否处理失当、是否过于公关化，存在强烈争议。
  • 有人认为，更早、更安静的修复，或者在泄漏后更快发布，会减少混乱；也有人指出，在 LLM 时代，任何公开补丁都会立刻暴露漏洞。
  • 评论区围绕“AI slop”展开了大量元讨论，既有批评（信任度低、报告嘈杂），也有赞赏（缓解措施快、生成了工具和审计）。

技术与文化反应

  • longjmp、手动 OOM 处理以及分散的 goto 式检查被批评为不安全的 C 编程模式；也有人指出，这类技术在解释器中很常见。
  • 一些人认为这再次说明 PHP 是“糟糕设计的分形”，并主张迁移离开 PHP，尤其是在 AI 可以帮助移植代码的当下。
  • 另一些人则反驳称，所有主要运行时（JVM、V8 等）都会出现严重 bug；PHP 的无处不在让它的失败更显眼，而不是本质上更糟。