你发给AI的长文档，可能被另一个陌生人完整收到过 Cloudflare在10月26日自己披露了一起AI服务串数据事件：8月27日到9月9日，它家Worker… · @404latitude · TwKit

@404latitude

你发给AI的长文档，可能被另一个陌生人完整收到过 Cloudflare在10月26日自己披露了一起AI服务串数据事件：8月27日到9月9日，它家Workers AI上跑的GLM-5.3模型，有155条回复里混进了别的客户请求的内容。不是模型胡说八道，是不同客户之间的数据隔离失效了。官方同时说了两点：没有发现被恶意利用的证据，其他Workers AI模型不受影响。 ▌为什么会漏 两个故障叠在了一起。第一，模型对外宣称的上下文是1048576个token，但预处理用的KV缓存池只装得下681280个token，大约只有宣称值的65%。第二，推理引擎SGLang有个bug：超长请求本应被拒绝，却走了一条错误路径——预处理拿一个token的占位符顶替了整段提示，解码端却以为整段提示已经写进缓存，直接读了上一位用户没被覆盖的缓存页。更麻烦的是，客户端拿到的是HTTP 200成功码，而不是400报错，表面看一切正常。 ▌谁会被影响 只有一种情况会被波及：单次提示超过681280个token。平时聊几句、贴几千上万字文档，基本碰不到这条线。真正危险的，是把整库代码、整份财报、整本合同一次性塞进超长上下文的企业用法。据发现方列举，回流内容里出现过发票号、源码信息、文件路径这类本不该外流的东西。 ▌已经修好了吗 安全研究员Gadi Evron在9月8日通过HackerOne上报，Cloudflare在25分钟内复现，随后下线该模型，9月9日恢复。修复是两手：预处理缓存池扩到约204万个token，SGLang补丁让超长请求在入队时就被拦下，上游完整修复收进了10月19日发布的SGLang v0.5.22。如果你自己搭SGLang服务，顺手查一下版本是不是0.5.22以后。 ▌普通人自查3步 第一，别把密码、密钥、身份证号、没公开的财报原文直接贴进任何AI的长上下文，能脱敏先脱敏，能分段先分段。第二，超长任务拆成多段跑，别一次塞满上下文上限；如果返回内容里出现明显不属于你的段落，立刻停下、截图留存、向服务商反馈，别继续追问。第三，企业用户可以多问服务商一句：你们的KV缓存隔离和超长请求拒绝路径，测过输出内容本身吗？Cloudflare自己承认，当时的长上下文测试只验了HTTP状态码和性能，没验输出对不对，这正是漏掉的口子。 你平时往AI里贴过最长的一份东西，是什么？

曝光 18 · 评论 0 · 点赞 0 · 书签 0