The WP OAuth Server (OAuth Authentication) WordPress plugin before 3.4.2 does not have CSRF check when regenerating secrets, which could allow attackers to make logged in admins regenerate the secret of an arbitrary client given they know the client ID

The WP OAuth Server (OAuth Authentication) WordPress plugin before 4.2.2 does not sanitize and escape Client IDs, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

The OAuth Client by DigitialPixies WordPress plugin through 1.1.0 does not sanitize and escapes some of its settings, which could allow high-privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example, in multisite setup).

The OAuth Client by DigitialPixies WordPress plugin through 1.1.0 does not have CSRF checks in some places, which could allow attackers to make logged-in users perform unwanted actions.

The OAuth client Single Sign On WordPress plugin before 3.0.4 does not have authorisation and CSRF when updating its settings, which could allow unauthenticated attackers to update them and change the OAuth endpoints to ones they controls, allowing them to then be authenticated as admin if they know the correct email address

Authentication Bypass vulnerability in miniOrange WP OAuth Server plugin <= 3.0.4 at WordPress.

Authentication Bypass vulnerability in miniOrange OAuth 2.0 client for SSO plugin <= 1.11.3 at WordPress.

The OAuth Single Sign On WordPress plugin before 6.22.6 doesn't validate that OAuth access token requests are legitimate, which allows attackers to log onto the site with the only knowledge of a user's email address.

ApiFest OAuth 2.0 Server 0.3.1 does not validate the redirect URI in accordance with RFC 6749 and is susceptible to an open redirector attack. Specifically, it directly sends an authorization code to the redirect URI submitted with the authorization request, without checking whether the redirect URI is registered by the client who initiated the request. This allows an attacker to craft a request with a manipulated redirect URI (redirect_uri parameter), which is under the attacker's control, and consequently obtain the leaked authorization code when the server redirects the client to the manipulated redirect URI with an authorization code. NOTE: this is similar to CVE-2019-3778.

The vulnerability is that IDToken verifier does not verify if token is properly signed. Signature verification makes sure that the token's payload comes from valid provider, not from someone else. An attacker can provide a compromised token with custom payload. The token will pass the validation on the client side. We recommend upgrading to version 1.33.3 or above