Captcha Solver
What is a CAPTCHA solver?
A CAPTCHA solver is a service or model that completes a CAPTCHA challenge on behalf of automated software, so a bot can pass a check designed to stop it.
This page is written for the people on the receiving end. If solver traffic is getting through your signup, login or checkout, the useful thing to understand is why the puzzle stopped being the control, and what replaced it.
How a solver service works
The mechanics are simple and that is the problem.
- The automated client hits your page and receives a challenge.
- It forwards the challenge to a solver service through an API.
- A human worker or a vision model produces the answer, usually within a few seconds.
- The answer comes back and the client submits it to you.
At no point does anything invalid arrive at your server. The answer is correct. Your challenge worked exactly as designed and verified exactly what it was built to verify: that a correct answer was supplied. It was never able to verify who supplied it.
Why harder puzzles do not work
The economics run in the wrong direction, and this is the single most useful thing to understand about solvers.
Commercial solver services charge roughly one to two dollars per thousand solves. Against a target where a single success is worth anything at all, that is not a deterrent.
Now make the puzzle twice as hard. The attacker's cost goes from a fraction of a cent to a slightly larger fraction of a cent. Your legitimate users lose real seconds, some fail, and some leave. You have taxed your customers and inconvenienced nobody else.
Worse, the accessible fallback is usually the weakest link. Audio CAPTCHA exists so that blind users can pass, and audio is the mode that automated transcription defeats most cheaply. So the hardened visual challenge runs next to an easier audio one, and the automation just takes the audio route.
What catches them
If the answer cannot be trusted, detection has to happen somewhere other than the answer.
The round trip. Getting a challenge out to a third party and an answer back takes time and leaves a pattern. A session where the gap between challenge render and answer submission is consistently a few seconds, with no intervening interaction, looks nothing like a person deciding.
Behaviour before the challenge. Real users arrive at a form having done something first. Solver-driven automation usually does not, and the interaction it does produce has timing regularities that people do not have.
What the client cannot fake cheaply. Header ordering and combinations real browsers do not emit, and CPU and SIMD timing signatures that contradict the hardware the client claims to be running on. A JA4 TLS fingerprint contributes only where it contradicts something else, because every Chrome install produces the same one: it identifies the TLS stack rather than the client using it.
Failure grinding. A cohort that clears its challenges is a cohort of users, however much volume it produces. A cohort that keeps failing and retrying is grinding at something it cannot pass. Volume alone cannot tell a busy office behind one IP from an automated solver; the solve ratio can.
When Prosopo stops one of these, the block names it. The string that comes back is the detector, for example Solver service detected, rather than a risk score. Knowing which service the attacker is paying for tells your team something about how organised the operation is.
Where solver traffic shows up
Form spam. Most junk submissions are not written by people. See spam bot protection and the Spam Filter.
Credential stuffing. A solver is the enabling step, not the attack. See credential stuffing and account takeover.
Ticket scalping. Solver services are a line item in a scalper's operating costs. See anti-scalping bot protection.
Account creation at scale. Bulk accounts warmed up for later use.
In the OWASP taxonomy this is OAT-009 CAPTCHA Defeat, and OWASP classifies it as an enabler rather than an end in itself. The classification is the right one.
The practical takeaway
If your current control is a challenge, you are relying on a test that a two-dollar API answers correctly. The fix is not a harder test. It is detection that identifies the solver in the request path, and enforcement that does not depend on the user proving anything at all.