FCaptcha v1.27: Every Detector Fired, Bot Allowed

A bot detector can fire correctly, on every signal it has, and still hand the bot a valid token.

FCaptcha shipped two releases this month that found exactly that, twice, for the same underlying reason. Neither was a detection failure. In both cases the detectors did their job and the arithmetic that combined them threw the answer away.

This is a worked example of a failure mode that any scored detection system can have, including ones that are not FCaptcha, so it is worth walking through the numbers rather than just the changelog.

Case one: a token for a request that did no work

v1.23.0 fixed this:

curl -X POST /api/verify -d '{"siteKey":"x","signals":{}}'

No browser. No proof of work. An empty signals object. That request minted a valid token on every server, and the token passed siteverify. The behaviour was present in v1.21.0 and earlier.

The detectors were not at fault. They fired. The problem was that the final verdict was a weighted sum, and in a weighted sum a category can contribute at most its own weight. The bot category is weighted 0.13. So every proof-of-work failure firing simultaneously reached a combined 0.1298, against a threshold of 0.5.

A forged solution referencing a challenge that was never issued did better and still lost: seven detections, final score 0.4003. Correct verdict, insufficient arithmetic.

The fix was to stop asking the score a question it structurally could not answer:

success = score < 0.5 && hostnameAllowed && powSatisfied

Proof of work moved outside the score entirely, alongside the hostname allowlist, as a precondition. Missing, unverifiable and nonce-unbound solutions are now marked dispositive and report 0.9 rather than 0.4, and refusals name the failed precondition in a new reason field, either pow_not_satisfied or hostname_not_allowed.

Impact on legitimate traffic: none measured.

Case two: a browser detectable only by how it moves

v1.27.0, shipped today, is the same shape of bug reached from the opposite direction.

A source-patched browser scrubs every JavaScript-observable automation flag at the binary level. It trips no headless signal, no CDP signal, no fingerprint, datacenter or bot category. Nothing environmental gives it away, because there is nothing left to observe.

In a weighted sum, all of those untouched category budgets still count as clean. That left such a browser with a ceiling of 0.41 against a 0.5 threshold. Not a high bar to clear. An unreachable one. It could not be blocked however obviously robotic its movement was.

The corpus sample of that adversary tripped seven correct behavioural detections:

• absent micro-tremor
• unnaturally direct path
• unnatural click precision
• consistent event timing
• consistent velocity
• no overshoot corrections
• movements too straight

Final score: 0.234. Allowed, token issued. Every detector fired and the aggregation discarded the verdict.

The fix: agreement as its own evidence

The score is now floored at 0.6 when two or more behavioural categories independently reach 0.5.

The reasoning is worth stating carefully, because it is not the same as raising a weight. Corroboration across independent views is evidence in its own right, distinct from any single view being strong. Three separate ways of looking at mouse movement agreeing that something is wrong means more than one of them being slightly more confident. That sample now scores 0.600, recommendation block, no token, on all three servers.

The constants were swept, not chosen

This is the part that makes the change trustworthy. The thresholds were measured against a labelled corpus over a 40-point grid rather than picked by intuition:

No human in the 126-sample panel reached two agreeing behavioural categories at any threshold tested. Requiring three categories fails outright: all sixteen such combinations leave the adversary allowed.

Human panel median stayed at 0.088 and maximum at 0.130, both unchanged, with a benchmark false-positive rate of 0.00%.

The caveat that should travel with the number

The adversary above is one synthetic, hand-authored corpus sample. It shows the arithmetic works on the shape the corpus describes. It does not show that it works against a real source-patched browser in the wild.

That distinction matters more than it might seem. A detection claim validated only against a sample you wrote yourself is a hypothesis with good arithmetic behind it, not a field result. Captured traces from real automation browsers remain the highest-value contribution anyone can make to the project.

The general lesson

Both bugs share a root cause: a weighted sum caps how much any one thing can matter.

That property is desirable most of the time. It is what stops a single noisy signal from blocking a real person. But it also means a weighted sum cannot express two things that detection genuinely needs:

1. Some conditions are not evidence, they are requirements. A missing proof of work is not a signal to weigh against other signals. It is a precondition that was not met. Scoring it at all was the mistake.
2. Agreement is information that no individual weight carries. Seven behavioural detections firing together is qualitatively different from one firing hard, and a sum flattens that difference away.

If you run any scored detection system, the diagnostic question is worth borrowing: what is the highest score an adversary can reach if it defeats every category except one? If that ceiling sits under your threshold, you have a class of attacker you cannot block regardless of how well your detectors work.

What else shipped since v1.12

Fifteen releases landed between v1.13.0 and v1.27.0. The ones worth knowing about:

Two of those deserve a second look before you upgrade.

v1.22.0 contains a breaking change. POST /api/token/verify now requires secret. It previously accepted and ignored one, which meant any caller who could reach the endpoint could spend a token. FCAPTCHA_LEGACY_UNAUTH_VERIFY=true restores the old behaviour for exactly one release.

v1.20.0 will move your scores. Two signals that were reported as Playwright artifacts, webdriver_configurable and chrome_runtime_missing, turned out to indicate nothing about automation. Removing them means legitimate visitors score lower than they used to, so any hand-tuned threshold needs re-checking.

Upgrading

FCaptcha is open source and self-hosted by default, so no data leaves your infrastructure. If you are on v1.21.0 or earlier, v1.23.0 is a security fix and you want it, since tokens could be minted with no proof of work at all.

WebDecoy’s own embedded client tracks the release tag and is on 1.27.0. If you want the background on the behavioural signals underneath all of this, v1.12 covered CDP input-event forensics and think-time cadence, and the keystroke cadence work goes back further still.