CVE-2026-104759: WPO365 | SEAMLESS WORDPRESS + MICROSOFT INTEGRATION (WPO365 | LOGIN) <= 44.1 - Unauthenticated Authentication Bypass via OIDC Nonce Replay via id_token Nonce Verification
The WPO365 | SEAMLESS WORDPRESS + MICROSOFT INTEGRATION (WPO365 | LOGIN) plugin for WordPress is vulnerable to Authentication Bypass via OIDC Nonce Replay in all versions up to, and including, 44.1 This is due to IdTokenServiceDeprecated::processopenidconnecttoken() using the incompatible WordPress core wpverifynonce() function to validate a nonce produced by NonceService::createnonce() — a 64-character hex value that wpverifynonce() can never successfully verify — causing the nonce check to silently fail without terminating authentication, so execution continues into authenticateoidcuser() with the attacker-supplied idtoken. This makes it possible for unauthenticated attackers who have obtained a previously-issued, valid idtoken for a target account to replay that token and authenticate as any WordPress user, including administrators, resulting in full site takeover. This vulnerability is only exploitable when the useidtokenparserv2 plugin option is enabled, as this is the configuration that routes token processing through the deprecated parser containing the broken nonce check.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable the use_id_token_parser_v2 plugin option to prevent token processing from using the deprecated parser with the broken nonce check.
WPO365 | SEAMLESS WORDPRESS + MICROSOFT INTEGRATION (WPO365 | LOGIN) use_id_token_parser_v2 = false
Event History
Frequently Asked Questions
Which deployments are exposed to exploitation?
Deployments running WPO365 | LOGIN version 44.1 or earlier are exposed only if the use_id_token_parser_v2 plugin option is enabled. That setting routes OIDC token handling through the deprecated parser with the failed nonce validation.
What does an attacker need to exploit this issue?
An unauthenticated attacker needs a previously issued, valid id_token for the WordPress account they want to impersonate. They can replay that token to authenticate as that user, including an administrator.
Is the vulnerable behavior enabled by default?
The available data does not state the default value of use_id_token_parser_v2. Exploitability depends on whether that option is enabled in the affected deployment.
How can I determine whether my site is affected?
Check whether the site uses WPO365 | LOGIN version 44.1 or earlier and whether its use_id_token_parser_v2 option is enabled. Both conditions must be present for the described exploit path.