Description

The Knit Pay – Cashfree, Instamojo, Razorpay, PayPal and more plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 9.6.1.0. This is due to the `maybe_update_user_role()` function reading the target role directly from an attacker-controlled Gravity Forms entry field — configured via the feed's `user_role_field_id` — and passing it to `WP_User::set_role()` without validating the supplied value against an allowlist of permitted roles. This makes it possible for authenticated attackers, with Subscriber-level access and above, to elevate their privileges to administrator by tampering with the hidden role field value at form submission time. Exploitation is further enabled by the fact that $0 orders are synchronously marked as SUCCESS during form submission without requiring a real payment, and when no GF User Registration user can be resolved, the role assignment target falls back to `$lead['created_by']` — the currently authenticated submitter's own user ID — making any authenticated form submitter an eligible exploitation target.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-25T08:16:40.940Z",
  "pubdate": "2026-09-25T08:16:40.940Z",
  "executiveSummary": "The Knit Pay – Cashfree, Instamojo, Razorpay, PayPal and more plugin for WordPress contains a critical privilege escalation vulnerability affecting all versions up to and including 9.6.1.0.\nThe vulnerability originates from insecure handling of user role assignments during form submissions, specifically within the interaction between Knit Pay and Gravity Forms.\nBy manipulating hidden form fields, an authenticated user with minimal privileges (such as a Subscriber) can supply an arbitrary WordPress role, including 'administrator', to the application.\nBecause the system fails to validate user-supplied role inputs against a secure allowlist, the application executes a privilege update on the submitter's account.\nThe risk is significantly amplified by the plugin's logic for $0 transactions, which bypasses payment verification and allows the role assignment to occur synchronously without financial friction.\nThe impact of this vulnerability is total site compromise, as an attacker can elevate their privileges to gain administrative control over the WordPress installation.\nExploitation requires the attacker to be authenticated with at least Subscriber-level access and the ability to interact with a configured Gravity Forms entry form linked to the plugin.",
  "technicalDetails": "The vulnerability resides in the function 'maybe_update_user_role()' within the Knit Pay plugin. This function is responsible for dynamic role assignment based on data submitted through Gravity Forms.\nThe root cause is the lack of server-side input validation for the 'user_role_field_id' parameter. The plugin retrieves the target role directly from an attacker-controlled Gravity Forms entry field without verifying that the submitted value corresponds to a permitted or intended user role.\nWhen a form is submitted, the plugin processes the input and passes the value directly to the 'WP_User::set_role()' function. Since 'set_role()' modifies the privileges of the specified user object, any arbitrary string passed to it effectively reassigns the user's capabilities based on the input.\nThe attack flow follows these steps: First, an authenticated attacker (Subscriber) identifies a form utilizing the Knit Pay Gravity Forms feed. Second, the attacker intercepts or modifies the HTTP request during form submission, specifically targeting the hidden input field associated with 'user_role_field_id'. Third, the attacker changes the value of this field to 'administrator'.\nUpon submission, the plugin processes the entry. If no specific Gravity Forms User Registration user is resolved, the code falls back to the current user's ID ('$lead['created_by']'). If the payment transaction is identified as a $0 order, it is marked as SUCCESS synchronously, triggering the execution of 'maybe_update_user_role()'.\nBecause the validation check for the supplied role is absent, 'WP_User::set_role()' accepts the malicious 'administrator' string and updates the attacker's account privileges. The attacker is subsequently granted full administrative access to the WordPress environment.\nThis vulnerability is particularly dangerous because it bypasses the need for actual payment authorization in $0 scenarios, allowing for automated or manual exploitation by any registered account holder. The exposure is limited to authenticated users, but within that context, the severity is critical due to the ease of privilege escalation."
}