General Information
Error Code Description
This error is displayed when there is an issue creating user in WordPress.
Solution
There has been some issue with user creation in WordPress. Copy the error message and reach out to us at samlsupport@xecurify.com with your registered email.
WPSAMLERR005 – User Creation Failed after updating to 6.0.0
Short version: The plugin used to match SSO logins against WordPress accounts by username and email. It now matches on one criterion only — Email by default, configurable to Username. If no account matches that single criterion, the plugin tries to create a new account, and WPSAMLERR005 appears when the username it would create is already taken.
What changed
| Before the update | After the update | |
|---|---|---|
| Matching criteria | Username first, then email | One criterion only |
| Which criterion | Both, in order | Whatever User Matching Preference is set to |
| Default | Username took priority |
If Username was already configured on your site, the update keeps that setting. Everyone else gets Email.
Why the change was made
Under the old behavior, a username match alone was enough to log an SSO user into an existing WordPress account — even when the email address and every other attribute belonged to someone else. Usernames are not guaranteed to be unique or trustworthy at the Identity Provider (IdP), so this could let one user reach another user's WordPress account.
Matching on a single, explicitly configured criterion removes that path. This is a security fix, which is why the behavior changed without an opt-in.
What User Matching Preference does
This setting decides which piece of information the plugin uses to find the WordPress account during SSO login.
SAML SSO Plugin → Attribute Mapping → User Matching Preference
- Email (default) – the account is looked up by email address
- Username – the account is looked up by username
Only one option can be active, and the setting saves automatically.
Where Username and Email come from
Free version: both the Username and Email fields under Attribute Mapping use the NameID from the SAML response. So whichever preference you pick, the plugin compares the same NameID value against that WordPress field.
If the IdP sends NameID: john@example.com:
- With Email selected, the plugin looks for a WordPress user whose email is john@example.com.
- With Username selected, the plugin looks for a WordPress user whose username is literally john@example.com.
Paid plans: Username and Email can be mapped to different SAML attributes, so they no longer have to come from the same value. Everything below still applies — just read "the mapped attribute" wherever this article says NameID.
Why you're seeing WPSAMLERR005
The error appears when all three of these are true:
- No WordPress user matches the incoming value on the configured criterion (by default, email),
- so the plugin attempts to create a new WordPress account,
- but the username it would create already belongs to another WordPress user.
WordPress cannot create a duplicate username, so account creation fails.
This most often affects users who could log in before the update. Their login was working because of the old username-first fallback — the plugin was reusing an existing account on a username match that the new logic no longer accepts.
How to fix it
- Find out what your IdP actually sends as NameID. Check the SAML response for the affected user, or your IdP's NameID configuration.
- Compare it against the existing WordPress user. Look at both the WordPress username and the email address on that account.
- Set User Matching Preference to match reality:
| IdP sends as NameID | Your WordPress users are identified by | Select |
|---|---|---|
| Email address | Email address | Email (default) |
| Username | Username | Username |
| Email address, and usernames are also emails | Either | Email – safer, since emails are unique in Identity Provider |
- If the preference is already correct, align the data. The error means the incoming value genuinely doesn't match the account. Either update the WordPress user's email/username so it matches what the IdP sends, or change what the IdP sends.
- If the conflicting username belongs to a different person, stop and investigate. This is the case the security fix was designed to catch. Before the update, that login would have silently landed in the other person's account.
Do I need to change anything after updating?
No — the fix applies on its own, and no configuration is required for it to take effect. Act only if users report WPSAMLERR005, using the steps above.
Should I update?
Yes. Update to the latest version so the corrected identification behavior and the associated security improvement are applied.
