Topic starter
19/08/2026 3:29 pm
TL;DR: SiteGround’s SGCaptcha returns HTTP 202 with a JavaScript proof-of-work challenge that can make tools like Nuclei and WPScan finish cleanly with zero findings, according to Sprocket Security. The issue is not blocking access, but suppressing scanner visibility and distorting what security teams think they have validated.
Editorial analysis by NHI Mgmt Group, based on content published by Sprocket Security: “Please Show Your Work: Bypassing JavaScript Proof-of-Work CAPTCHAs”.
Key questions
Q: What breaks when a WordPress site returns 202 Accepted instead of blocking bots outright?
A: The assessment pipeline breaks because many scanners interpret 2xx responses as successful delivery.
Q: Why do proof-of-work CAPTCHAs hide risk from automated scanners?
A: They hide risk because the gate shifts from simple HTTP retrieval to JavaScript execution and nonce solving.
Q: What are the signs that a scanner has been blinded by a challenge page?
A: Common signs include repeated HTTP 202 responses, challenge headers, redirects to a CAPTCHA URL, and scan runs that end with zero findings against a target that should have content.
Practitioner guidance
- Instrument scanner challenge detection Flag HTTP 202 responses, challenge headers, and JavaScript redirects as a distinct scan state so a run cannot be mistaken for a clean assessment.
- Validate with a browser-capable test path Use tooling that can execute JavaScript and follow cookie issuance when testing gated WordPress targets, especially where proof-of-work challenges are present.
- Compare raw requests with gated responses Run the same check with and without cookie replay so you can see whether the challenge is suppressing content visibility rather than blocking the service outright.
Bottom line: PoW CAPTCHA challenges can turn automated scanning into a visibility problem, because the tool may complete successfully without ever reaching the protected page.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:12 pm
Challenge visibility is now a governance problem, not just a bot problem. A control that returns 202 Accepted while redirecting the client into a browser puzzle can make defensive and offensive scanners report a false sense of coverage. The issue is not whether the site is protected from bots, but whether the security team can prove what the scanner actually saw. For practitioners, challenge handling must be part of validation design, not an afterthought.
A question worth separating out:
Q: Should teams trust a clean scan if the target uses browser-side access challenges?
A: No, not without verifying what the scanner actually executed. A clean scan against a challenge-protected target may only mean the tool handled the transport layer successfully. Teams should confirm whether the workflow solved the challenge, captured the cookie, and retried the request before treating the result as evidence. Otherwise the assessment can understate exposure.
👉 Read our full editorial: PoW CAPTCHA challenges are blinding security scanners on WordPress sites