CVE-2026-85602 in Grav Form Plugin
Summary
by MITRE • 09/04/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Grav Form plugin serves as a critical component for managing user input and interaction within websites built on the Grav content management system, particularly when integrating third-party anti-bot services like Google reCAPTCHA. In versions ranging from 8.0.6 through 9.1.19, the implementation of this integration contains a fundamental logic error in how it determines which version of the reCAPTCHA API to invoke for validation. The vulnerability stems from an insecure design pattern where the plugin selects the verification branch based exclusively on the presence or absence of specific field names within the submitted HTTP payload rather than validating the integrity or type of the token itself. Specifically, the code checks if a key named g-recaptcha-response exists in the request data to decide whether to process the submission as reCAPTCHA v2. If this key is present, regardless of its content, the plugin proceeds with the v2 validation logic. Conversely, it assumes that any other field name indicates a v3 token and applies the corresponding verification routine. This approach fails to account for the fact that an attacker can manipulate the structure of the request payload to trick the server into using the wrong validation path.
This architectural flaw leads directly to a complete bypass of reCAPTCHA version 3 protections, which are designed specifically to detect automated bots through behavioral analysis and scoring mechanisms rather than simple user interaction challenges. When a site is configured for reCAPTCHA v3, it relies on Google's backend service to assign a score between zero and one based on the likelihood that the request originates from a human or an automation tool. The plugin is expected to retrieve this score and compare it against a predefined threshold; if the score falls below the threshold, the submission should be rejected as suspicious activity. However, because the vulnerability allows an attacker to submit their v3 token under the g-recaptcha-response key, the server incorrectly routes the validation request through the reCAPTCHA v2 verification endpoint. The v2 branch of the code is designed for interactive challenges and does not evaluate scores or verify expected actions such as login, signup, or checkout events. Consequently, the plugin accepts any valid-looking token submitted in this manner without performing the necessary security checks that would normally identify automated behavior.
The operational impact of this vulnerability is severe for websites relying on Grav Form to protect against spam, credential stuffing, and denial-of-service attacks via form submissions. An anonymous attacker can exploit this flaw by crafting a malicious HTTP POST request where the reCAPTCHA token generated by their automation tool or script is placed in the g-recaptcha-response field instead of the expected token field for v3. Since Google's API will still validate that the token itself is legitimate and associated with the correct site key, the server perceives the submission as authentic. The absence of score evaluation means that even highly suspicious traffic patterns are treated as benign human interactions. This effectively neutralizes the primary defense mechanism against bots, allowing attackers to automate submissions at scale without triggering alerts or blocks. Such exploitation can lead to data integrity issues through spam comments, unauthorized account registrations, and increased server load due to automated abuse of public-facing forms.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to adequately validate the input structure against its expected configuration state. It also relates closely to CWE-862 Missing Authorization, in the sense that the system grants access or processes requests based on flawed logic rather than proper security controls. In terms of offensive tactics, this exploit maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter if used as part of a broader automation campaign, but more specifically it represents a bypass of protective mechanisms akin to Defense Evasion techniques where attackers manipulate input fields to avoid detection by security software or web application firewalls. The root cause is not a buffer overflow or injection flaw but rather a logical misconfiguration in the decision-making process for API selection.
To mitigate this vulnerability, administrators must upgrade the Grav Form plugin to version 9.1.20 or later, where the developers have corrected the logic to properly distinguish between v2 and v3 tokens based on more robust criteria than mere field presence. Until an update is applied, site owners can implement a temporary workaround by modifying their server configuration or application code to enforce stricter validation rules that reject requests containing g-recaptcha-response if the global setting indicates reCAPTCHA v3 usage. Additionally, enabling additional layers of bot protection such as rate limiting on form endpoints and monitoring for anomalous submission patterns can help detect exploitation attempts in real-time. It is also advisable to audit other plugins or custom code within the Grav environment that interact with third-party security services to ensure similar input validation flaws do not exist elsewhere in the application stack.