CVE-2026-16635
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedThe 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe Pronamic Pay plugin for WordPress has a privilege escalation vulnerability in the maybe_update_user_role() function. This function takes an attacker-controlled value from a Gravity Forms field submission and passes it directly to WP_User::set_role() without any validation, allowlisting, or capability checks. An authenticated user with Subscriber-level access can submit a form with a modified role field value to set their own account role to Administrator.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check Pronamic Pay plugin versionIn WordPress admin, go to Plugins > Installed Plugins and find Pronamic Pay. Compare the version number to 10.1.1. Alternatively, check the plugin header in /wp-content/plugins/pronamic-payments/includes/classes/class-pronamic-wp-pay-plugin.php or the main plugin file.Affected if Installed version is lower than 10.1.1 and the Update User Role feature is enabled in any payment feed
-
Verify Gravity Forms integration is activeCheck if Gravity Forms plugin is installed and active in WordPress under Plugins. The vulnerability only applies when Pronamic Pay is integrated with Gravity Forms payment feeds.Affected if Gravity Forms is installed and active, and Pronamic Pay has payment feeds configured
-
Inspect Pronamic Pay payment feeds for Update User Role settingGo to Forms > Payment Feeds (or the payment feed settings in Pronamic Pay). Look for any feed where the "Update User Role" option is enabled or configured.Affected if Any payment feed has Update User Role enabled and the plugin version is below 10.1.1
-
Review user role allowlist configurationCheck the payment feed settings for any role allowlist or role restriction configuration. The vulnerability exists because no allowlist validation is performed on the role value passed to WP_User::set_role().Affected if No allowlist is configured, allowing any role value to be set, and the Update User Role feature is enabled
You are affected if Pronamic Pay plugin version is below 10.1.1 AND any Gravity Forms payment feed has the Update User Role option enabled, allowing any authenticated subscriber to escalate privileges by submitting a manipulated role field.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpdate to version 10.1.1 or later if available. As an immediate workaround, disable the 'Update User Role' option in all Pronamic Pay payment feeds until the patch can be applied. Review user accounts for unauthorized role changes to Administrator.
Latest version after 10.1.0 (check WordPress plugin repository for current release)
- 1. Update the Pronamic Pay plugin to the latest available version from the WordPress plugin repository.
- 2. After updating, verify that the 'Update User Role' functionality in Gravity Forms feed settings has proper role validation in place.
- 3. Review all Gravity Forms feeds using Pronamic Pay with the 'Update User Role' option enabled to ensure only expected roles can be assigned.
- 4. Audit all user accounts with Subscriber-level or higher access for any unauthorized privilege escalation.
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation1.0 h
- Testing2.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,696.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-16635 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-16635 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data