CVE-2026-112348 in Kirki Plugin
Summary
by MITRE • 10/30/2026
Kirki plugin for WordPress before 6.2.5 contains a reCAPTCHA bypass vulnerability that allows unauthenticated attackers to submit frontend forms without valid verification by omitting the g-recaptcha-token field from POST requests to the form submission endpoint. Attackers can exploit the verify() method's early return on empty token values to submit unlimited forms, triggering notification emails, webhooks, and unbounded writes to the submissions table without completing reCAPTCHA validation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The Kirki plugin for WordPress prior to version 6.2.5 contains a critical authentication bypass vulnerability related to its integration with Google reCAPTCHA services. This flaw stems from an improper implementation of security controls within the form submission logic, specifically in how the application validates user interaction proofs. The vulnerability allows unauthenticated attackers to circumvent the intended protection mechanism by simply omitting the g-recaptcha-token field from POST requests directed at the form submission endpoint. In a properly secured system, the absence or invalidity of this token should trigger an immediate rejection of the request and prevent further processing. However, due to the flawed logic in the verify method, the application performs an early return when it encounters empty or missing token values rather than treating them as failed authentication attempts. This design error effectively neutralizes the reCAPTCHA protection for any form that relies on this specific validation routine within the Kirki framework.
From a technical perspective, the core issue lies in the conditional logic governing the verification process. When an attacker constructs a malicious POST request without including the g-recaptcha-token parameter, the backend script checks for the presence of this token and finds it absent or empty. Instead of invoking the Google reCAPTCHA API to validate the challenge response against a secret key, which would result in a failure status code due to missing data, the application simply exits the verification function prematurely. This early exit is interpreted by subsequent parts of the form processing pipeline as successful validation because no explicit error flag or exception was raised during this specific check phase. Consequently, the request proceeds through the rest of the submission workflow as if it had passed all security checks, allowing the attacker to bypass human interaction tests entirely.
The operational impact of this vulnerability is significant and multifaceted, affecting both data integrity and system availability. Attackers can exploit this flaw to submit unlimited forms without completing reCAPTCHA validation, leading directly to unbounded writes in the database submissions table. This capability facilitates automated spamming attacks where malicious actors flood contact forms or registration portals with junk data at a scale that would be impossible if proper bot detection were enforced. Furthermore, each successful submission triggers downstream actions configured by the site administrator, such as sending notification emails via SMTP services and invoking external webhooks. These side effects can result in excessive email delivery costs, potential blacklisting of the server's IP address due to spam complaints, and unnecessary load on third-party API endpoints triggered by webhook calls. The ability to generate uncontrolled database entries also poses a risk of storage exhaustion or performance degradation over time if left unchecked.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to correctly verify that an entity is who it claims to be before granting access to protected resources or actions. Additionally, from the perspective of offensive security frameworks such as MITRE ATT&CK, this behavior relates to techniques involving automated exploitation and resource exhaustion, specifically falling under tactics like Initial Access through web application exploits and Impact via data manipulation or denial of service conditions caused by excessive requests. The lack of rate limiting combined with the authentication bypass creates a potent vector for abuse that can disrupt normal site operations and compromise the trustworthiness of user-submitted content.
To mitigate this vulnerability, administrators must upgrade the Kirki plugin to version 6.2.5 or later immediately upon availability, as these versions contain patches addressing the flawed verification logic. Until an update is applied, temporary mitigations include implementing server-side rate limiting on form submission endpoints to restrict the number of requests allowed from a single IP address within a given timeframe. Additionally, deploying a Web Application Firewall with rules specifically targeting abnormal POST request patterns or missing required security tokens can help block exploitation attempts at the network perimeter. It is also advisable to review custom code that interacts with Kirki forms to ensure no additional logic relies on the assumption that empty token fields indicate valid submissions, and to enforce strict input validation checks before processing any form data. Regular monitoring of submission logs for spikes in activity or unusual patterns can aid in early detection of ongoing exploitation attempts while permanent fixes are being deployed.