Cloudflare Turnstile's 'Bypass' Costs $1.45 Per Thousand

A developer published a writeup claiming a critical bypass in Cloudflare Turnstile: copy the token Turnstile leaves in your browser, paste it into a different browser, and the challenge is gone. They tested it against Cloudflare's own demo page. Cloudflare's triage team, by the researcher's account, confirmed it reproduced, then closed the report as out of scope and locked it.

Both parties are right about the facts and wrong about what they mean. The behavior is real. It's also the documented design, and it has been a commercial product with published per-unit pricing for years.

One caveat on sourcing: the original post now returns a 404 with no archived snapshot, and I found no independent account of the disclosure exchange. So treat the narrative about Cloudflare's response as one person's uncorroborated telling. The technical claim at the center of it needs no corroboration, because Cloudflare documents it.

A bearer token is supposed to be portable

The Turnstile widget produces a string and drops it into a hidden cf-turnstile-response input. That string is a bearer token in the plainest sense: whoever holds it can spend it, once, within 300 seconds. Cloudflare documents both limits — a replay comes back as timeout-or-duplicate — and documents nothing about binding the token to a browser, because it isn't bound to one.

There's no fingerprint baked into it, no session cookie it has to travel with, no TLS signature it gets checked against. The one parameter that could tie a token to where it was minted, remoteip, is optional, and sending it is the integrator's job.

So yes: solve the challenge in Firefox, carry the unused token to Chrome, submit it. It validates. Firefox never spent it, Chrome spends it, and siteverify has no grounds to object. That isn't a hole in the design. It is the design. The token attests that a challenge was solved for a given sitekey on a given hostname. It says nothing about who's holding it now, and was never meant to.

The bypass ships with a price list

2Captcha sells solved Turnstile tokens at $1.45 per thousand. Their integration instructions describe the maneuver in so many words: use the token returned by the API in your interaction with the target website, normally by sending it through the input named cf-turnstile-response. Solve in one place, spend in another. CapMonster, CapSolver and a long tail of competitors sell the same primitive at roughly the same price.

None of this is new, and none of it is Turnstile-specific. reCAPTCHA v2 had the identical property: g-recaptcha-response, single use, a couple of minutes of validity, freely relayable between clients. Solving farms have monetized that since the mid-2010s. When Cloudflare launched Turnstile in September 2022 and made it free for everyone a year later, it changed how the signal gets collected — a rotating set of non-interactive browser challenges instead of traffic-light grids — and left the token contract exactly where it found it. There's no version of a stateless proof-of-humanity token that survives being copied, short of binding it to something the server already knows about the client. Which brings us to the part worth your attention.

The real bug is usually in your handler

The interesting question was never whether the token moves. It's what your server does when one shows up.

Cloudflare's docs are blunt about this: server-side validation is mandatory, and skipping it "will leave major vulnerabilities in your implementation." A depressing share of integrations render the widget, check that the field is non-empty, and call it protected. For those sites, token relay is a complete bypass — and it's their bug, not Cloudflare's.

Even among teams that do call siteverify, most stop at success: true. The response carries more than that:

const r = await fetch("https://challenges.cloudflare.com/turnstile/v0/siteverify", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({
    secret: env.TURNSTILE_SECRET,
    response: token,
    remoteip: req.headers.get("cf-connecting-ip"),
  }),
}).then((r) => r.json());

if (!r.success) return new Response("failed", { status: 403 });
if (!ALLOWED_HOSTS.has(r.hostname)) return new Response("wrong origin", { status: 403 });
if (r.action !== "signup") return new Response("wrong form", { status: 403 });

The hostname check is what stops a token minted on your staging domain — or on a sitekey-sharing sibling app — from being spent against production. The action field scopes a token to the form it was solved on, so a token from your low-value newsletter box can't be replayed into password reset. Both are free. Both are skipped constantly.

remoteip is the only lever that touches the researcher's exact scenario, and it's a weak one. Two browsers on the same laptop share an IP, so it wouldn't have caught this at all. It catches the token that got solved in a datacenter and spent from a residential proxy, which is the shape most abuse actually takes. Real defense against bulk relay is rate limiting and per-account velocity checks downstream, not the challenge itself.

Worth knowing if you're on the newer setup: pre-clearance issues a cf_clearance cookie, but Cloudflare is explicit that the Turnstile token still requires siteverify. That cookie is widely reported to be pinned to IP, user agent and TLS fingerprint — that's from the scraping literature rather than Cloudflare's docs, so hold it loosely, but it does suggest the cookie wouldn't survive a copy-paste between browsers. Which is one more reason to think the widget token was the thing being moved here.

"Out of scope" is carrying two meanings

Cloudflare's bug bounty program already codifies this posture for the adjacent product: WAF bypasses are treated as an enhancement to the WAF rather than a bug, closed as Informational, with a discretionary award topping out at $50. Turnstile isn't the WAF, but it's the same species of system — an adversarial classifier where "someone got past it" is the permanent operating condition, not an incident.

That's a defensible policy. The failure is linguistic. "Out of scope" lands on a reporter as we won't pay you, when the honest sentence is this is working as documented and here's the doc. Those aren't the same message, and only one of them ends the argument. Locking the report while a related change ships reads as bad faith even when it isn't.

The cheap fix is a paragraph in the Turnstile docs stating plainly that tokens are relayable by design, that hostname and action checks are the mitigation, and that relay reports won't be triaged. Cost: an afternoon. Saves every future researcher the same dead end.

The verdict

This is a rediscovery, not a bypass, and "critical" is doing no work in that headline. But the researcher tripped over something genuinely worth saying, just aimed at the wrong party. If your Turnstile integration doesn't validate hostname and action, a token relay isn't a theoretical weakness in Cloudflare's product. It's a working exploit against yours, and it costs an attacker about a tenth of a cent.

Go read your siteverify handler.