Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Drupal OAuth & OpenID Connect Single Sign On – SSO (OAuth/OIDC Client) allows Cross-Site Scripting (XSS).This issue affects OAuth & OpenID Connect Single Sign On – SSO (OAuth/OIDC Client): from 3.0.0 before 3.44.0, from 4.0.0 before 4.0.19.

Guzzle OAuth Subscriber signs Guzzle requests using OAuth 1.0. Prior to 0.8.1, Nonce generation does not use sufficient entropy nor a cryptographically secure pseudorandom source. This can leave servers vulnerable to replay attacks when TLS is not used. This vulnerability is fixed in 0.8.1.

The OAuth Single Sign On – SSO (OAuth Client) plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 6.26.3. This is due to insufficient verification on the user being returned by the social login token. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the username and the user does not have an already-existing account for the service returning the token.

In the OAuth library for nim prior to version 0.11, the Authorization Code grant and Implicit grant both rely on the `state` parameter to prevent cross-site request forgery (CSRF) attacks where a resource owner might have their session associated with protected resources belonging to an attacker. When this project is compiled with certain compiler flags set, it is possible that the `state` parameter will not be checked at all, creating a CSRF vulnerability. Version 0.11 checks the `state` parameter using a regular `if` statement or `doAssert` instead of relying on a plain `assert`. `doAssert` will achieve the desired behavior even if `-d:danger` or `--assertions:off` is set.

In the OAuth library for nim prior to version 0.11, the `state` values generated by the `generateState` function do not have sufficient entropy. These can be successfully guessed by an attacker allowing them to perform a CSRF vs a user, associating the user's session with the attacker's protected resources. While `state` isn't exactly a cryptographic value, it should be generated in a cryptographically secure way. `generateState` should be using a CSPRNG. Version 0.11 modifies the `generateState` function to generate `state` values of at least 128 bits of entropy while using a CSPRNG.

OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. This worked fine prior to JupyterHub 5.0, because `allow_all` did not take precedence over `identity_provider`. Since JupyterHub 5.0, `allow_all` does take precedence over `identity_provider`. On a hub with the same config, now all users will be allowed to login, regardless of `identity_provider`. `identity_provider` will basically be ignored. This is a documented change in JupyterHub 5.0, but is likely to catch many users by surprise. OAuthenticator 16.3.1 fixes the issue with JupyterHub 5.0, and does not affect previous versions. As a workaround, do not upgrade to JupyterHub 5.0 when using `GlobusOAuthenticator` in the prior configuration.

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in WP OAuth Server OAuth Server.This issue affects OAuth Server: from n/a through 4.3.3.

OAuthenticator provides plugins for JupyterHub to use common OAuth providers, as well as base classes for writing one's own Authenticators with any OAuth 2.0 provider. `GoogleOAuthenticator.hosted_domain` is used to restrict what Google accounts can be authorized access to a JupyterHub. The restriction is intented to be to Google accounts part of one or more Google organization verified to control specified domain(s). Prior to version 16.3.0, the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023). OAuthenticator 16.3.0 contains a patch for this issue. As a workaround, restrict who can login another way, such as `allowed_users` or `allowed_google_groups`.

An issue was discovered in ownCloud owncloud/oauth2 before 0.6.1, when Allow Subdomains is enabled. An attacker is able to pass in a crafted redirect-url that bypasses validation, and consequently allows an attacker to redirect callbacks to a Top Level Domain controlled by the attacker.

light-oauth2 before version 2.1.27 obtains the public key without any verification. This could allow attackers to authenticate to the application with a crafted JWT token.