If you received an email from me pointing you to this page, it is because your website appears to be running a version of Profile Builder (the WordPress plugin listed on WordPress.org as “Profile Builder” / “User Profile Builder”, by Cozmoslabs, which lives in your files at /wp-content/plugins/profile-builder/) 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, how to read your version without being misled, and how to update.

Please note: this is not ProfilePress. There is a different WordPress plugin with a similar name (ProfilePress, folder wp-user-avatar), and I write about that one separately. If your plugin folder is wp-user-avatar rather than profile-builder, this page is not the one you want; see the ProfilePress notice instead. Everything below concerns Cozmoslabs’ Profile Builder only.

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 below only comes into play on sites that have switched on one specific setting, and I cannot see your settings from outside:

  • Profile Builder’s “Automatically Log In” option, which logs a new user straight in after they complete registration, has to be enabled.
  • That option is off by default. A site that has never turned it on is not exposed to this issue, even on an affected version.

I can read your plugin version from a public file, but I cannot read your configuration, so this notice is a precautionary heads-up rather than a confirmed finding about your site.

The issue is CVE-2026-15368, an unauthenticated account takeover in the plugin’s automatic-login step. It affects versions 2.1.4 through 3.16.3 and is fixed in 3.16.4. If you are running an affected version, update Profile Builder to 3.16.4 or later. It carries a CVSS score of 8.1. I am not aware of any public exploit code for it.

A word on urgency, because this is a conditional notice. If you do not use automatic login after registration, updating is ordinary plugin maintenance. If you do, please treat the update as a priority: in that configuration the flaw could let a visitor with no account at all obtain a logged-in session belonging to an existing user whose email address they know, including an administrator, which would hand over control of the site.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Profile Builder 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, register on it, 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. I specifically did not submit your registration form, did not create an account, and did not go near the automatic-login step. 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

Profile Builder adds front-end registration, login and profile-editing forms to a WordPress site, so visitors can sign up and manage their own accounts without ever seeing the admin area. One of its conveniences is the option to log a new user in automatically the moment their registration completes, saving them from typing their password again on a separate login form.

In affected versions, that convenience decided which account to log in the wrong way. Instead of using the account it had just created, the plugin looked up an account by the email address that had been typed into the registration form, and logged that one in. If the address submitted belonged to somebody who already had an account on the site, the person filling in the form was handed a logged-in session for that existing account.

Two things follow from that, and they pull in opposite directions. The first is that this only happens where automatic login is switched on. With the setting off, the plugin never starts the automatic-login step at all, so a site in that state is not reachable through this issue. The second is that where the setting is on, nothing limits the consequence to ordinary members: the account that gets handed over is whichever one matches the address that was submitted, and an administrator’s address is usually not a secret. No account, no password and no cooperation from the victim is required.

I am describing this at the level a site owner needs in order to act, and no further. I am not publishing the details that would let someone reproduce it, and I would ask you not to try it against your own site or anyone else’s. Reading your setting and your version number, as described below, tells you everything you need to decide what to do.

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 settings are configured. All I observed is the version.

Am I affected?

Two questions decide it, in this order.

First: is “Automatically Log In” switched on?

This is the deciding question, and only you can answer it. Checking your own settings is entirely safe and is the whole point of this page.

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Open the Profile Builder menu in the sidebar, then go to Settings.
  3. Look for the toggle labelled Automatically Log In, described as “Enable to automatically log in new users after successful registration”.
  • If that toggle is off, this issue does not reach your site, even on an affected version. Updating is still worth doing as ordinary maintenance.
  • If it is on, the issue applies to you, and you should update promptly.

One extra place to look, if you have more than one registration page: an individual page holding a Profile Builder register form can carry its own copy of that setting, which overrides the global one. If you maintain several registration pages, it is worth checking each of them rather than relying on the global toggle alone.

Please do not try to reproduce the problem against your own site or anyone else’s, and you do not need to in order to answer the question above.

Second: which version are you running?

You do not have to take my word for it. For this plugin there is one specific way of checking that will mislead you, so it is worth reading this part carefully.

From the WordPress admin area (authoritative):

  1. In your WordPress dashboard, go to Plugins then Installed Plugins.
  2. Find Profile Builder, the entry whose folder is profile-builder, and note the version shown beneath its name.

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

From your page source (no login needed): view the source of a page on your site that shows a Profile Builder form, and look for the plugin’s front-end stylesheet at exactly this path:

/wp-content/plugins/profile-builder/assets/css/style-front-end.css?ver=...

The ?ver= number attached to that one file is the plugin’s own version. For this plugin it tracks the release exactly, which is why I treat it as a dependable second reading.

The trap to avoid here, and it is an easy one to fall into. Profile Builder ships other components inside its own plugin folder, and they carry their own, unrelated version numbers. The bundled user-profile-picture add-on under add-ons-free/user-profile-picture/ has sat at 2.6.0 across several Profile Builder releases without moving, and there is a bundled Divi integration under assets/misc/divi/ numbered 1.0.0. Both of those numbers look alarmingly old next to 3.16.4, and neither one says anything at all about this issue. If you are reading a version out of your page source, make sure the file path you are reading it from is assets/css/style-front-end.css and nothing else.

Then apply this rule, and note that versions compare numerically, not alphabetically, so 3.10.0 is newer than 3.9.9 even though it looks smaller as text. This plugin really does run every release line from .0 through .9 before rolling over, so that distinction matters here:

  • 2.1.4 through 3.16.3: potentially affected, subject to the setting question above. Update now.
  • 3.16.4 or newer: already fixed as far as this issue is concerned. The current release at the time of writing is 3.16.6, and taking the latest available version is the best move.
  • Older than 2.1.4: not affected by this issue. The specific mistake described above was introduced in 2.1.4, so genuinely older installs are outside its range. That said, a release that old is many years behind on everything else, and updating is worth doing on general grounds.

If you cannot get a readable version out of any of the three checks above, that is common with this plugin and is not a sign of anything: the stylesheet is only loaded on pages that actually render one of its forms, and caching or optimisation plugins routinely strip the ?ver= value. The admin screen in step one always has the answer.

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 Profile Builder update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update profile-builder (the command uses the folder name).
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Profile Builder, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (3.16.4 or later) using the steps above, and check that your registration, login and edit-profile forms still work normally.

If you run any of Cozmoslabs’ paid Profile Builder add-ons, update those alongside the core plugin, since their releases are usually paired.

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 3.16.4 or later closes the issue, and for most sites that is the whole task. This page is a precautionary notice, not an incident report: I have no visibility into whether anything happened on your site, and I did not look.

One follow-up is worth considering, and it is conditional on the same setting question. If your site had Automatically Log In enabled while running an affected version, then it was at least theoretically possible for someone to have been handed a session on an existing account. Updating closes the hole, but it does not undo access that was already taken, so in that case a few routine precautions are sensible:

  • Review your administrator accounts and any other accounts that matter, for entries you do not recognise, email addresses that are no longer the right person’s, or role changes you did not make.
  • Look over recent logins and any currently active sessions for anything you cannot account for.
  • Reset the passwords on your administrator accounts. Regenerating WordPress’s secret keys and salts in wp-config.php is a sensible companion step (new values are one click away at the official secret-key generator, and swapping them signs every user out once).

If you find something that concerns you, treating it as you would any other suspected unauthorized access is the right response. If your site never had automatic login enabled, updating alone is enough.

What I did and did not do

To be fully transparent about the check behind my email: I only read files that your site already serves to every visitor, specifically the plugin’s public readme.txt, your homepage, and the asset addresses written into that page. I did not access your WordPress admin area, your database, or any private part of the site.

In particular, I never submitted your registration form, never created an account, and never touched the automatic-login step. Nothing was submitted, tested, or exploited. That matters more here than on most of these pages, because registering is the exact action this issue concerns, so “I did not touch it” is the whole difference between a disclosure and an intrusion.

I am also deliberately not publishing the details that would help someone act on this issue. The description above stops at the level a site owner needs, and I do not link any proof-of-concept code.

This is a version-based observation: your site reports a version in the affected range. It is not a statement that your site was exploitable at the time I checked. Because the issue depends on a setting I cannot see, a site in that range may well not be exposed at all, and a site in that range may separately be protected by other means such as a web application firewall or a backported fix.

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