If you received an email from me pointing you to this page, it is because your website appears to be running a version of ProfilePress (the WordPress plugin that still ships under the folder name wp-user-avatar, by ProperFraction) that falls within the affected range of a known security issue. This page explains what the issue is, how to work out whether it applies to your site at all, and how to update.

A note on the name before anything else, because it trips people up: this plugin began life as WP User Avatar and kept that slug through its rebrand, so in your files it lives at /wp-content/plugins/wp-user-avatar/, while the WordPress admin lists it under its full current name, “Paid Membership Plugin, Ecommerce, User Registration Form, Login Form, User Profile & Restrict Content – ProfilePress”. WP User Avatar and ProfilePress are the same plugin. This is a WordPress plugin throughout.

Before anything else, the most important fact about this notice: a version in the affected range does not by itself mean your site is exposed. The issue described below is only exploitable when ProfilePress publishes a front-end registration form that includes a role-selection field (the [reg-select-role] shortcode, or the “reg-select-role” field in the drag-and-drop form builder), configured in a particular way. If your site does not offer public self-registration, or your registration forms do not let the visitor pick a role, it is very likely not exposed even on an affected version. I can read your plugin version from public files, but I cannot see your registration forms, so this notice is a precautionary heads-up, not a confirmed finding about your site.

The issue is CVE-2026-12497, an unauthenticated privilege escalation in the plugin’s front-end registration handler (CWE-269, improper privilege management). The authority that assigned the CVE did not publish a severity score, and I am not inventing one; what matters for judging it is that it is unauthenticated but capped at a non-administrator role, and gated on the registration configuration described above. It affects versions 3.0.0 through 4.16.17 and is fixed in 4.16.18. If you are running an affected version, update ProfilePress to 4.16.18 or later (the current release is 4.16.19). There is no indication that this issue is being exploited anywhere.

A word on urgency, because this is a conditional notice: how much it matters for you depends almost entirely on whether you publish that kind of registration form. If you do not offer public self-registration with a role-selection field, updating is routine plugin maintenance. If you do, please treat the update as a priority: in that configuration, the flaw could let an unauthenticated visitor register at a higher role than your form offered (for example Editor or Author). Even then, this page is a precautionary heads-up, not an incident report, and no emergency response is implied.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the ProfilePress plugin itself is on an affected version.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, upload anything, or exploit anything.

All I did was look at publicly visible files that your website serves to every visitor (the same way your homepage is public) and note the version number that the plugin publishes in its public readme.txt file. I specifically did not touch the registration system, and nothing about this check touches your data, your admin area, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

ProfilePress is a widely used membership, user-registration, and login plugin for WordPress (around 100,000 active installs). Among other things, it lets a site publish front-end registration forms so visitors can create their own accounts, and those forms can optionally include a field that lets the visitor choose which role their new account should have.

In affected versions, the registration handler works out the roles a form offers and the roles it will accept using two different pieces of code. For some valid role-field configurations, the code that computes the accepted roles fails to read the form’s role list and silently falls back to accepting any editable role (that is, any role except administrator). Because there is also no nonce protecting the public registration handler, an unauthenticated visitor can submit a role of their own choosing and be registered at a higher role than the form offered, for example Editor or Author rather than the intended Subscriber.

Two things keep this in perspective. First, the impact has a firm ceiling: the plugin explicitly excludes the administrator role from what registration can assign, so this is a privilege-escalation issue capped at a non-administrator role, not a server takeover, an admin takeover, or remote code execution. Second, the entry point is a published registration form with a role-selection field, so the issue only reaches sites configured that way; a site with no public self-registration, or whose forms do not let a visitor pick a role, is very likely not exposed even on an affected version. And to repeat it plainly, there is no indication of active exploitation: it is not in CISA’s Known Exploited Vulnerabilities catalog, and I am aware of no exploitation reports.

If my email cited this issue, it means the version your site reports falls within the affected range. I did not test whether your particular site is exploitable, and I cannot see how your registration forms are configured; all I observed is that the site reports an affected version.

Am I affected?

Two questions decide it, in this order.

First: do you publish a ProfilePress registration form that lets a visitor pick a role? This is the deciding question, and only you can answer it.

  • If your site does not offer public self-registration, or its registration forms do not include a role-selection field (the [reg-select-role] shortcode or the “reg-select-role” field in the form builder), you are very likely not exposed, even on an affected version. Updating is still recommended, as ordinary maintenance.
  • If your site does publish a front-end registration form with a role-selection field, the issue applies to you, and you should update promptly.
  • To check: in the WordPress admin, look at your ProfilePress registration forms for a role field, or open one of your registration pages in a private browsing window and see whether a visitor who is not logged in is offered a choice of account role.

Second: which version are you running? You do not have to take my word for it, and for this plugin the version reports reliably.

From the WordPress admin area (authoritative):

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Go to Plugins then Installed Plugins.
  3. Find the entry listed as “Paid Membership Plugin … ProfilePress” (its folder is wp-user-avatar) and note the version shown beneath its name. This is the real installed version.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/wp-user-avatar/readme.txt in a browser. The Stable tag: line near the top is the version your install reports, and this is the same public file I read.

One small heads-up if you are the sort of person who reads version numbers off asset URLs: judge the version from the plugin’s own frontend.min.js or frontend.min.css ?ver= value, which is the ProfilePress version. Do not read it off the bundled select2/select2.min.css, whose ?ver= (for example 7.0.2) is the select2 library’s own version and has nothing to do with the plugin version.

Then apply this rule, and note that versions compare numerically, not alphabetically:

  • 3.0.0 through 4.16.17: potentially affected (subject to the registration-form question above), update now.
  • 4.16.18 or newer: already fixed. This includes the current 4.16.19 release.
  • Older than 3.0: not affected by this issue. The vulnerable registration handler first shipped with the ProfilePress 3.0 rebrand; the earlier avatar-only “WP User Avatar” 1.x and 2.x line had no registration feature and does not carry it. (In practice, essentially every current install is a 4.16.x release.)

How to upgrade

The safest path is to update through WordPress itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a WordPress backup plugin.
  2. In the WordPress admin, go to Dashboard then Updates, or Plugins then Installed Plugins. If a ProfilePress update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update wp-user-avatar (the command uses the folder name, wp-user-avatar).
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, ProfilePress, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (4.16.18 or later; the current release is 4.16.19) using the steps above, and check that your registration and login pages work normally.

While you are in there, it is worth confirming that WordPress core and your other plugins are up to date, since the same principle applies to all of them.

After updating

Updating to 4.16.18 or later closes the issue, and for most sites that is the whole task. There is no indication this flaw has been exploited anywhere, so no emergency response is implied: you do not need to treat your site as compromised or take it offline.

One follow-up is worth considering, and it is conditional on the same registration question. If your site was publishing a ProfilePress registration form with a role-selection field while on an affected version, then it was at least theoretically possible for a visitor to have registered at a higher role than intended, even though there is no evidence anyone did so. In that case, a single routine precaution is sensible:

  • Have a look over your recent user registrations for any account created at an unexpectedly high role (for example an Editor or Author you do not recognise), in the ordinary way you would review site activity, and adjust or remove anything that looks out of place.

Treat this as ordinary security housekeeping, not incident response. If you do not offer public self-registration with a role-selection field, updating alone is enough.

What I did and did not do

To be fully transparent about the check behind my email: I only read public files that your site already serves to every visitor, specifically the plugin’s public readme.txt file and your homepage. I did not access your WordPress admin area, your database, or any private part of the site. In particular, I did not touch the vulnerable registration path, and I did not test or exploit anything.

This is a version-based observation: your site reports a version in the affected range. Because this issue is configuration-dependent, a site in that range may not be exposed at all (if it offers no public self-registration, or its forms carry no role-selection field), and it may also already be mitigated by other means, such as a web application firewall. This notice is not a statement that your site was exploitable at the time I checked.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / plugin