Description

The WP OAuth Server ( Login with WordPress ) WordPress plugin before 6.4.0 does not bind the OpenID Connect identity assertion it issues to the authorization grant being exchanged, returning instead the assertion belonging to whichever user authenticated most recently, which allows users with the Subscriber role and above to obtain a validly signed identity assertion for another user, including an administrator, and authenticate as them at any application that uses the site for single sign-on.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.0",
  "pubDate": "2026-09-23T06:17:02.363Z",
  "pubdate": "2026-09-23T06:17:02.363Z",
  "executiveSummary": "The WP OAuth Server (Login with WordPress) plugin prior to version 6.4.0 contains a critical logic vulnerability related to OpenID Connect identity assertion handling.\nThe vulnerability involves an improper binding of identity assertions to authorization grants, leading to an authentication bypass.\nAn attacker with at least Subscriber-level privileges can manipulate the authorization flow to receive a validly signed ID token belonging to another user, including administrators.\nThis allows for unauthorized account takeover across any application utilizing the affected site as an identity provider for Single Sign-On (SSO).\nThe flaw stems from the plugin returning the most recently authenticated user's identity assertion rather than the assertion specifically associated with the requested authorization grant.\nThis represents a high-risk security failure that compromises the integrity of the authentication process and the confidentiality of user accounts.",
  "technicalDetails": "The root cause of this vulnerability is a design flaw in the OpenID Connect (OIDC) implementation within WP OAuth Server. Specifically, the plugin fails to enforce cryptographic or session-based binding between an issued authorization grant and the subsequent identity assertion (ID token).\nIn a secure OIDC implementation, the identity assertion must be strictly scoped to the specific authorization code and user session initiated by the client. In the vulnerable versions, the system retrieves the identity assertion based on global state (the most recently authenticated user) rather than contextual state (the specific user associated with the authorization grant).\nThe attack flow proceeds as follows: First, the attacker initiates an OIDC authorization flow via the plugin. Concurrently, the attacker triggers an authentication event on the WordPress site—or waits for an administrator to authenticate—which updates the 'most recently authenticated user' state within the plugin's session handling logic. When the attacker completes the authorization grant exchange, the plugin incorrectly issues an identity assertion for the last user who authenticated rather than for the attacker's own session.\nBecause the ID token is validly signed by the WP OAuth Server, the relying party (the external application) accepts the assertion as legitimate. This allows the attacker to successfully authenticate as the targeted victim (e.g., an administrator) at any third-party application integrated via this SSO provider.\nThe vulnerability requires the attacker to have at least a Subscriber-level account on the WordPress installation, enabling them to trigger the necessary requests to the OAuth endpoints. No specialized administrative privileges are required on the target server, only the ability to interact with the plugin's authorization flow. The impact is a complete authentication bypass and account takeover at any service trusting the affected WordPress instance as an Identity Provider (IdP).\nThe flaw affects all versions of the WP OAuth Server plugin prior to 6.4.0. The lack of validation ensures that the assertion provided to the client is decoupled from the actual authorization request, effectively rendering the identity verification process insecure."
}