Executive brief
The Grav Form plugin's reCAPTCHA validation mechanism selects which version (v2 or v3) to use based on which field name appears in the submitted form data, rather than the site's configured setting. An attacker can submit a v3 token under the v2 field name to bypass reCAPTCHA v3's bot-detection score checks entirely, allowing automated attacks to succeed on sites that believe they have bot protection enabled.
Technical details
The vulnerability is a reliance-on-untrusted-inputs logic flaw in the ReCaptchaProvider class (CWE-807). The vulnerable code detects the reCAPTCHA version from the form payload using detectVersionFromPayload(), which keys purely on the presence of either "token" (v3) or "g-recaptcha-response" (v2) fields, and this detection unconditionally overrides both the site configuration and form frontmatter. When v2 validation is triggered, the code skips setting the score threshold and expected action checks that are mandatory in v3. An unauthenticated attacker can POST a form with a valid form-nonce and place their v3 token under the v2 field name, causing the v2 validation branch (which has no score or action verification) to be used instead of v3. The fix in version 9.1.20 treats the configured version as authoritative and uses payload data only to locate the token.
Affected products
- Getgrav Form plugin 8.0.6 to 9.1.19
Timeline
- 2026-08-20: disclosed
- 2026-09-04: advisory
- 2026-09-04: patched: version 9.1.20