EUVD-2026-51795
GHSA-72h4-7f42-rjh6
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Network form submission with subscriber auth (PR:L); AC:L because once the required feed configuration exists, exploitation requires no special timing or conditions; full C/I/A impact from admin takeover.
Primary rating from Vendor (wordfence).
CVSS VectorVendor: wordfence
Lifecycle Timeline
2DescriptionCVE.org
The Pronamic Pay plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 10.1.0 This is due to the maybe_update_user_role() function passing an attacker-controlled Gravity Forms field value ($lead[$feed->user_role_field_id]) directly into WP_User::set_role() without any allowlist validation, capability comparison, or permission check to constrain which roles can be assigned. This makes it possible for authenticated attackers, with Subscriber-level access and above, to escalate their own WordPress account to Administrator by tampering with the role field value in a form submission. Exploitation requires that an administrator has already configured a Pronamic Pay payment feed in Gravity Forms with the Update User Role option enabled and mapped to a form field; once that configuration is in place, no further preconditions exist to prevent an authenticated attacker from exploiting this vulnerability.
AnalysisAI
Privilege escalation in the Pronamic Pay WordPress plugin (all versions ≤10.1.0) enables authenticated Subscriber-level users to self-escalate to Administrator by submitting a tampered Gravity Forms field value that is passed unvalidated into WordPress's WP_User::set_role(). The flaw is in maybe_update_user_role() within the plugin's Gravity Forms extension, which performs no allowlist check, capability comparison, or permission verification before applying the attacker-supplied role string. Exploitation is gated on a specific administrator-configured Gravity Forms payment feed setup, but once that configuration exists, a low-privilege user can achieve full WordPress site compromise. No public exploit or CISA KEV listing confirmed at time of analysis; a patch was released in version 10.2.0.
Technical ContextAI
The vulnerability resides in the Pronamic Pay plugin's Gravity Forms integration (packages/wp-pay-extensions/gravityforms/src/Extension.php, lines 144, 376, 379, 988 in the 10.1.0 tag). The maybe_update_user_role() function retrieves a role name from a Gravity Forms lead entry using $lead[$feed->user_role_field_id] - a value sourced directly from an authenticated user's form submission - and passes it without validation to WordPress's native WP_User::set_role(). WordPress's set_role() is a privileged internal function that accepts any valid role string and applies it immediately; it is the responsibility of the calling code to enforce role restrictions. CWE-269 (Improper Privilege Management) precisely describes this root cause: the plugin grants elevated privileges based on attacker-controlled input without verifying that the requested role is within the set of roles the requester is permitted to assign, nor that it does not exceed the requester's own privilege level. The affected plugin is also tracked under the pronamic-ideal slug on the WordPress plugin repository.
RemediationAI
The primary fix is to update the Pronamic Pay plugin to version 10.2.0 or later, which contains the validated changeset at https://plugins.trac.wordpress.org/changeset?old_path=%2Fpronamic-ideal/tags/10.1.0&new_path=%2Fpronamic-ideal/tags/10.2.0. WordPress site administrators should apply this update via the WordPress admin dashboard or WP-CLI (wp plugin update pronamic-ideal). As an immediate workaround prior to patching, administrators should audit all active Gravity Forms payment feeds configured through Pronamic Pay and disable the 'Update User Role' option on any feed where it is enabled - this eliminates the exploitable code path entirely, though it will also disable the legitimate role-update functionality for those feeds. Sites that have not configured Gravity Forms with the Update User Role feature in Pronamic Pay feeds are not at risk from this specific vulnerability and do not require emergency action beyond the standard plugin update.
The mailSend function in the isMail transport in PHPMailer before 5.2.18 might allow remote attackers to pass extra para
The isMail transport in PHPMailer before 5.2.20 might allow remote attackers to pass extra parameters to the mail comman
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
The Hash Form - Drag & Drop Form Builder plugin for WordPress is vulnerable to arbitrary file uploads due to missing fil
Authentication bypass in the LiteSpeed Cache WordPress plugin (versions prior to 6.5.0.1) allows unauthenticated remote
The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all
The Simple File List plugin for WordPress through version 4.2.2 contains an unauthenticated remote code execution vulner
The AI Engine WordPress plugin through version 3.1.3 exposes Bearer Token values through the /mcp/v1/ REST API endpoint
The SureTriggers WordPress plugin through version 1.0.82 contains a privilege escalation vulnerability that allows unaut
The Ninja Forms plugin before 2.9.42.1 for WordPress allows remote attackers to conduct PHP object injection attacks via
The Business Directory Plugin - Easy Listing Directories for WordPress plugin for WordPress is vulnerable to time-based
Remote code execution in WordPress 6.9.x (before 6.9.5) and 7.0.x (before 7.0.2) arises from a REST API batch endpoint r
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today