npm · @apostrophecms/form
ApostropheCMS: CAPTCHA response token not URL-encoded
Summary Form and login CAPTCHA verification interpolate the user-supplied widget token unencoded into the server-side verification URL/body, allowing a crafted token to inject query parameters into the reCAPTCHA/hCaptcha verify request.
Details
packages/form/lib/recaptcha.js:39 — recaptchaUri = 'https://www.google.com/recaptcha/api/siteverify?secret=${recaptchaSecret}&response=${input.recaptcha}'packages/login-recaptcha/index.js:44 — same pattern for loginpackages/login-hcaptcha/index.js:47 — body: 'response=${token}&secret=${secret}'PoC
input.recaptcha = 'attacker_token&secret=INJECTED_SECRET&something=1'
→ resulting verify URL:
https://www.google.com/recaptcha/api/siteverify?secret=<real>&response=attacker_token&secret=INJECTED_SECRET&something=1
# (replicated exactly from recaptcha.js:39)
Impact
Low: a crafted token smuggles extra key=value pairs (secret, extra response) into the outbound verify call, forcing verification failures (DoS of the captcha gate and of captcha-gated login/form flows) and enabling automated bypass probing; no secret exfiltration.
Remediation — Build the verify request with URL + searchParams (or encodeURIComponent on both secret and response), and validate the token against ^[A-Za-z0-9._-]{1,2048}$ before use.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.