昨天本来是一个平静的午后，夏天天气热的把树叶和知了烤卷了。
我正在为写什么文章而发愁，然后就在此时，我在群里看到有个人发了一条记录，是这么说的：
一句话给大家总结下：在 Claude Code Web 端登录，然后再执行一段油猴脚本代码，你就能获得一个 Claude Code Max 20x 的订阅资格。
然后。。。。。。就 TM 的炸了，直接全网狂欢了。
这个油猴脚本是这样的。
根据这个油猴脚本，可以在 web 端直接把 SEPA Debit 给搞出来。
这是最关键的。
然后你输入虚拟地址，用户名等信息，再用上面那个 Iban 的网址，能够随机生成一个字符串，填进去即可。
精彩的时刻来了，当你点击 Subscribe and Pay 的时候，你会发现你已经成为一个拥有 Max 20x 的用户了，恭喜你🎉。
而且还能爽夯 Fable 5 ！！
我看到身边已经有朋友夯了一下午，换算成 API 费用，相当于直接夯出 A 社几百 U token 出来。
但你以为你赚麻的是你？错了，赚麻了的永远是咸鱼卖金铲子的！！
此时此刻的你不是一个人在战斗，就算封了一个你，还有千千万万个你。
如果你不用的话，是这样的。
没有 SEPA Debit 的付款选项。
没用多久，等出现这个之后，就代表你的账户凉了。
天才程序员今天夯开心了，高低得奖励自己一个猪脚饭。
我自己在昨天晚上亲测了一下，油猴脚本已经无了。估计是 A 社的开始上班了，一上班发现炸鱼了。。。
但我说实话，这波 Claude Code 白嫖看起来是赚的，其实际上我认为还是亏麻了，因为我有个 gmail 老号，没有用科技，只是登录了一下，连带着咸鱼嫖的账号一起直接被封了。感觉电脑是被标记了。 如果后续再想要用 cc，感觉就没那么容易了。
而且 A 社已经发起了无差别攻击，他竟然没有封禁德区用户，而是
把所有新用户都禁了。。。。。。
说完事件的完整过程，再来聊一下技术方面的细节。
为什么一段油猴脚本，就能把 A 社的家给偷了？为什么一段油猴脚本，就能让世界顶级知名 LLM 公司 --- Anthropic 沦为全世界的笑柄？为什么一段油猴脚本，就能直接让 A 社损失上亿美元？
先说答案。
大概有两个方面的问题。
第一层：油猴脚本到底干了什么？
很多人看到这里，第一反应可能是：
这脚本是不是把 A 社服务器黑了？是不是伪造了一个支付成功响应？
都不是。它其实是让前端支付的时候走了另外一套结账流程。
Claude 网页在打开订阅页面的时候，会先请求后端：我这个账号应该走哪套 Checkout，也就是结账流程？
正常情况下，后端会返回一个 checkout_capabilities。前端拿到字段之后，再决定给你展示哪个支付页面、哪些付款方式。
而这段油猴脚本在页面刚开始加载时，就把浏览器原生的 fetch 和 XMLHttpRequest 接管了。
真实请求照样发给 A 社，也会有正常的响应。
只是响应走到浏览器里之后，被脚本半路截住，然后强行换成了这么一句：
{
"checkout_flow": "cassia"
}
为了伪造真实的效果，它甚至连 HTTP 状态码、响应头、responseText 和 response 都一起伪装成了 200 OK。
前端一看：哦，后端让我走 Cassia 方式。
于是原本没有出现的备用结账页面，就这么被硬生生的撬开了。
所以你也能看出来，这段脚本根本没有修改 A 社服务器里的任何东西。
服务器返回的还是真数据，数据库也没有被油猴脚本动过。
发生变化只发生在用户自己的 chrome 浏览器中。
这在前端安全里有个非常经典的原则：永远不要信任客户端（Never Trust the Client）原则。
浏览器属于不可信环境，任何影响权限、价格、支付和业务状态的判断，都必须由服务端重新验证。
按钮可以隐藏，接口可以抓包，JavaScript 可以改，页面里的变量也可以随便重写。
前端校验的作用，是让正常用户用起来更简单顺手，而不是负责安全。
如果后端真把前端的判断当成权限，那就相当于小区保安问你：
“你有门禁吗？”
你说：“有。”
然后他就把门打开了。
这类问题在安全领域一般会被归到 CWE-602：依赖客户端执行服务端安全控制。
注意，这里还有一个特别关键的地方。
如果只是前端显示出了 SEPA Debit，但后端在创建订单时重新检查一次账号资格，那这个根本称不上漏洞。
你页面爱怎么改怎么改，最后提交订单的时候，服务端只要自己重新计算一遍：
- 这个账号属于哪个地区？
- 这个套餐允许哪些支付方式？
- 这个用户有没有资格进入 Cassia？
只要有一个条件不满足，直接拒绝就完事了。
所以，如果前面看到的现象确实是由这条链路造成的，那么真正的第一处后端漏洞，很可能不是“SEPA 可以输入 IBAN”，而是：
备用 Checkout 被前端强行打开以后，后端居然还接受了它发来的订单。
换句话说，checkout_capabilities 本来应该只是一个 UI 配置，最后却疑似变成了授权凭证。
这才是第一道入口。
但只有这个入口，其实还不能把 20x 拿走，因为接下来还有支付层面。
第二层：随机 IBAN 为什么也能支付成功？
这里先纠正一个叫法。
IBAN 不是德国银行卡号，更准确地说，它是国际银行账户号码。SEPA Debit 也不是刷信用卡，而是商家拿着你给出的授权，也就是 Mandate，向银行发起账户扣款。
随机 IBAN 网站生成的字符串，通常只是满足了 IBAN 的结构和校验位规则。
以德国 IBAN 为例，里面会包含国家代码、校验位、银行识别部分和账户标识。系统可以通过 MOD 97 之类的校验，判断这个字符串长得像不像一个 IBAN。
但问题是，格式正确，和账户真实存在，完全是两码事。
这就像你写了一个符合身份证校验规则的号码。
它可以证明你数学做对了，但不能证明世界上真有这个人，更不能证明这个人就是你。
IBAN 校验同样证明不了三件事：账户是否真实存在、账户是不是你本人的、账户里面到底有没有钱。
而 SEPA Direct Debit 又偏偏不是一个同步支付流程。
商家提交扣款之后，支付系统可能先给出 created、submitted 或者 processing 这一类中间状态。真正的银行扣款、拒绝、退回，可能要在后面才发生。
德国央行和 European Payments Council 对 SEPA 的说明里，都把 Reject、Return、Refund 这类异常处理当成了正常流程的一部分。尤其是面向消费者的 SEPA Core Direct Debit，即使已经扣款，后面仍然存在退回和退款机制。
简单说就是：
用户点了支付按钮之后，不等于钱已经到了 A 社账上。
甚至支付平台告诉你请求创建成功，也不等于这笔钱最终一定能结算。
随机 IBAN 在整个事件里，就像是整个事件的导火索。
它本身不是漏洞。
真正的漏洞，系统只确认了输入格式正确，却在账户有效性和扣款结果尚未得到银行确认之前，就提前开放了 20x 权益。
真正出问题的是支付状态机
支付系统里最怕的是：业务系统把发起扣款，理解成了钱已经到账了。
如果把它翻译成最简单的状态，大概就是这样：
也就是说，支付还停留在 PROCESSING，订阅服务却已经把账号变成了 Max 20x 。。。
等银行在后面告诉支付平台这个账户不存在或者这笔扣款失败了的时候，用户可能早就把 Fable 5 夯得冒烟了。
如果失败 webhook 没有正确送达、处理太慢，或者订阅服务收到失败消息之后没有立即撤权，这个时间差就会变成一个完整的攻击窗口。
聊到这里，完整链路就比较清楚了。
- 油猴脚本通过修改浏览器，强迫前端进入 Cassia 备用结账流程。
- 后端疑似没有重新验证当前账号是否真的有资格使用这套流程，于是接受了 SEPA 订单。
- 随机 IBAN 通过了格式校验，支付平台创建了扣款请求，但资金并没有完成最终结算。
- 订阅系统疑似把中间支付状态当成成功状态，提前发放了 20x 权益。
- 真正的扣款失败消息来晚了，此时而用户已经开始夯麻了。
所以说，这不是一个单纯的前端漏洞，也不是一个单纯的随机 IBAN 漏洞。
而是客户端信任边界错误 × 备用支付流程缺少鉴权 × 异步支付状态机发权过早。
三次平 A 一起上，直接打出了一个暴击。
当然，这里必须强调一下：我们看不到 Anthropic 的后端源码和支付服务商日志。
上面这条链路，是根据公开的油猴脚本、页面行为和 SEPA 工作机制做出的技术推导，不等于已经确认了 A 社内部的具体实现。
仅凭这段脚本，最多只能百分之百确定一件事：它能欺骗前端选择 Cassia。
至于服务器当时为什么接受订单、在哪个支付状态发放权益、后续如何撤权，仍然要以 A 社内部订单记录和 webhook 日志为准。
