EUVD-2026-71025
GHSA-v453-9p95-fp34
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify Grav form using reCAPTCHA v3
-
DeliveryObtain any reCAPTCHA token
-
ExploitSubmit token under v2 field name g-recaptcha-response
-
ExecutionPlugin validates via v2 branch, skips score/action
-
PersistBot submission accepted
-
ImpactAutomate spam or abuse at scale
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Trusted input validation
|
| Exploitation Conditions | Requires the target Grav site to be configured for reCAPTCHA v3 specifically (the bypass forces the request into the v2 validation branch); sites using v2 are not affected by this technique. No authentication, user interaction, or special privileges are needed - an anonymous attacker simply places the reCAPTCHA response value under the v2 field name (g-recaptcha-response) rather than the v3 field name (token) in an otherwise normal form POST. The limiting factor is purely the v3 configuration prerequisite and the presence of a reachable form; there are no platform or version constraints beyond the affected 8.0.6-9.1.19 range. |
| Impact | The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 9.3) accurately reflects that exploitation is trivial, remote, and unauthenticated against a default v3-configured site - the attack is a single crafted form POST with no user interaction. However, the VC:H/VI:H/VA:H impact metrics are overstated: this defeats bot/CAPTCHA protection, it does not by itself yield code execution, data theft, or system compromise. The realistic consequence is downstream abuse - automated spam, credential-stuffing or brute-force submissions, comment/registration flooding, and abuse of any email or webhook the form triggers - so I assess integrity and availability as Low and confidentiality as None. No EPSS, KEV, or POC data was supplied; treat exploitation probability as unquantified but the bar to exploit is low, so any operator running Grav forms with v3 protection should patch promptly rather than defer. |
| Exploit ScenarioDerived | An attacker targeting a Grav site with a v3-protected contact or registration form scripts a bot to solve or acquire any low-cost reCAPTCHA token, then submits it in the g-recaptcha-response field instead of the expected token field. The plugin routes validation to the v2 branch, accepts the token without score or action checks, and processes the submission, letting the attacker flood the form with spam, abuse email delivery, or automate account registration at scale. No public exploit code was identified, but the technique requires only a modified HTTP request. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 04, 2026
reCAPTCHA v3 bot protection in the Grav Form plugin (getgrav/grav-plugin-form) 8.0.6 through 9.1.19 can be fully bypassed by an anonymous remote attacker who submits a token under the wrong field name. Because the plugin picks which reCAPTCHA validation branch to run based only on which response field key appears in the payload, sending a v3 token in the v2 field (g-recaptcha-response) forces the v2 code path, which never checks the risk score threshold or the expected action. There is publicly available advisory detail from VulnCheck but no public exploit identified at time of analysis and no evidence of active exploitation.
RemediationAI
Vendor-released patch: upgrade the Grav Form plugin to version 9.1.20 or later, which fixes the version-selection logic; this is the primary and recommended action per GHSA-89j6-8h38-2cc3. If immediate patching is not possible, compensating controls include switching the site's form protection from reCAPTCHA v3 to reCAPTCHA v2 or hCaptcha (the v2 challenge branch is not the bypass target), or placing forms behind an authenticated area or a WAF/rate-limiting layer to throttle automated submissions - with the trade-off that v2 reintroduces user friction and rate-limiting only reduces rather than eliminates abuse. Review advisory details at https://www.vulncheck.com/advisories/grav-form-plugin-before-9.1.20-recaptcha-v3-authentication-bypass before choosing a workaround.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Grav is a flat-file PHP CMS, and grav-plugin-form is its bundled forms component used for contact, registration, and similar form handling. The flaw is CWE-807 (reliance on an untrusted input in a security decision): the plugin trusts the attacker-controlled shape of the submitted payload to decide which reCAPTCHA verification logic to invoke. reCAPTCHA v3 is a score-based, frictionless system where the server is supposed to verify Google's returned score against a threshold and confirm the 'action' matches; v2 is a checkbox/challenge model with no score. By routing a request into the v2 branch, all v3-specific integrity checks (score threshold, action verification) are skipped, so any token - even one earned trivially by a bot - is accepted. The affected CPE is cpe:2.3:a:getgrav:grav, though the vulnerable code lives specifically in the Form plugin rather than Grav core.
Know when Grav gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Trivial remote unauthenticated bypass (AV:N/AC:L/PR:N/UI:N) but impact is defeating bot protection enabling spam/abuse, so I:L/A:L and no confidentiality, not the input's H/H/H.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
The Grav Form plugin (getgrav/grav-plugin-form) versions 8.0.6 through 9.1.19 select the reCAPTCHA version to validate based solely on which response field key is present in the submitted payload. On a site configured for reCAPTCHA v3, an anonymous attacker can place their v3 token under the v2 field name (g-recaptcha-response instead of token), causing validation to use the v2 branch, which never applies the score threshold or verifies the expected action. This results in a complete bypass of reCAPTCHA v3 bot protection. The issue is fixed in version 9.1.20.
Technical POC Analysis
CWE-807: the plugin uses an untrusted request field name to choose the reCAPTCHA validation branch.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Grav Form plugin versions 8.0.6-9.1.19 contain a critical reCAPTCHA v3 bypass that allows unauthenticated attackers to defeat bot protection by sending a v3 token under the v2 field name, forcing validation logic to skip risk-score and action checks. Organizations using this plugin for contact forms, user registrations, or feedback submission face immediate exposure to spam campaigns, credential stuffing, and account takeover attempts without manual intervention.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Replace reCAPTCHA v3 with reCAPTCHA v2, hCaptcha, Cloudflare Turnstile, or similar alternative CAPTCHA provider; (2) Implement server-side request rate-limiting and burst detection on form submission endpoints; (3) Deploy IP reputation filtering and geolocation-based access controls if appropriate; (4) Add form submission logging and anomaly alerting to detect attack patterns; (5) Temporarily require authentication for high-value forms.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Server-side template injection (SSTI) in Grav (getgrav/grav) prior to 1.8.0-beta.27 allows an authenticated attacker hol
Broken access control in Grav CMS (CWE-285) before 1.8.0-beta.27 lets an authenticated editor-level user escalate their
A Remote Code Execution (RCE) vulnerability in Grav CMS v1.7.48 allows an authenticated admin to upload a malicious plug
Grav is a file-based Web platform. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low a
GravCMS 1.10.7 allows unauthenticated remote attackers to write arbitrary YAML configuration files, leading to full serv
Remote code execution in Grav CMS 2.0.4 (fixed in 2.0.7) lets an authenticated user holding the admin.pages or api.pages
Remote code execution in Grav CMS before 2.0.15 allows attackers holding page-edit or blueprint-config privileges to wri
Vertical privilege escalation in Grav CMS before 2.0.14 lets a delegated administrator holding only the admin.users perm
Stored cross-site scripting in Grav CMS before 2.0.15 lets authenticated editors smuggle JavaScript event handlers past
Server-side request forgery (SSRF) in Grav CMS versions prior to 1.7.49.5 allows remote authenticated attackers to make
Grav is a file-based Web platform. Prior to 1.8.0-beta.27, Grav CMS is vulnerable to a Server-Side Template Injection (S
Remote code execution in Grav CMS before 2.0.13 allows authenticated low-privilege users to plant and execute arbitrary
Exploit-DB