Skip to content
eastbaycyber

CVE-2026-16635: Pronamic Pay Gravity Forms Privilege Escalation

CVE explainers 10 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-08-01
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - Authenticated users can potentially escalate to Administrator in affected Pronamic Pay deployments. - Affects Pronamic Pay versions up to and including 10.1.0 when a specific Gravity Forms option is enabled. - Upgrade beyond 10.1.0 immediately; assume high risk if the feature is configured.

Vulnerability at a Glance

Field Value
CVE ID CVE-2026-16635
Severity High
CVSS v3.x 8.8
Attack vector Authenticated attack through a Gravity Forms submission in a configured Pronamic Pay payment feed
Privileges required Low, Subscriber-level access or above
Patch available Yes, update to a version newer than 10.1.0; 10.2.0 is confirmed available on WordPress.org

CVE-2026-16635 is a privilege escalation flaw in the Pronamic Pay WordPress plugin, specifically in its Gravity Forms integration. The issue exists because a user-controlled field value can be passed into WordPress role assignment logic without sufficient validation or authorization checks. In the right configuration, a low-privileged authenticated user can submit a crafted form value and promote their own account.

This is not a generic unauthenticated WordPress plugin bug. Exploitation depends on a specific administrative setup: a site administrator must have configured a Pronamic Pay payment feed in Gravity Forms with the Update User Role option enabled and mapped to a form field. If that configuration is present, the path to privilege escalation becomes viable for authenticated users.

What Is This Vulnerability?

At its core, this is an insecure trust boundary issue. According to the NVD description, the vulnerable code path in maybe_update_user_role() takes an attacker-controlled Gravity Forms field value, referenced as $lead[$feed->user_role_field_id], and passes it directly to WP_User::set_role(). That is the dangerous sink: WordPress role assignment is being driven by form data that the attacker can tamper with.

The security failure is not simply that a role field exists. The problem is that the submitted value is accepted without an allowlist of safe roles, without a capability comparison to make sure the actor can assign that role, and without a permission check that constrains which role can be set. In practice, this means the application logic treats user-supplied input as authoritative for a sensitive administrative action.

For defenders, the most important takeaway is that this vulnerability sits in a business workflow, not just a low-level code bug. If a payment or onboarding flow is designed to update user roles after a form submission, and the role source is a user-editable field, the site can effectively expose administrative privilege assignment to any authenticated user who understands how to manipulate the request.

Technical Notes

The vulnerable behavior described by NVD centers on these elements:

// Conceptual flow based on NVD description.
$role = $lead[$feed->user_role_field_id];
$user->set_role($role);

What should have happened instead is a validation and authorization flow more like:

$allowed_roles = array( 'customer', 'member' );
$requested_role = $lead[$feed->user_role_field_id];

if ( in_array( $requested_role, $allowed_roles, true ) ) {
    // Additional capability checks should still apply.
    $user->set_role( $requested_role );
}
AnalystImpact · assess the risk

Who Is Affected?

The affected product is Pronamic Pay for WordPress, in the Gravity Forms extension context. Based on the NVD description, the vulnerable range is all versions up to and including 10.1.0. That means defenders should treat 10.1.0 and earlier as affected unless they have strong evidence of a custom backport or vendor-specific mitigation.

The current version shown on the official WordPress.org plugin page at the time of the research note is 10.2.0, which is beyond the affected range. However, because the primary-source advisory text and Trac patch diff were not directly retrievable in this session, the exact first fixed release could not be independently quoted from a vendor advisory. What is known with confidence is that anything newer than 10.1.0 should be preferred, and 10.2.0 is an available non-vulnerable target based on current listing data.

Not every installation of Pronamic Pay is automatically exploitable. The vulnerable path requires that an administrator has configured a Pronamic Pay payment feed in Gravity Forms and enabled Update User Role, then mapped that action to a form field. If your WordPress environment runs Pronamic Pay but does not use this Gravity Forms role-update workflow, your practical exposure may be lower. Even so, running a vulnerable version still warrants patching because configuration can change, and inherited admin settings are often poorly documented.

Organizations most at risk include membership sites, donation portals, event-registration systems, subscription flows, or any WordPress deployment where authenticated users can submit forms tied to payment or account lifecycle actions. In those environments, a successful privilege escalation to Administrator can quickly turn into plugin installation, persistent backdoor deployment, content tampering, credential theft, or full site takeover.

CVSS Score Breakdown

The CVSS v3.x base score is 8.8, which places this issue in the High severity range. The underlying NVD response available here did not return the full vector string, so defenders should avoid assuming unverified values for each metric. Still, the score itself strongly suggests a combination of impactful privilege gain with relatively achievable exploitation conditions.

The most plausible reason the score is this high is that the flaw allows a low-privileged authenticated user to obtain much higher privileges, potentially Administrator, which has major impact on confidentiality, integrity, and availability in a WordPress context. An Administrator can alter site settings, install or modify code, access sensitive data, and create persistence, so the blast radius is effectively full application compromise.

Privileges required are known to be low: the NVD description states Subscriber-level access and above. Attack complexity also appears limited once the vulnerable configuration exists, because the attacker only needs to tamper with a form field value in a submission path that is already permitted to them. User interaction beyond ordinary form submission does not appear central to exploitation, though a site must be configured in the vulnerable manner first.

Because the exact CVSS vector was not available in the source material used here, practitioners should treat the score as authoritative but not over-interpret individual metric values until the vector is confirmed in primary sources. Operationally, however, the difference is minor: a High-severity authenticated privilege escalation in WordPress should be treated as an urgent patching priority.

Exploitation Status

At the time of writing, there is no confirmed evidence from the provided primary sources that CVE-2026-16635 is being actively exploited in the wild. It is not listed in CISA’s Known Exploited Vulnerabilities catalog, which means there is no CISA-confirmed active exploitation record to cite.

There is also no confirmed public proof of concept from the primary-source material supplied for this article. The research note specifically states that a public PoC repository was not confirmed. That does not mean exploitation is difficult. In fact, the NVD description is detailed enough that experienced attackers or testers may be able to reproduce the issue without a published PoC.

Defenders should not wait for KEV listing or a GitHub PoC before acting. Authenticated privilege escalation flaws in WordPress plugins are frequently attractive because many sites expose login and form functionality to broad user populations. If your site uses the vulnerable feature path, exploitation may be straightforward for any user willing to modify a request in transit.

In practical terms: PoC not confirmed and in-the-wild exploitation not confirmed are not comfort signals. They simply mean defenders should patch based on impact and exploitability, not media attention.

ResponderRunbook · act now

How to Detect It

Detection should focus on two angles: configuration exposure and evidence of suspicious role changes. First, determine whether Pronamic Pay is installed in a vulnerable version range and whether any Gravity Forms payment feed is configured with Update User Role enabled and mapped to a form field. If that feature is not enabled anywhere, the specific exploit path described by NVD may not be reachable.

Second, review user-account changes around Gravity Forms submissions, payment events, and plugin activity. Unexpected promotions from Subscriber or other low-privilege roles to Administrator are the clearest post-exploitation indicator. In many WordPress environments, direct visibility into role changes is limited unless audit plugins, web server logs, or application logging are in place, so defenders may need to correlate account changes with form submission timestamps and source IPs.

If you have centralized logging for web requests, inspect requests to relevant form endpoints for suspicious role values in POST bodies. Exact parameters depend on form design, but any user-controllable field mapped to role update logic deserves scrutiny. Also review administrator creation events, plugin installation actions, theme edits, or changes to wp_options shortly after a low-privileged account interacted with a payment form.

Technical Notes

Example hunting ideas for web or WAF logs where request bodies are captured:

Look for POST requests to form-processing endpoints containing role-like values such as:
administrator
editor
shop_manager
author

Example generic grep approach on captured HTTP logs:

grep -RinE 'administrator|editor|shop_manager|set_role|user_role' /var/log/nginx /var/log/apache2

Example SQL to review suspicious role assignments in WordPress user meta:

SELECT user_id, meta_value
FROM wp_usermeta
WHERE meta_key LIKE '%capabilities%'
  AND meta_value LIKE '%administrator%';

Example Splunk-style query for suspicious form submissions and subsequent admin activity:

(index=web OR index=waf) method=POST ("gravity" OR "gform" OR "pronamic")
| regex _raw="administrator|editor|shop_manager"
| stats count by src_ip, uri, user, http_user_agent

If you have WordPress audit logging, prioritize events that show: - a Subscriber or low-privilege user account changing roles, - new Administrator creation after a form submission, - plugin/theme installation by a recently promoted account.

Mitigation and Patching

The primary mitigation is to upgrade Pronamic Pay to a version newer than 10.1.0. Based on the available evidence, 10.2.0 is a currently available release on WordPress.org and is beyond the vulnerable range. Because the exact first fixed version was not directly confirmed in a vendor advisory retrieved here, the safest practical guidance is to move to the latest available stable release, not merely the first version after 10.1.0.

If you cannot patch immediately, reduce exposure by reviewing all Pronamic Pay Gravity Forms payment feeds and disabling the Update User Role option anywhere it is enabled, especially where it is mapped to a user-editable field. That configuration is the key exploitation precondition described by NVD. Removing or disabling the role-update workflow is the most direct workaround while patching is pending.

You should also review all user accounts for unauthorized elevation, reset credentials for suspicious accounts, and inspect for post-exploitation actions such as new plugin installs, modified themes, scheduled tasks, or webshell-like PHP files in writable directories. Because successful exploitation can yield Administrator access, incident response should assume the possibility of full site compromise.

As an additional hardening step, reduce the population of accounts with Subscriber access if they are not needed, enforce MFA for privileged users, and deploy WordPress activity logging. Those steps do not fix the bug, but they improve both resistance and visibility.

Technical Notes

Upgrade via WP-CLI:

wp plugin update pronamic-ideal
wp plugin list | grep pronamic-ideal

If you need to pin to the latest available release after testing:

wp plugin install pronamic-ideal --force
wp plugin activate pronamic-ideal

Temporary risk-reduction workflow: 1. In WordPress admin, review Pronamic Pay payment feeds tied to Gravity Forms. 2. Disable Update User Role on each feed. 3. Remove any field mapping that lets users influence role selection. 4. Re-test the form to confirm role changes no longer occur.

Basic post-patch verification:

wp plugin list --fields=name,status,version | grep pronamic-ideal

If compromise is suspected, enumerate administrator accounts:

wp user list --role=administrator --fields=ID,user_login,user_email,registered

References

The primary reference for this CVE is the NVD record, which documents the vulnerable function, the user-controlled input path, the sink into WP_User::set_role(), the exploitation prerequisites, and the affected version range of all versions up to and including 10.1.0. That is the most authoritative technical summary available in the supplied material.

The official WordPress.org plugin page is the best available product reference in the research note for confirming the plugin identity, publisher, and currently listed version. It showed 10.2.0 as the current version at the time of verification, which supports the guidance to update beyond 10.1.0.

Additional references below are useful for validation and follow-up research. Note that the WordPress Trac URLs referenced by NVD returned 403 Forbidden during the research session, so this article does not quote the patch diff directly.

For further insights into security measures, consider exploring our articles on what is PCI DSS and MDR.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-08-01

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.