WP OAuth Server CVE-2026-82843

The site must run WP OAuth Server (before 6.4.0) as an OpenID Connect / single sign-on identity provider for one or more relying applications. The attacker must already hold a valid account at Subscriber role or above on that WordPress site (PR:L). Exploitation depends on a timing condition: because the plugin returns the identity assertion of whichever user authenticated most recently rather than the assertion bound to the attacker's own grant, the attacker must perform their token exchange while a higher-privileged user (e.g., an administrator) is the most-recently-authenticated identity - a race/interaction window (UI:R). Limiting factors: a valid low-privilege account is required, the deployment must actually use the plugin for OIDC SSO, and the attacker cannot fully control when a targeted admin authenticates.

This is a genuinely high-severity identity-confusion/account-takeover flaw, and the signals are internally consistent. The CVSS 9.0 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H) reflects a network-reachable OIDC identity-provider bug where a low-privileged Subscriber can obtain a validly signed identity assertion for an administrator and then log in as them at any relying application - the S:C (scope change) correctly captures that the real damage lands on downstream SSO applications, not just the WordPress site. The core weakness (the issued OIDC assertion is not bound to the authorization grant being exchanged, so it returns whoever authenticated most recently) implies a timing/race dependency; I would argue AC:H rather than the vendor's AC:L, since the attacker must exchange their grant while a higher-privileged user's assertion is the 'most recent'. No EPSS score, no CISA KEV listing, and no public exploit code are provided in the input, so despite the 9.0 this is not confirmed to be under active or widespread exploitation. The correct posture: treat as a real priority for any site running WP OAuth Server as an SSO IdP (auth-bypass-to-admin is high impact and a patch exists), while noting exploitation requires a foothold account plus a timing window, which tempers real-world mass-exploitation likelihood.

An attacker registers or acquires a Subscriber-level account on a WordPress site that uses WP OAuth Server as its OpenID Connect single sign-on identity provider. They initiate an OIDC authorization/token exchange timed so the plugin returns the identity assertion of the most-recently-authenticated user (an administrator), receive a validly signed assertion for that admin, and present it to a relying application to authenticate as the administrator. No public exploit code is identified in the provided data; the WPScan advisory is the sole source.