HN 告知：我在不知情的情况下打破了 PHP RCE 禁止披露协议。对此我很抱歉。
一个备受关注的 PHP 远程代码执行漏洞及其处理不当的禁止披露协议，引发了关于在约定发布日期之前敏感细节扩散时究竟该由谁负责的争论。评论者大多认为，未正式加入该协议的人不可能“打破”它，责任应归于糟糕的流程，而不是在信息不完整情况下出于善意行动的个人。讨论还延伸到协调披露与“负责任披露”的区别、该漏洞在现实中的严重程度、AI 生成概念验证、以及公开道歉是否真的会改变安全事件中的法律或社会责任。
背景：禁止披露与“泄露”
- 媒体将此前一篇关于 PHP RCE 的帖子归咎为“打破了禁止披露协议”。
- 许多人认为，你不可能打破一个你从未被告知、也未参与其中的禁止披露协议；上游的禁止披露其实早就已经被打破了。
- 也有人指出，既然知道有一项计划中的公告，至少应当意识到可能存在协调披露的预期。
“承担全部责任”的含义
- 一些评论者称赞公开承认错误，认为这种道歉是真诚的，也具有社会价值。
- 另一些人批评“承担全部责任”之类的说法含糊不清、像企业套话，除非它意味着真实后果（例如赔偿）。
- 也有人警告，自我归咎可能掩盖流程失败，把系统性问题变成个人替罪羊叙事。
法律风险与道歉
- 少数人警告，明确承认可能招致轻率诉讼，尤其是在美国，并建议删除此类帖子。
- 其他人反驳说，法院不会奖励毫无根据的案件，缺乏深厚财力的被告也没那么有吸引力，而在某些领域，道歉反而可以减少冲突。
- 大家普遍同意，发帖者对一个自己从未加入的禁止披露协议并没有法律义务。
PHP RCE 的严重性与可利用性
- 一派认为，这个漏洞并不容易利用，媒体把它炒得过头了，而且和许多其他 CVE 类似；ASLR、速率限制和现代技术栈等缓解措施会降低风险。
- 另一派坚持认为它是严重漏洞（“5 级警报火灾”），在默认 PHP 应用上可被利用，而且必须遵从主要厂商的紧急指导（让 PHP 应用下线，立即打补丁）。
- 关于 ASLR 和“heap feng shui”到底有多重要存在争议；有人说 ASLR 让它很难利用，另一些人则给出 PoC，并表示 ASLR 并不是致命障碍。
- 许多人强调，真正重要的是是否存在未公开的可用利用链，而不是随机公开 PoC 是否失败。
禁止披露机制与 AI
- 禁止披露的目的：允许补丁同步发布，避免防御者与能逆向预发布修复的攻击者赛跑。
- 争论焦点在于，一旦线索和 CVE 编号公开，AI 是否能迅速重新发现漏洞，使禁止披露变得脆弱。
- 有人认为，这次事件可被视为未来更多 AI 辅助 0day 发现的预演，并强调需要重新思考披露流程。
社区与流程教训
- 一些人强调无责事后复盘，以及改进披露流程，而不是指责个人。
- 另一些人把整个场面看作安全行业的戏剧化表演和媒体耸动。
- 许多人安慰原帖作者，强调其动机是善意的，并敦促不要把一个复杂的、多方参与的失败过度个人化。