PHP 安全更新后：先修补，再检查凭据和访问权限

PHP 于 2026 年 10 月 21 日发布 8.5.12、8.4.27、8.3.36 和 8.2.35，修复可能允许未经身份验证的远程代码执行的严重漏洞 CVE-2026-109618 和 CVE-2026-109619。官方公告指出，包括 PHP-FPM 和 Apache mod_php 在内、处理网页请求的部署存在风险。更新才是完整修复，临时缓解措施不能等同替代。

存在漏洞 并不证明已经入侵。修补、调查和凭据恢复相互关联，但应根据实际环境与证据决策。

确认真正处理请求的运行环境

盘点运行 PHP 的公开网站、内部服务、容器和托管账号。确认处理网页请求的运行时版本与补丁状态；命令行显示的可能是另一个安装实例。

使用托管服务时，请运营方确认已应用的软件包、对应服务以及重启或更新是否完成。发行版可能把修复回移到旧版，因此应获取供应方的补丁确认，而不只看上游版本号。与运营方一起根据 PHP 团队安全公告核实范围。不要公开暴露服务器配置的诊断页面。

控制暴露并恢复可信环境

尽快与托管方或运维团队协调更新。如果事件评估要求，应保留相关证据，同时限制暴露或隔离受影响系统。不要为了收集完日志而耽误紧急遏制。

检查暴露时间段、网站和系统日志、异常文件或进程，以及相关服务的审计事件。没有告警或日志看起来正常，都不能证明主机未受侵害。

如果确认入侵或有合理怀疑，应按事件处理流程从可信来源重建或恢复。打补丁不会移除攻击者的持久化机制。不要在不可信主机或设备上生成、接收或安装替代机密。

先评估凭据，再安排轮换

列出受影响进程可能访问的凭据：应用配置、环境变量、部署令牌、数据库凭据、服务 API 密钥。判断其权限、范围及暴露可能性。单凭公告不能认定组织的所有凭据都已泄露。

对于可能暴露的凭据，应从可信管理员设备协调在签发服务中替换和撤销。在可信重建环境中安装新值，验证合法集成。依据是否正在被滥用、服务能力和依赖关系确定顺序；不要承诺零停机，也不要为了方便而无限期保留已暴露密钥。

按需检查会话和恢复权限，记录每项变更的负责人。不要把原始机密写入事件工单或日志。 OWASP

工作结束后清理紧急访问权限

为响应人员提供独立账号、最低必要权限和约定的结束时间。恢复后复查临时角色、会话、部署访问及交接链接。移除不再需要的残留访问，并在对应服务中确认结果，而不是只依赖日历提醒。

区分三种不同控制

控制措施	改变什么	不能做什么
交接链接过期	之后通过该链接的访问	撤销签发服务的凭据
服务端撤销密钥	服务是否接受该密钥	删除已保存副本或修复被入侵主机
删除消息或笔记	对应系统中该项的可用性	收回下载、截图或复制文字

恢复信任后才使用临时交接

流程允许时，可从可信系统创建密码保护备忘录，只交给已核实接收者所需的最少信息。单独发送密码，并在套餐支持时使用到期时间或访问次数限制。不要在交接中放入钱包恢复助记词或私钥。

LOCK.PUB 只是有限的信息交接工具，不能修补 PHP、修复感染设备、撤销服务密钥或收回副本。它不替代机密管理器、身份控制或事件响应。

常见问题

安装 PHP 更新后，调查就结束了吗？

不是。更新解决漏洞，而证据和暴露范围决定仍需要哪些调查、恢复和凭据操作。

备忘录过期会禁用其中的 API 密钥吗？

不会。必须在签发服务中撤销或替换密钥。已复制的凭据独立于传递它的链接。

相关阅读：了解边界后共享 API 密钥。