Last updated: August 22, 2026
The User Profile Builder vulnerability CVE-2026-15826 is a critical authentication bypass rated CVSS 9.8 that lets an unauthenticated attacker log in as the site administrator. It affects versions up to and including 3.16.4 of the Cozmoslabs plugin, was fixed in 3.16.5 on July 16, 2026, and exposes more than 40,000 sites.
What is the User Profile Builder vulnerability?
It is a type confusion flaw, classified as CWE-704 (incorrect type conversion), in the plugin’s registration and automatic-login workflow. When account creation fails, the plugin misreads the error object as user ID 1 and issues an authentication token for that account — which on most WordPress sites is the original administrator.
| Detail | Value |
|---|---|
| CVE | CVE-2026-15826 |
| CVSS score | 9.8 (critical) |
| Weakness | CWE-704 incorrect type conversion or cast |
| Plugin | User Profile Builder (Cozmoslabs) |
| Affected versions | All versions ≤ 3.16.4 |
| Patched version | 3.16.5, released July 16, 2026 |
| Sites exposed | 40,000+ |
| Authentication required | None |
The disclosure timeline was unusually fast. Wordfence received the report on July 14, 2026, validated it on July 15, and Cozmoslabs shipped the patch on July 16 — a two-day turnaround. Public reporting followed on August 17, 2026, giving site owners a month of quiet patching before details went wide.
How does a type confusion bug hand over an admin account?
The plugin’s wppb_log_in_user() function calls absint() on the return value of wp_insert_user() before checking it with is_wp_error(). When registration fails, wp_insert_user() returns a WP_Error object. Casting an object to an integer in PHP produces 1 — so the failure silently becomes “user ID 1”.
This is worth sitting with, because it is a mistake any WordPress developer can make. The order of two lines is the entire vulnerability:
// Vulnerable pattern: cast first, check later
$user_id = absint( wp_insert_user( $userdata ) );
if ( is_wp_error( $user_id ) ) { // never true - it is an int now
return;
}
wp_set_auth_cookie( $user_id ); // $user_id === 1 on failure
// Correct pattern: check first, then cast
$result = wp_insert_user( $userdata );
if ( is_wp_error( $result ) ) {
return;
}
$user_id = absint( $result );So the attack is simply: submit a registration that is guaranteed to fail — for example, reusing an existing username — on a site where automatic login after registration is enabled. The plugin then logs the attacker in as user ID 1. No password, no token theft, no brute force.
Which sites are actually at risk?
Two conditions must both be true: the “Automatically Log In after Registration” setting is enabled, and user ID 1 is an account with administrator privileges. Sites that disable auto-login, or that have retired the original user ID 1 admin, are not exploitable even on a vulnerable version.
Check both in about a minute:
# Is the plugin on a vulnerable version?
wp plugin get profile-builder --field=version
# Who is user ID 1, and are they an administrator?
wp user get 1 --fields=ID,user_login,rolesThen open Profile Builder → Settings and look at “Automatically Log In after Registration”. If it is on, you have the second condition. Turning it off is a legitimate emergency mitigation if you genuinely cannot update today — but it is a workaround, not a fix.
How do I fix the User Profile Builder vulnerability?
Update User Profile Builder to 3.16.5 or later. The patch has been available since July 16, 2026 and fully resolves the type confusion. After updating, audit your administrator accounts, because a successful exploit before patching would leave no failed-login trace in your logs.
- Update the plugin:
wp plugin update profile-builder. - Confirm the installed version is 3.16.5 or higher.
- List every administrator and verify you recognise each one — including any hidden from the Users screen.
- Force a password reset on all admin accounts and revoke application passwords.
- Rotate the salts in
wp-config.phpto invalidate any session an attacker established. - Review recent posts, plugins and users for changes you did not make.
Step 5 matters more than it looks. Because the exploit produces a valid authentication cookie, an attacker who used it before you patched keeps that session until the salts change. Updating the plugin does not log them out.
Why is user ID 1 such a common target?
Because it is predictable. WordPress assigns ID 1 to the first account created during installation, and on the overwhelming majority of sites that account is still an administrator. Any bug that leaks or defaults to an integer user ID lands on an admin account far more often than chance would suggest.
This vulnerability is a clean illustration: the flaw does not target user ID 1 deliberately. It just casts an object to an integer, gets 1, and that happens to be the owner of the site. A useful hardening step is to create a second administrator, move your real work there, and demote or remove the original ID 1 account.
It is not a substitute for patching, and it will not stop a targeted attacker who enumerates users properly. It does remove your site from the default case that a whole class of bugs lands on. For the broader hardening picture, see our guide to the best WordPress security plugins and our overview of WordPress security in 2026.
Frequently asked questions
Which version fixes CVE-2026-15826?
User Profile Builder 3.16.5, released July 16, 2026. All versions up to and including 3.16.4 are vulnerable. The fix corrects the order of the error check so a failed registration can no longer be read as user ID 1.
Was this vulnerability exploited in the wild?
No active exploitation was reported in the coverage published on August 17, 2026. The patch preceded public disclosure by a month, which meaningfully reduces exposure — but only for sites that applied it.
Can I just disable automatic login instead of updating?
It removes one of the two required conditions, so it is a valid stopgap for a few hours. It is not a fix. The vulnerable code stays in place, and anyone who re-enables the setting later silently reopens the hole.
How would I know if someone already used this against my site?
There is no failed-login record, because the attacker never fails a login — they are handed a valid session. Look instead for unexplained content or settings changes, new plugins, new admin accounts, and active sessions you do not recognise. Rotating salts ends any session that already exists.
Leave a Reply