昨天全网白嫖 Claude Max 20x 炸锅了！A社这个漏洞是咋回事？

昨天全网白嫖 Claude Max 20x 炸锅了！A社这个漏洞是咋回事？

大家好，我是星哥。昨天下午，台风过境，星哥正对着电脑发愁今天写点啥，结果技术群里突然甩出一张截图，直接让整个圈子炸锅了。

一句话总结就是：在 Claude Code Web 端，跑个油猴脚本，就能白嫖 Claude Max 20x 的订阅资格。

好家伙，这谁顶得住？直接全网狂欢，A社（Anthropic）的家差点被偷没了。

今天星哥就来给大家复盘一下，这波“白嫖狂欢”到底是怎么玩的，以及从技术角度扒一扒，A社这波到底输在哪。

不提供技术支持，因为星哥也没有白嫖到，错误几个亿，捶胸顿足中。。。

赚麻了！

先说说这帮“天才程序员”是怎么操作的。

其实原理不复杂。群里流传的那个油猴脚本，核心作用就是在 Web 端强行把 SEPA Debit（欧洲直接借记） 这个支付方式给调出来。

具体怎么弄呢？

1. 1. 跑脚本，调出 SEPA Debit 选项。

2. 2. 随便填个虚拟地址和用户名。

3. 3. 找个生成 IBAN（国际银行账户号码）的网站，随机生成一串字符串填进去。

4. 4. 点击“Subscribe and Pay”。

奇迹发生了，你直接变成了尊贵的 Max 20x 用户！不仅能用，还能狂夯 Fable 5 模型。
有朋友算了一笔账，这一下午夯出来的 Token，换算成 API 费用，得好几百U了。

但你以为你赚麻了？错，赚麻的永远是闲鱼上卖“金铲子”的。

此时此刻，无数人前赴后继。但羊毛出在羊身上，A社的反击来得比想象中快。

没用多久，当你看到账户出现异常提示时，就代表你的号凉了。

星哥昨晚也去亲测了一把，结果油猴脚本直接失效。估计是 A 社的工程师上班一看后台，好家伙，炸鱼了，赶紧热修复。

更惨的是，A社直接开启了无差别攻击。
不仅封了薅羊毛的号，连德区正常用户都没放过，甚至把很多新用户也一刀切禁了。

星哥自己有个用了很久的 Gmail 老号，没开科技，就登了一下，结果连带着一起被封。
感觉电脑设备直接被拉黑了。后续想再正经用 Claude，估计得费一番功夫。

所以，听星哥一句劝：白嫖一时爽，封号火葬场。

网友截图：

星哥实际测试的，并没有SEPA的支付

可能是我的节点不在德国

技术拆解：A社的漏洞是怎么来的？

吃瓜吃完，咱们来点硬核的。

很多人好奇：一段几十行的油猴脚本，怎么就能把世界顶级 LLM 公司的支付系统给干了？是黑进服务器了吗？

当然不是。这其实是一个经典的组合漏洞链。

星哥给大家拆成三层来看。

第一层：前端“掩耳盗铃”，后端“盲目信任”

油猴脚本干了啥？它其实没改 A 社服务器上的任何东西，它只改了你自己浏览器里的东西。

正常情况下，你打开订阅页面，前端会问后端：“这哥们该走哪套结账流程？”

后端返回一个 checkout_capabilities，前端根据这个字段展示支付方式。

但油猴脚本在页面加载时，直接劫持了浏览器的 fetch 和 XMLHttpRequest。

它把后端返回的真实数据半路截胡，强行替换成了：

                                                                 {
  "checkout_flow": "cassia"
}

甚至连 HTTP 状态码都伪装成了 200 OK。

前端一看：“哦，后端让我走 Cassia 备用结账流程。”
于是，原本没有的 SEPA Debit 选项，就这么被硬生生撬开了。

这里犯了安全大忌：永远不要信任客户端（Never Trust the Client）。

前端校验只是为了让正常用户体验更好，绝不能用来做安全拦截。按钮可以隐藏，但接口必须服务端重新校验。

如果 A 社后端在创建订单时，重新检查一遍账号资格，这漏洞根本成不了。

但显然，后端把前端传来的 checkout_capabilities 当成了“授权凭证”，直接放行了。

第二层：随机 IBAN 为什么能过？

调出 SEPA Debit 后，随便填个随机 IBAN 居然能支付成功，这又是怎么回事？

先科普下，IBAN 只是国际银行账户号码，SEPA Debit 是商家拿着你的授权去银行扣款。

随机生成的 IBAN，只是格式正确（通过了 MOD 97 校验），但账户根本不存在。

这就像你写了一个符合规则的假身份证号，数学上没毛病，但查无此人。

那为什么系统没拦截？

因为 SEPA Direct Debit 是个异步支付流程。

商家提交扣款后，支付系统只会先返回一个 created 或 processing 的中间状态。真正的扣款成功或失败，要等银行后续回调。

系统只确认了“IBAN 格式正确”，就放行了。

第三层：致命的“支付状态机”

这是最核心的一环。

支付系统里最怕什么？最怕业务系统把“发起扣款”等同于“钱已到账”。

正确的状态机应该是：
发起扣款 (PROCESSING) -> 等待银行回调 -> 扣款成功 (SUCCESS) -> 发放权益。

但 A 社的订阅系统疑似把状态机搞错了：
只要支付平台返回了 PROCESSING，订阅服务就直接把账号升级成了 Max 20x！

等银行在后面慢悠悠地回调说“这账户不存在，扣款失败”时，用户早就把 API 额度夯冒烟了。
如果失败回调没处理好，或者撤权有延迟，这个时间差就成了完美的攻击窗口。

总结

复盘下来，这根本不是什么神仙黑客技术，而是三个低级错误的叠加：

1. 1. 客户端信任边界错误 （油猴脚本欺骗前端）。

2. 2. 备用支付流程缺少鉴权 （后端没校验资格就接单）。

3. 3. 异步支付状态机发权过早 （没等钱到账就发权益）。

三次平 A，直接打出了暴击。

当然，星哥得客观说一句，咱们看不到 A 社的后端源码，以上是基于公开脚本和支付机制的技术推导。但底层逻辑绝对跑不出这个框架。

这件事给咱们普通用户提了个醒：天下没有免费的午餐，白嫖的代价往往是你的核心资产（账号/设备）。

给开发者也提了个醒：永远不要信任客户端，支付状态机必须严谨，不见兔子不撒鹰！

好了，今天的复盘就到这里。

如果觉得文章对你有帮助，别忘了点个 “赞” 和 “在看”。

你昨天薅到 Claude 的羊毛了吗？评论区聊聊你的“战况”！