“已知”究竟是指谁已经知道？
谈到已知安全漏洞时，往往还缺少一个关键问题：谁已经知道？研究团队可能已经分析漏洞并私下向厂商报告，但企业尚未收到公开通告。之后，厂商可能已发布更新，而受影响的企业还没有部署。这两种情况需要不同的应对。
因此，企业的补丁管理可以看作一连串可追溯的决策：哪些系统受影响？谁有权变更？应该采用哪项修复？修复是否已经实际生效？仅靠未解决的 CVE 数量，无法回答这些问题。“严重”级别也不能替代资产清点和对具体服务的核实。
有用的状态说明，应当指出下一项缺失的证据。“厂商正在调查”“软件包已获批准”或“尚未验证运行实例”，都比笼统的“处理中”更有助于推进工作。
PHP2Shell：时间线能够说明什么
PHP 事件涉及上述多个状态。以下选取的节点，区分了早期迹象、非公开协调和公开发布。Calif 的日期来自其事后披露的过程记录；PHP Foundation 也记载了 8 月 11 日的报告。
从 Calif 于 8 月 11 日提交首次报告，到 10 月 21 日发布修复版本，相隔 71 个日历日，按日期差计算，不计起始日。这个数字既不表示期间无人处理，也不表示漏洞已公开了 71 天。它同样无法说明某家托管服务商或客户何时真正启用了修复。 [1] [2] [3] [4]
左右滑动可查看完整表格。
| 时间 | 已记录的状态 | 不能据此得出的结论 |
|---|---|---|
| 2024 年 | 出现内存耗尽（OOM）问题的早期迹象，当时尚未证明具体攻击路径 | 不能证明当时已有公开可用的 PHP2Shell 攻击方法 |
| 2026 年 8 月 11 日 | Calif 向 PHP 非公开报告了其发现的第一项漏洞 | 不等于已向所有运营方公开预警 |
| 2026 年 8 月 15 日 | 据 Calif 记载，PHP 确认了其提供的演示 | 不等于更新已完成交付并在所有环境中部署 |
| 2026 年 10 月 21 日 | 针对最初两项 CVE 的修复版本公开发布 | 不能证明每个运行实例都已完成修复 |
| 2026 年 10 月 23 日 | 针对一种特定会话配置发布了补充通告 | 不等于全面撤回最初两项修复 |
漏洞确认后，为什么不能立刻交付更新
PHP Foundation 指出了兼容性、性能、可能引入的新故障风险和扩展变更之间的技术取舍。同时，专业人员的可用投入有限；它也将相关决策流程评价为结构性失灵，并介绍了改革措施。信息提前流出后，发布计划提前了一天，而发行方当时仍在准备可安装的软件包。
这些解释并不能成为拖延的通用理由。它们说明，升级处理时应当明确回答：缺少的是可靠复现、技术决策、验证，还是向软件包提供方的交接？每个未完成环节都需要责任方和下一次检查时间。将所有问题都归结为“补丁还在等”，反而难以识别和处理瓶颈。 [1]
两项研究揭示了什么，又有哪些边界
补丁管理研究有助于更细致地理解实际工作流程，但不能提供当前全球未受保护企业的比例。因此，数字旁应同时标明论文发表年份、数据采集时段和统计单位。 [5] [6]
左右滑动可查看完整表格。
| 研究与数据基础 | 观察结果 | 结论的适用边界 |
|---|---|---|
| ten Napel 等，2025 年：一家荷兰政府机构；工单覆盖 2015 年 8 月至 2022 年 11 月；分析了 92 个主工单 | 37 个被归类为已打补丁的主工单，从创建到关闭的时长中位数为 13.2 天 | 单一机构中选定紧急通告的案例研究。工单关闭不等于对实际运行环境进行了测量验证，该时长也不是建议处理期限。 |
| Jenkins 等，2024 年：2021 年 8 月 24 日至 9 月 7 日，对 220 名系统管理员开展在线调查 | 220 人中有 80 人报告可以使用专门的测试环境；107 人采用分阶段部署 | 非随机样本的自我报告，允许多选。没有专门测试环境不等于没有测试，也不能据此推算 2026 年全球情况。 |
从交接环节审视自身流程
我们的工作框架从系统出发，而不是从更新目录出发。只有将通告对应到具体服务和负责的角色，才能形成可执行的任务。资料缺失时，应保留“是否受影响尚未确认”的状态，而不是草率地标为低风险。
接下来明确目标状态、功能检查和恢复方案。如果暂时无法部署修复，临时措施必须记录理由和复核日期，不能在无人确认的情况下变成长期方案。变更后，还要核查实际运行的实例，包括所需的重启或新部署的容器。
NIST 将打补丁视为预防性维护。其指南要求验证安装及生效情况，并持续检查，包括恢复备份或重置后的状态。后续恢复操作可能重新引入旧版本。 [7]
确认是否受影响
将通告对应到实际系统，记录对外暴露情况、证据和责任归属。
实施变更
确定目标软件包、审批和恢复方案，为临时防护设置复核日期。
验证是否生效
检查运行中的实例及重要功能，明确保留尚未解决的问题。
完成验证后再结案
新版本可供下载、安装流程执行成功、工单已经关闭，分别只能提供部分证据。关键在于受影响服务当前实际运行的是什么状态。
Cyberkern 自行设计的工作框架。图示说明核查流程，不代表从研究中推导出的成功率或固定处理期限。
托管、内部 IT 与应用：各环节由谁负责？
“放在云上”并没有说明谁负责。以 AWS EC2 为具体例子，AWS 区分了自身维护的基础设施，以及由客户维护的客户机操作系统和已安装应用。在抽象程度更高的服务中，责任划分有所不同。未经核实，不应将这一例子直接套用到您的托管合同。
对每项服务，都应明确谁评估厂商通告、谁维护基础系统、谁测试应用、谁确认完成。业务负责人参与确定哪些功能必须保持可用；技术运营方说明具体变更及其证据。如果由供应商负责，记录中应附上该供应商针对具体事项的答复；一般性的状态页面往往不足以回答相关问题。 [8]
为下一个实际问题准备一份空白记录表
补丁登记表是 Cyberkern 自行设计的工作辅助工具，并非经过上述研究验证的标准流程。每一行将系统、厂商通告、责任归属、措施和结案证据关联起来。请使用角色或团队名称，避免填写个人联系方式；不要写入密码、密钥或机密日志内容。
CSV 文件仅包含列标题。记录未完成事项时，应当与记录已完成工作一样认真。计划安装不等于可以结案。回滚后应重新评估防护状态，不能悄然将过去的验证结果当作当前状态的证据。
- 记录系统及是否受影响，并附上可追溯的证据。
- 明确负责的技术角色或供应商，以及决策路径。
- 确定目标软件包或配置变更，以及恢复方案。
- 记录临时措施、期限和下一次复核时间。
- 变更后检查实际运行状态和重要业务功能。
- 附上结案证据；尚未解决的问题保留为未完成，并写明下一步。
下一次进度复核，值得问哪些问题
不要只问关闭了多少工单。还应问：哪些可从公网访问的系统尚未确认是否受影响？哪些临时措施已超过复核期限？哪里仍缺少修复实际生效的证据？将责任归属确定、修复启用和最终验证所用时间分别统计，才能看清工作滞留在哪个交接点。
外部安全评估有助于识别对外可见的系统和异常。内部软件包状态、责任归属以及是否曾经遭到入侵，还需要额外证据。更新成功不能替代事件调查。初次咨询时，说明待评估的服务和您的问题即可；敏感运维资料可以之后通过双方约定的渠道提供。
参考来源
- PHP Foundation · Security release and disclosure background (21 October 2026)
- Calif Research · PHP2Shell discovery and disclosure timeline
- PHP · Critical remote code execution vulnerabilities (21 October 2026)
- PHP · Session upload progress advisory (23 October 2026)
- ten Napel, van Eeten & Parkin · Speedrunning the Maze (IEEE S&P 2025)
- Jenkins et al. · Not as easy as just update (CHI 2024)
- NIST SP 800-40 Rev. 4 · Guide to Enterprise Patch Management Planning (2022)
- AWS · Shared Responsibility Model