Anthropic SEPA漏洞遭Chrome插件薅羊毛，千万损失成P0事故
近期一起针对AI服务商的大规模薅羊毛事件引发行业广泛讨论，这场事故被业内称为P0级生产漏洞，不少用户调侃相关团队醒来后会发现业务遭受重创，后续大概率会启动大规模账号封禁，提醒相关使用者提前做好应对准备。
据统计，此次事件造成的直接经济损失可能达到上千万美元。社区和社交群组中广泛流传的免费订阅教程被封装成油猴脚本和Chrome插件，甚至附带了随机生成德国银行卡号的工具，用户可以一键完成薅羊毛流程。该教程在多个社区平台的浏览量累计超过百万，不少用户通过注册多个小号进行批量订阅，进一步放大了此次事件的影响。
不少业内人士对此表示：此次漏洞的设计之粗糙令人意外，甚至戏称连AI都很难写出这种低级的P0级漏洞，开发者只要稍有安全意识都不该出现这种问题，甚至有猜测称系统连基本的预警机制都没有。
事件核心背景
这次被广泛传播的“德国银行卡免费订阅Claude Code”事件，本质上并非银行卡信息泄露，而是SEPA直接扣款的结算延迟与权益提前发放叠加产生的致命时间窗口漏洞。
SEPA（欧元区直接扣款）与信用卡的核心差异在于：信用卡是“授权即确认扣款”，而SEPA则是“先发起扣款请求，后续由银行完成结算”。根据支付服务商的公开文档，SEPA扣款通常需要1到5天的清算周期，在这段时间内，支付状态会长期处于“处理中”，并且最终仍有可能失败。而问题的关键就出在这里：系统在尚未确认款项到账的情况下，就直接发放了高价值的订阅权益。
攻击的核心逻辑
这场薅羊毛攻击并不需要真实的资金投入，也无需控制真实的银行账户，只需要满足两个核心条件即可：
- 能提交格式合法的IBAN（仅通过校验位验证即可）
- 让支付系统进入“处理中”的状态
在SEPA的规则下，系统仅会验证IBAN的结构（国家代码+校验位），既不会核实账户是否真实存在，也不会确认账户是否属于提交请求的用户，因此攻击者可以轻松构造出看似合法的支付请求。
致命的时间窗口漏洞
整个攻击的核心依赖于一个极短但致命的时间窗口：漏洞窗口 = 权益已发放时间 - 支付最终确认失败时间
这个窗口由两个相互独立的系统共同决定：
- 银行结算链（慢）
- SEPA清算：1–5天
- 最终结果：成功 / 拒付 / 退单
- 风控系统（快）
- 异常检测：分钟级
- 行为分析：小时级
- 账号冻结：实时触发
因此实际可用的攻击窗口，取决于银行结算和风控封禁哪一个先触发——要么是银行结算完成前风控还没来得及封禁账号，要么是风控封禁前已经拿到了权益。
银行未结算（天级）
vs
风控已封禁（小时级甚至分钟级）
攻击者真正能用的时间，取决于哪一个先触发
涉事插件的技术细节
技术人员拆解了流传的Chrome插件，这款工具并非简单修改页面显示隐藏的SEPA按钮，而是在已登录的Claude页面中自行构建SEPA支付表单，直接调用官方结账接口强制指定paymentMethodTypes为["sepa_debit"]，再通过后端返回的Stripe会话完成支付流程。从插件的权限申请来看，它仅请求了页面脚本注入和本地存储权限，扩展说明也明确标注了“创建SEPA Direct Debit表单”。这说明尽管正常界面没有开放SEPA支付渠道，但服务端至少在之前接受了客户端指定该支付方式，暴露出后端业务规则校验存在明显漏洞。不过仅凭这款插件，只能确认可以创建SEPA结账会话，还无法直接证明系统将“处理中”的状态误判为扣款成功并立即发放订阅权益，这一点还需要结合实际支付状态和权益发放响应进一步验证。
后续影响与提醒
对于此次薅羊毛的行为，我们暂不做评价。但可以预见的是，这类大规模攻击会让服务商进一步收紧风控规则，后续的订阅流程难度会大幅提升。结合此前Claude Code源代码泄露的信息来看，该服务商已经具备记录用户运行环境的能力，不排除会记录设备相关信息，如果设备触发风控规则，甚至可能牵连原本正常使用的账号，出现多账号连续被封的情况。截至本文撰写时，已经有部分用户反馈自己的订阅账号被封禁，新账号的注册和订阅也出现了障碍。
