A Tampermonkey Script, a Fake IBAN, and a Payment State Machine Bug Unlocked Free Claude Max 20x

Yesterday started as a quiet afternoon, the summer heat curling the leaves and cicadas.

I was struggling with what to write about when I saw someone in a group chat post a record that said:

To summarize in one sentence: Log into the Claude Code Web side, then run a Tampermonkey script, and you get a Claude Code Max 20x subscription.

And then... it just fucking exploded. The whole internet went wild.

The Tampermonkey script looked like this.

With this Tampermonkey script, you could directly bring up SEPA Debit on the web side.

This was the most critical part.

Then you entered a virtual address, username, and other info, used the IBAN website above to randomly generate a string, and filled it in.

Here comes the exciting part: when you clicked Subscribe and Pay, you'd find yourself already a Max 20x user. Congratulations 🎉.

And you could even go crazy with Fable 5!!

I saw friends around me who had been going at it all afternoon. Converted to API costs, that's equivalent to directly burning through several hundred dollars' worth of Anthropic tokens.

But you think you're the one who made bank? Wrong. The ones who always make bank are the guys selling shovels on Xianyu!!

At this moment, you are not fighting alone. Even if one of you gets banned, there are thousands more of you.

If you didn't use it, it looked like this.

No SEPA Debit payment option.

Not long after, when this appeared, it meant your account was dead.

The genius programmers had a blast today, they definitely deserved to treat themselves to a pig trotter rice.

I personally tested it last night, and the Tampermonkey script was already gone. I guess Anthropic's people started work and found the fishing frenzy...

But honestly, this wave of freeloading Claude Code seemed like a win, but I actually think it was still a huge loss, because I had an old Gmail account. Without using any VPN, just by logging in, it got banned along with the account I freeloaded from Xianyu. I feel like my computer got flagged. If I want to use CC again later, it probably won't be that easy.

And Anthropic has launched an indiscriminate attack. They didn't just ban German region users, but

banned all new users......

After finishing the complete event process, let's talk about the technical details.

Why could a single Tampermonkey script steal Anthropic's house? Why could a single Tampermonkey script turn the world's top-tier LLM company --- Anthropic --- into a global laughingstock? Why could a single Tampermonkey script directly cause Anthropic to lose hundreds of millions of dollars?

Let's start with the answer.

There are roughly two aspects to the problem.

Layer 1: What exactly did the Tampermonkey script do?

Many people's first reaction upon seeing this might be:

Did this script hack Anthropic's servers? Did it forge a payment success response?

Neither. It actually made the frontend payment go through a different checkout process.

When the Claude webpage opens the subscription page, it first requests the backend: which Checkout, i.e., payment process, should this account use?

Normally, the backend returns a checkout_capabilities. After the frontend gets this field, it decides which payment page and which payment methods to show you.

And this Tampermonkey script, right when the page started loading, took over the browser's native fetch and XMLHttpRequest.

The real request was still sent to Anthropic, and there was a normal response.

It's just that when the response reached the browser, it was intercepted halfway by the script and forcibly replaced with this line:

{
  "checkout_flow": "cassia"
}

To fake a realistic effect, it even disguised the HTTP status code, response headers, responseText, and response all as 200 OK.

The frontend saw this and thought: oh, the backend told me to use the Cassia method.

So the originally non-existent backup checkout page was pried open just like that.

So you can see, this script didn't modify anything on Anthropic's servers at all.

The server still returned real data, and the database wasn't touched by the Tampermonkey script.

The changes only happened within the user's own Chrome browser.

There's a very classic principle in frontend security here: Never Trust the Client principle.

The browser is an untrusted environment. Any judgment affecting permissions, prices, payments, and business state must be re-verified by the server side.

Buttons can be hidden, APIs can be packet-sniffed, JavaScript can be modified, and variables on the page can be rewritten at will.

The purpose of frontend validation is to make things smoother and easier for normal users, not to be responsible for security.

If the backend truly treats the frontend's judgment as authorization, it's like a neighborhood security guard asking you:

"Do you have an access card?"

You say: "Yes."

And then he opens the gate.

This type of problem is generally classified in the security field as CWE-602: Reliance on Client-Side Enforcement of Server-Side Security.

Note, there's another particularly critical point here.

If the frontend only displayed SEPA Debit, but the backend re-checked the account eligibility when creating the order, then this wouldn't even qualify as a vulnerability.

You can modify the page however you want. When you finally submit the order, the server just needs to recalculate on its own:

• Which region does this account belong to?
• Which payment methods does this plan allow?
• Does this user have the qualification to enter Cassia?

As long as one condition is not met, just reject it outright.

So, if the phenomena observed earlier were indeed caused by this chain, then the real first backend vulnerability is likely not "SEPA allows IBAN input," but rather:

After the backup Checkout was forcibly opened by the frontend, the backend actually still accepted the orders it sent.

In other words, checkout_capabilities, which should have only been a UI configuration, ended up seemingly becoming an authorization credential.

That was the first entry point.

But having just this entry point still couldn't take the 20x away, because the payment layer came next.

Layer 2: Why could a random IBAN also succeed in payment?

First, let's correct a term.

IBAN is not a German bank card number. More accurately, it's an International Bank Account Number. SEPA Debit is also not swiping a credit card; it's the merchant using the authorization you gave, i.e., the Mandate, to initiate an account debit with the bank.

The string generated by a random IBAN website usually only satisfies the IBAN structure and check digit rules.

Taking a German IBAN as an example, it contains the country code, check digits, bank identifier, and account identifier. The system can use checks like MOD 97 to determine if this string looks like an IBAN.

But the problem is, correct format and a real existing account are two completely different things.

It's like writing a number that conforms to ID card validation rules.

It can prove you did the math right, but it cannot prove that such a person really exists in the world, let alone that this person is you.

IBAN validation similarly cannot prove three things: whether the account actually exists, whether the account belongs to you, and whether there is actually money in the account.

And SEPA Direct Debit happens to not be a synchronous payment process.

After the merchant submits the debit, the payment system might first give intermediate statuses like created, submitted, or processing. The actual bank debit, rejection, or return might happen later.

The German Bundesbank and the European Payments Council, in their explanations of SEPA, both treat exception handling like Reject, Return, and Refund as part of the normal process. Especially for consumer-facing SEPA Core Direct Debit, even after a debit has occurred, there are still return and refund mechanisms afterward.

Simply put:

After the user clicks the pay button, it does not mean the money has already reached Anthropic's account.

Even if the payment platform tells you the request was created successfully, it does not mean this money will ultimately be settled.

The random IBAN in this whole event was like the fuse for the entire incident.

It itself was not the vulnerability.

The real vulnerability was that the system only confirmed the input format was correct, but prematurely granted 20x benefits before the account validity and debit result were confirmed by the bank.

The real problem was the payment state machine

The most feared thing in a payment system is: the business system interprets initiating a debit as the money having already arrived.

If we translate it into the simplest state, it probably looks like this:

That is to say, the payment was still stuck at PROCESSING, but the subscription service had already turned the account into Max 20x...

Later, when the bank told the payment platform that this account didn't exist or this debit had failed, the user might have already been hammering Fable 5 until smoke was coming out.

If the failure webhook wasn't correctly delivered, was processed too slowly, or the subscription service didn't immediately revoke privileges after receiving the failure message, this time gap would become a complete attack window.

Having discussed this far, the complete chain is relatively clear.

1. The Tampermonkey script, by modifying the browser, forced the frontend into the Cassia backup checkout process.
2. The backend seemingly did not re-verify whether the current account was actually eligible to use this process, thus accepting the SEPA order.
3. The random IBAN passed format validation, the payment platform created a debit request, but the funds did not complete final settlement.
4. The subscription system seemingly treated the intermediate payment status as a success status, prematurely granting 20x benefits.
5. The actual debit failure message arrived late, by which time the user was already going wild.

So, this is not a simple frontend vulnerability, nor a simple random IBAN vulnerability.

It is a client-side trust boundary error × backup payment flow lacking authorization × asynchronous payment state machine granting privileges too early.

Three normal attacks combined to land a critical hit.

Of course, it must be emphasized here: we cannot see Anthropic's backend source code or payment service provider logs.

The chain above is a technical deduction based on the public Tampermonkey script, page behavior, and SEPA working mechanism. It is not equivalent to having confirmed Anthropic's specific internal implementation.

Based solely on this script, at most, one thing can be 100% confirmed: it can deceive the frontend into choosing Cassia.

As for why the server accepted the order at that time, at which payment status the benefits were granted, and how they were later revoked, that still depends on Anthropic's internal order records and webhook logs.

---

References

• Anthropic: Max plan offers 5x and 20x tiers
• Deutsche Bundesbank: SEPA Direct Debit mechanism and return rules
• European Payments Council: SEPA Direct Debit and Mandate mechanism