A Fly That Didn’t Know Where to Land

That afternoon was ordinary in its heat. The edges of the leaves outside curled from the sun, and the cicadas' drone merged with the hum of the air conditioner compressor until you couldn't tell which was which. I stared at a blank document on my screen, the cursor blinking like a fly that didn't know where to land.

Then my phone lit up.

A message popped up in the group chat. Two lines. The first was a link to a Tampermonkey script. The second said: "Claude Max 20x, instant approval, hurry."

I stared at those words for five seconds. The group stayed quiet for maybe thirty more. Then it burst like a water balloon that had been poked from underneath.

Screenshots came in one after another. Someone posted a full-screen capture of the subscription success page: the Max 20x badge sat in the upper right corner, the same color scheme as a legitimate subscription. Someone else posted their API call logs, lines scrolling down like a ledger, each entry a request to Claude 3.5 Sonnet. Requests that had been worth a few dozen cents minutes earlier were now trophies from a "zero‑dollar heist."

"The window won't last long," someone said.

"I've been hammering it for three hours. In API terms, that's almost three hundred dollars," said another.

I scrolled further and found a detail that made me laugh and wince at once: people were already selling tutorials on Xianyu (China's second‑hand marketplace), priced anywhere from nine to thirty‑nine yuan, titles all plastered with "Zero‑dollar grab," "Rush now," "Last chance." The sellers didn't touch the exploit themselves. They sold shovels to the gold rushers.

The entire Chinese tech community was on fire within hours. Across the Pacific, at Anthropic (the company founded by former OpenAI members, with "We are committed to building responsible AI" on its homepage) their engineers were probably still asleep.

Later I read the script myself. It was maybe a few dozen lines. Not a hacker tool, not an injection attack, nothing with complicated crypto bypasses. What it did was so simple it felt absurd:

It changed one field from the backend response while the browser was loading the subscription page.

Here's how it worked. Every time Claude's page opened the subscription panel, it sent a request back to the server asking: "Which checkout flow should this account use?" The server returned a configuration object called checkout_capabilities, which told the page which payment methods to show—credit cards for US users, SEPA for Europe, maybe nothing for others.

The Tampermonkey script intercepted that configuration after it arrived at the browser but before the page rendered. It grabbed the response, forced the checkout_flow field from its normal value to "cassia".

What was Cassia? A backup checkout flow inside Anthropic, probably built for internal testing, perhaps one that didn't even require real money, just a formality to activate a subscription. Normal users would never see it, because the backend wouldn't send it to them. But the script bypassed that "can't see it" restriction without touching the server. It only touched your own browser.

The browser knew nothing. It saw the server "telling" it to run the Cassia flow, so it obediently rendered the corresponding page and placed the SEPA direct debit form in front of the user.

That was the first layer.

If you stopped here, you'd think: isn't that just a front‑end change? The backend isn't stupid. It can re‑check when the user submits the order, right?

Right. A proper system would do exactly that.

But Anthropic's server didn't block it this time.

When the user filled in the fake German IBAN (generated from an online tool that spits out structurally valid but totally fictitious account numbers) and clicked "Subscribe and Pay," the backend accepted the order. It didn't re‑validate whether this account was actually eligible for Cassia. It didn't ask whether the user's region truly supported SEPA. It took the request as legitimate.

Imagine a building's security system: the guard asks the visitor, "Do you have a key card?" The visitor says "Yes," and the guard opens the door. The guard doesn't check if the card is real. Doesn't look at the photo to see if it matches the person in front of him. Whatever the visitor says, the guard believes.

In information security, this has a number: CWE‑602. Full name: "Client‑Side Enforcement of Server‑Side Security Controls." In plain words: you handed the decision (the "may I?") to the person who was asking permission.

That was the second layer.

Then came payment itself.

SEPA direct debit has a peculiarity: it's not real‑time. You fill in the IBAN, click confirm, and the merchant submits a debit request to the banking system. The bank returns an intermediate status ("request created") and the actual funds transfer, success or failure, doesn't come back until a day or two later.

In other words, the moment you hit the payment button, the money hasn't moved. Your bank doesn't know anything yet. The only thing that happened was Anthropic's payment gateway (most likely Stripe) registering a "pending debit" record.

And Anthropic's system gave the green light right there.

It saw the gateway return a "request created" status, treated that as money received, and activated the Max 20x subscription. Users started calling models, line after line of code, document after document—API requests pouring out like a tap left open.

When the bank finally returned "account does not exist" a day later, those hundreds of dollars of API usage had already been burned.

It's like eating at a restaurant, handing your credit card to the waiter, and the kitchen starts cooking your next course before the POS machine prints the receipt. If that card turns out to be fake, by the time the waiter finds out, you've already had three mains and two desserts.

The "debit‑first‑settlement‑later" mechanism of SEPA wasn't the problem. The problem was Anthropic treating "initiated" as "completed."

That was the third layer.

Three things stacked together:

Client‑side configuration tampered → Backend skipped re‑validation → Asynchronous payment state mistaken for success.

Any one of these mistakes alone wouldn't have caused such damage. If the page got changed, the backend would block it on submission. If payment was async, waiting for the final bank response would have prevented the premature access. But none of the three was done.

This wasn't an intrusion. It was a betrayal of trust.

Anthropic's response wasn't slow. A few hours after the exploit went viral, their engineers started their workday. The Tampermonkey script stopped working. The Cassia entry was shut down. The payment flow was patched. At the same time, a massive wave of account bans began.

But then things turned absurd.

Banning the abusers made sense. But a large number of users who had done nothing—especially in Germany—got banned too. Legitimate users who had signed up normally, used the service normally, and even paid for Claude Max subscriptions found themselves locked out. Their subscriptions were cancelled, their accounts flagged as "risky."

Worse: someone posted that an old account they'd used for years (never a single anomaly, never any script) got banned just because it had logged in from the same computer as a "freebie" account.

Anthropic had deployed device fingerprinting. If one account on a machine was flagged for abuse, every account on that same device got caught in the net. The logic: better to kill a thousand innocents than let one abuser escape. In the urgency of stopping the bleeding, the collateral damage became acceptable.

Those German users who'd paid real money and been banned for nothing became the most aggrieved victims of the whole affair. They never even had a chance to "freeload," yet they bore the same consequences as those who did.

Let's tally the ledger.

Did regular users win? No. Their accounts got flagged, their devices fingerprinted. Even if they want to legitimately use Claude products in the future, they'll face higher risk thresholds. Trading a couple hours of free use for the long‑term credit of your account—worth it? No.

Did the tutorial sellers on Xianyu win? Yes. They took zero risk, never touched the exploit themselves. They just listed their guides at peak hype, sold dozens or hundreds of copies at thirty‑nine yuan each, netted a few thousand. They sold shovels. Whether the gold rushers struck gold or got nothing, the shovel sellers never lost.

Did Anthropic lose? Yes. Direct loss: the API calls burned during those hours (marginal cost per call isn't high, but sustained mass usage over hours adds up to hundreds of thousands of dollars). Indirect loss: engineer overtime to patch, customer service hours handling false‑ban appeals, brand damage, and the paid users who might never come back.

Some estimates put the total cost in the low tens of millions. For a company still burning cash to train large models, that's not pocket change.

This brings me to a more fundamental question: why did such a simple vulnerability exist in a production environment at a top‑tier AI company?

The answer probably isn't complicated.

Most modern payment systems are asynchronous. Credit cards are async, SEPA is async, crypto is async. But many system designers, deep in their subconscious, still treat payment as synchronous: user hits pay, money arrives. This "optimistic assumption" is especially common in fast‑iterating startups. To reduce wait times, to improve user experience, engineers grant access while the payment is still "processing."

Most of the time this doesn't break, because most users' payments eventually succeed. But when a single wave of mass exploitation hits, that optimism turns into a disaster.

Anthropic's second mistake (exposing the internal Cassia testing flow to ordinary users in production) also reveals another issue: insufficient isolation between internal test hooks and live environments. Cassia was clearly a backdoor left for engineers' convenience. Such doors are common in large systems. The problem is, they should never appear anywhere an ordinary user can touch.

What a Tampermonkey script can do is actually very limited. What made things spiral was social media. Once "zero‑dollar heist," "free milk," and "window period" got plastered over the exploit—once a technical flaw was translated into a "free lunch" anyone could understand—the participants expanded from a few tech‑savvy insiders to a flood of ordinary users. That spread was far faster than Anthropic's ability to respond.

I'm writing this on the evening of July 28. Outside, it's still hot, the cicadas still calling, no different from two days ago.

The Tampermonkey script is dead. Cassia is either removed or now guarded by server‑side validation. The banned users queue in appeal channels, waiting for replies that may never come. Those who made a quick buck from tutorials have probably moved on to the next "window."

But what this incident leaves behind won't vanish.

It reminds every system designer: never trust anything the client sends about permissions, prices, or eligibility. The front end can do interactions, caching, UI—but anything that asks "may I?" must be re‑evaluated on the server.

It reminds every payment product manager: the payment state machine must rigorously distinguish "initiated," "processing," "success," and "failure." Until "success" is confirmed, access stays locked. Better to make users wait two more seconds than to let them start using the service before the money settles.

It also reminds every developer: internal test entries, debug endpoints, fallback flows—they must be strictly walled off from production. A single unassuming test path, once exposed, becomes the city gate left unbarred.

That afternoon, I never did write the article I'd planned. I spent the whole afternoon in the group, watching screenshots, reading tutorials, tracking the "instant approval" cheers and the "I'm banned" laments. By dusk, the blank document on my screen was still blank, the cursor blinking on like a fly still uncertain where to land.

Later I thought that maybe the article I didn't write that day was hiding inside the whole thing all along.

How fast a system built on trust collapses when that trust is abused. That, perhaps, is the only thing worth remembering in this story.

Anthropic paid a price in the tens of millions for this lesson. For everyone else still designing payment systems, that lesson is still free.