A 61-character username can take over a WordPress site

A username 61 characters long was all it took. On a WordPress site running the User Profile Builder plugin with automatic login switched on, registering with an over-long username handed the visitor a logged-in session on the site's original administrator account, with no password and no email confirmation.

The bug is rated 9.8 out of 10 on the CVSS severity scale and affects every version of the plugin up to and including 3.16.4. User Profile Builder, built by Cozmoslabs, runs on more than 40,000 WordPress sites, where it supplies the front-end registration, login and profile forms that membership sites, clubs and small communities depend on. Cozmoslabs shipped the fix, version 3.16.5, on 16 July 2026. Wordfence published the full technical account, tracked as CVE-2026-15826, on 14 August.

The flaw was found by Supakiad S., who uses the handle m3ez, and reported through the Wordfence Bug Bounty Program, which paid 975 dollars for it. Wordfence's Istvan Marton wrote up the original report.

An error object that quietly became the number 1

The plugin's registration form accepts usernames of up to 70 characters, and its own validation only checks that the name is unique and passes WordPress core's format rules. Core itself rejects any username longer than 60 characters. That leaves a gap. A username of 61 to 70 characters clears the plugin's checks and then fails inside WordPress, so the wp_insert_user() call returns an error object instead of a new user ID.

The plugin does not treat that as a failed registration. In vulnerable versions it runs the returned value through absint(), the PHP helper that coerces a value to a positive integer, before it checks whether the value is an error at all. absint() turns the error object into the integer 1. The error check therefore passes, and on a standard WordPress install user ID 1 is the first account ever created, which is normally the owner's administrator account. That is the type confusion at the heart of this: an error was mistaken for an identity.

From there the plugin does what it would do after any successful signup. It generates an autologin nonce, stores it against user ID 1, and returns a URL carrying that nonce. Requesting the URL makes the plugin look the nonce up and set an authentication cookie for the bound user, so the attacker arrives at the site as its administrator. Wordfence notes the usual consequences of full admin access: more administrator accounts, a backdoored plugin or theme, altered content, or the site's data walking out.

Two settings decide whether your site was exposed

Not every install was at risk. Exploitation needs the plugin's documented Automatically Log In after Registration setting to be enabled, the option that signs a new user in immediately instead of waiting on an email confirmation. Wordfence also stresses that the flaw only critically affects sites where the account holding user ID 1 is still an administrator. That is the default on a fresh WordPress install, but not universal on sites that have been migrated, rebuilt or handed between agencies.

Update to 3.16.5, and check who user 1 is

The fix has been available since 16 July, one day after Wordfence sent the vendor full disclosure details, and Cozmoslabs acknowledged and patched on the same day it was notified. Sites on 3.16.4 or older should update now. Anyone who cannot update immediately should turn the automatic login option off, then review the administrator account list and recent registrations for accounts they did not create. Wordfence pushed a firewall rule to its paying customers on 15 July and to free users on 14 August, the 30-day gap it applies to all of its bug bounty findings.

Authentication bypasses like this one are the quiet end of the WordPress ecosystem's problem. No exploit chain, no memory corruption, just two checks that ran in the wrong order. Wordfence counted 249 plugin and theme flaws in a single week earlier this month, and a comparable takeover bug in the WPMU DEV Dashboard plugin surfaced days before that. The difference between a patched site and a compromised one here is a version number that has been sitting in the updates screen for a month.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions