事故过去六周，状态页上还只写着「错误率上升」

事故发生六周后，Cloudflare 的状态页上仍然只写着一句「错误率上升」。真正的性质，要到 10 月 26 日复盘发布才公开。

一、发生了什么

站内此前写过这起事件的根因与修复细节，本文不重复，只补三条 Cloudflare 视角的新增量。

第一条是披露的时间线。8 月 27 日到 9 月 9 日间，Workers AI 上某长上下文模型的 155 条回复串入了其他客户的内容；9 月 8 日晚，安全公司 Knostic 的研究员通过漏洞赏金渠道提交报告，40 分钟内下线、当晚修复——管理层复盘里有一句很直白的自省：上线前明知配置错配，测试只核对了响应码和耗时，没核对输出内容对不对，这正是没执行的那项检查。修复速度没得挑，但对外解释晚了近七周——期间用户只能从状态页看到模糊的错误提示，无从判断自己是否中招，更谈不上自检。

第二条是开源引擎的旧线索。引擎侧那个「拒绝请求未被正确终止」的缺陷，早在 7 月初就被另一位用户单独报告过；相关修复 9 月 6 日已合入主分支，但还没进正式发布版本。Cloudflare 是在调查中才发现这份旧报告，随后把自家补丁也提交了上游。引擎维护方同日发文，并确认单机部署下同一路径会正常报错——问题特定于预填与解码分离的部署形态；研究员的完整报告按其说法也将随后公开。换句话说，这个雷在生态里已经躺了三个月，踩到它的只是第一家把百万 token 上下文推上线的大厂。

第三条是新增的闸门。除扩容缓存池外，Cloudflare 加了部署前校验：缓存池容量必须不小于上下文窗口，两处数字从此写在同一条检查项里；所有用该引擎服务的模型统一加固；并且正在探索页级标记，让引擎宁可对请求报错，也不返回别人的数据。

二、跟你有什么关系

自建推理的团队：旧缺陷报告可能就躺在你的 issue 列表里，值得翻一遍。用托管长上下文的开发者：Cloudflare 事后核对了流量形态，排除测试流量后与正常使用一致、没有蓄意利用的证据，但它至今没说哪些客户中招、串出的是什么内容——你在 8 月底 9 月初发过的超长提示词里如果有敏感信息，只能自己复盘。管安全流程的人：状态页口径和事故等级不一致，是信任崩塌的第二现场。

三、怎么判断

1. 跑分离式部署的，升级到引擎 0.5.22 或更高版本，这一批修复已进正式版。
2. 把「缓存池不小于上下文窗口」写进部署检查单，做成机器校验而不是口头约定。
3. 自己的事故通报模板里加一条：定性结论必须在修复完成后一个明确期限内发布。

四、三个别信的说法

修复快就不欠用户一个交代。 六周里受影响客户无从自检，披露滞后本身就是事故的一部分。

锅全是开源引擎的。 配置错配是厂商定的，旧报告也早就在那里，两头都该认账。

错误页频繁出现只是不稳定。 这次的「错误率上升」底下藏着串页，表象和性质差着一个量级。

五、一句话结论

修复的速度和披露的速度是两种能力，成熟的平台两个都得有。

信息来源

• OSCHINA：Cloudflare 披露 KV 缓存暴露事故与修复（2026-10-27）
• Cloudflare 博客：事故复盘（2026-10-26）

功能与价格以官方公告为准。本文写于 2026 年 10 月 28 日。