PHP 官方近期发布安全公告，修复了 CVE-2025-1734 和 CVE-2025-1735。前者指向 php_stream_temp 路径的潜在堆溢出，后者位于 phar_parse_zipfile 的 ZIP 归档解析环节。媒体常称这次为“两个严重漏洞”，但风险等级不等于每台 PHP 机器都能被一条远程请求拿下。
堆内存破坏麻烦在于，表现未必直观：可能是请求 500、FPM worker 异常退出或 Segmentation fault，也可能在特定条件下影响后续执行。能否利用，取决于攻击者能否把特制输入送进临时流或归档解析路径，以及 PHP 以 FPM、CLI、CGI 还是其他方式运行。“所有 PHP 都已被攻破”不准确，“与上传和压缩包处理无关”同样危险。
这两项漏洞很有运维味。PHP 常被 CMS、后台和下载站用来处理外部数据，站点表面是“上传压缩包”，后端却可能进入 PHAR 或临时文件机制。漏洞不等于新 0day，但公开公告会降低门槛：过去要靠熟悉内存布局的人反复试，现在可借助 AI 生成模糊测试脚本、批量比较响应。AI 不会创造堆溢出，却能把试探变成流水线。
这也是 AI 时代最不好听的一点：AI 更像放大器。防守端可用它读公告、比对版本、整理日志和生成测试用例；攻击端也能让它改写载荷、分析报错、适配不同框架。我不会把未经核验的 AI 命令直接放进生产环境，任何复现也应限于自有测试环境并取得授权。它能帮我列检查项，补丁范围、配置影响和回滚方案仍要回到官方公告与实际验证。
这次该怎么做
我会先盘清资产，再核对官方修复版本，而不是急着在 WAF 里加两条规则。
- 先查真实版本：CLI 和 FPM 可能不是同一套 PHP，多版本服务器尤其容易漏。记录
php -v、php -i、扩展目录和进程方式；容器还要核对镜像摘要，不能只看 Dockerfile 标签。 - 按公告升级：仍受支持的 PHP 分支要选择对应补丁版本，优先使用发行版或 PHP 官方源。不要从第三方站点单独替换
.so，扩展与 PHP ABI 绑定，混用可能直接启动失败。 - 做业务回归：除首页和登录，还要测上传、下载、压缩包安装、导出和队列任务。确认实际 FPM 已重启、加载了预期扩展，再观察 5xx、502 和 worker 重启数量。
- 无法立刻升级时：限制外部文件进入高风险路径，收紧上传目录权限，禁止上传目录执行脚本，降低应用账号权限。
phar.readonly=1只阻止 PHAR 写入，不能修复读取解析漏洞；WAF 也只能短期缓冲。
下面这组命令比面板上的版本号更可信：
type -a php
php -v
php -m | grep -Ei 'phar|zip'
php -i | grep -E '^(Server API|Loaded Configuration File|extension_dir)'
ps -ef | grep '[p]hp-fpm'type -a php 可以发现多套二进制，Server API 能区分 CLI 与 FPM。宝塔或 1Panel 面板显示的版本，不一定就是站点进程加载的版本；容器站点还要回到容器内检查。
修复前已有异常时，可对照 Web 日志、PHP-FPM 日志和内核日志。重点筛选 HTTP 500/502、异常大请求、上传接口报错、worker 重启和 core dump。有权限时，dmesg -T | grep -Ei 'php|segfault' 能辅助定位崩溃痕迹。发现崩溃不等于已经证实被利用，公开工单也要先脱敏。
AI 时代，攻防成本会继续拉开
坏消息是自动化正在压低攻击门槛，防守端也能用同样速度找资产、核公告、验补丁。差距不在有没有用 AI，而在闭环是否完整：资产清单、补丁优先级、变更验证、日志告警和回滚预案，缺一项，效率优势就可能变成新的风险。
我的判断很明确：AI 时代对运维没有单纯的好坏，它会放大流程里原有的缺口。流程严谨，AI 是省时间的放大器；补丁拖延、资产混乱，AI 就会变成批量试探的放大器。PHP 这次更新提醒我们，安全新闻不能读完就转发。回到自己的服务器，确认版本、运行方式和业务回归，才算把新闻变成了处置动作。