The Bug That Made Anthropic Close the Door on New Claude Signups

AI

The Bug That Made Anthropic Close the Door on New Claude Signups

I spent most of Sunday, July 26, watching the same screenshot land in three different forum threads inside ten minutes: a Claude subscription page with an IBAN field sitting where the credit card form was supposed to be.

Under it, a Max 20x plan marked active. Amount charged: nothing.

By Monday, the story had mutated into the version you’ve probably seen. Anthropic lost a fortune, Anthropic banned every new account, Anthropic shut off signups. Some of that is true. Most of it is the internet doing what the internet does with a screenshot.

So here’s what the evidence actually supports, and where the interesting engineering failure was. Not where most people are pointing.

Sunday, 07:45 UTC

The first thread I can timestamp went up on the Chinese dev forum linux.do at 07:45 UTC on July 26. The poster isn’t explaining a vulnerability. They’re complaining that the trick didn’t work until they switched exit nodes.

Two hours later, @audit_911 posted on X:

That post has 333,000 views and quotes another post that’s now unavailable, which tells you roughly how long the original stayed up.

By 12:14 UTC, someone was publishing lists of German IBANs for people who couldn’t generate their own. Ten minutes into that thread, replies start reporting the same account numbers no longer work.

So the whole usable window was something like a single working day. That detail matters later.

One field, one word

The tool circulating was a Tampermonkey userscript, under 200 lines. The most detailed teardown I found is this Chinese write-up published the same Sunday, and its account matches what the community threads describe.

Worth being precise about what it didn’t do. Nothing on Anthropic’s side was compromised, and no payment confirmation was forged. The script used the user’s own logged-in session and sent real requests. What it rewrote was a single response, after that response had already reached the browser. And the response it rewrote had nothing to do with payment. It was about eligibility.

When you open the upgrade page, the Claude frontend first asks the backend which checkout it should render:

GET /api/organizations/{org_id}/subscription/checkout_capabilities

The response carries a flow identifier. Normally stripe, which renders the card form: number, expiry, CVV, 3DS.

The script hooked fetch and XMLHttpRequest at document-start, let the real request go out, and rewrote the response body on its way back into the page:

{ "checkout_flow": "cassia" }

cassia is the identifier for the European SEPA Direct Debit flow. The renderer saw a different flow, so it drew a different form: name, address, IBAN.

Note the ordering, because it’s the one clever thing here. The script doesn’t block the request and fabricate a reply. It lets the real call reach the server, gets a real 200 back, and swaps the bytes inside the browser.

From the server’s logs, nothing happened. A normal GET, a normal response, normal timing. The tampering lives on the far side of the TLS termination, where Anthropic has no visibility at all.

That’s the whole client-side half of the story: a UI configuration field treated as an authorization decision.

Why a made-up German account number clears

This is where most people’s intuition breaks, and the payments part is worth slowing down on.

An IBAN is not a card number. It carries check digits computed with ISO 7064 MOD 97–10, and a generator can produce syntactically perfect ones all day. The algorithm proves you did the arithmetic correctly. It proves nothing about whether the account exists, whether it has money, or whether it belongs to you.

Card payments hide that distinction from you because authorization is synchronous. You press pay, the issuer answers in milliseconds, and a wrong number is wrong right now.

SEPA Direct Debit works nothing like that. The merchant isn’t receiving a transfer; the merchant is presenting a mandate and pulling funds from your account through interbank clearing. Nobody asks your bank anything at submission time.

Stripe documents this in plain language on its SEPA Direct Debit page:

SEPA Direct Debit is a reusable, delayed notification payment method.

And, less ambiguously:

Wait at least 6 business days before considering a SEPA Direct Debit payment as successful.

Six business days. Stripe’s own settlement table puts payment success at T+6. The refusal window, where the customer’s bank can bounce the debit back with an R-code, is five business days on its own.

Stripe also spells out what it collects up front:

To debit an account, businesses must collect their customer’s name and bank account number in IBAN format.

A name and an IBAN. That’s the entire input, and neither one gets checked against a real account when you submit it.

On top of that, SEPA Core gives consumers an eight-week no-questions-asked reversal right, stretching to thirteen months if the debit was unauthorized. Even a real account isn’t settled money for two months.

Germany was the country of choice for boring reasons. A German IBAN is a fixed 22 characters with no extra national check key layered on top, unlike France’s 27 with its RIB key. Fewer moving parts, higher hit rate.

Where the actual bug lives

Put the two halves together and notice neither one is fatal alone.

A tampered UI flag is harmless if the server recomputes eligibility when the order arrives. You can rewrite JSON in your browser all day; the backend knows your region, your plan, and whether you’re allowed near the SEPA path.

An unverified IBAN is harmless if entitlement waits for settlement. Stripe tells you in the docs to wait six business days. Wait, and the worst outcome is a pending subscription that quietly fails.

The exploit needed both to be true at once, plus a third thing that’s the real defect:

The subscription got provisioned on payment initiation rather than payment settlement.

That’s the sentence I’d put in the incident review. Everything else is decoration.

A payment system has states, and PROCESSING isn't SUCCEEDED. Direct debit is the case where those two sit days apart instead of milliseconds, and where the gap is documented and expected. If your entitlement service reads "the gateway accepted the request" as "the money arrived," direct debit is the rail that will find out.

Which is also why the ban wave looked the way it did. Anthropic never had to wait for R-codes to come back from German banks. Same-day it could see accounts converting to Max 20x through a payment path they had no business being on, from IPs nowhere near the SEPA zone, in a burst. That’s a pattern query, not a fraud investigation.

The forum threads show accounts dying within an hour of activation. The clearing system had not even started.

About that signup shutdown

Now the part of the story I can’t support, which I think is the more useful thing to write down.

The claim spreading everywhere is that Anthropic responded by banning all new users and closing registration. The evidence for it is screenshots of this message:

Anthropic has paused sign ups to provide the best possible service to customers.

Three problems with reading that as a July 26 emergency shutdown.

That string isn’t new. It dates back to capacity throttling in 2025 and has been surfacing on and off ever since, which makes it useless as a timestamp for anything.

It’s also risk-gated per user rather than global. It fires on disposable email domains, flagged IP ranges, and datacenter exits. Two people hitting signup from different networks in the same minute get different outcomes, which isn’t how a shutdown behaves.

And the tightening predates the incident by weeks. A Chinese roundup published July 13, thirteen days before any of this, already describes fresh Claude accounts getting killed within hours of creation, driven by IP geolocation, browser fingerprinting, and payment-channel checks.

What I can confirm is narrower: a community thread dated July 26 reports new users unable to register that day. Anthropic’s status page carries no incident about signups, and Anthropic has said nothing publicly. I checked the signup flow myself on July 28 and it was normal.

The honest version is that Anthropic runs an aggressive signup risk gate; that gate was already tight before July 26, and it plausibly got turned up further while the payment path was bleeding. Reading a per-user throttle screen as a company-wide shutdown is how a real engineering failure gets buried under a fake one.

For scale, Anthropic’s own transparency reporting puts account bans at 1.45 million for the second half of 2025. Mass banning isn’t an emergency measure there. It’s Tuesday.

Someone is going to run this again

Strip out the Claude specifics, and you get a shape worth memorizing, because this is a category, not a one-off.

Find an API response that decides something about money: available payment methods, eligible plans, promotional pricing, feature entitlements. Confirm the client can alter it and the server won’t recompute. Then pick the payment rail with the longest confirmation delay you can reach.

Direct debit beats bank transfer beats wallets beats cards, ranked by how long the truth takes to arrive. The exploit window is the confirmation delay.

I don’t think this is a story about one team being sloppy, and I’d be careful about reading it that way. It’s a story about two reasonable-looking decisions in different systems that were never wrong until they met.

If you ship subscription billing, here’s what I’d take from it.

The checkout flow has to be computed server-side, every time, at order creation. Whatever the client came back with is a rendering hint. The moment your backend treats it as a capability grant, your authorization boundary sits inside someone else’s browser.

On any asynchronous rail, entitlement waits for settlement. Give the user a “payment processing” state and mean it. Stripe wrote the number down for you: six business days.

And if you’re going to take IBANs from strangers, check them against something real. MOD 97–10 is arithmetic, not identity.

The script is dead. Anthropic patched the path inside a day, which is fast by any standard. But the pattern behind it will keep working on somebody, and the tell never changes: a payment method your system marks successful before the money exists.