Oauth2
Monthly
Unauthenticated remote attackers can steal OAuth2 authorization codes from smart-sso deployments running version 2.1.1 or earlier by abusing an unvalidated redirectUri parameter in the /login handler (CWE-601). A victim who already holds an active SSO session must be induced into opening a crafted /login link, after which the attacker - who must additionally hold any valid OAuth2 client credentials - redeems the leaked code at /oauth2/access_token to obtain the victim's access token, giving both high confidentiality and integrity impact (CVSS 7.6 v4.0: AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N; independent assessment CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N). Exploitation is conditional rather than trivial: it fails if the victim has no active session, does not click the link, or if the attacker lacks valid client credentials, though no authentication to the SSO server itself is required (PR:N). No public exploit identified at time of analysis, although a public technical writeup describing the authorization-code leak path has been published; this is a genuine but conditional risk rather than a drop-everything emergency.
OAuth2 client secret disclosure in the RabbitMQ Management UI affects versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2, where the configured management.oauth_client_secret is embedded in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js. Any party with network reachability to the management HTTP port can retrieve the secret with a simple GET request - authentication requirements confirmed unauthenticated (CVSS:3.1 AV:N/AC:L/PR:N/UI:N) and the assessed impact is high confidentiality loss (VC:H) with no integrity or availability impact. The flaw only manifests when OAuth2 authentication is enabled for the Management UI and the IdP flow uses a confidential client secret, so default or non-OAuth2 deployments are unaffected; no public exploit code has been identified at time of analysis, and the issue is fixed in 4.3.3 and 4.2.9.
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauthenticated remote attackers obtain a session for another user's account by linking their own OAuth2 provider identity to an account that was matched on an attribute other than email, and the same upsert rewrites the victim's email to the attacker's address so subsequent account recovery flows reach the attacker. Exploitation is conditional: the application must configure the OAuth2/Auth0/Apple strategy with a register-action upsert_identity that matches existing accounts on a non-email attribute, or use the registration_enabled? false sign-in path where accounts are matched by the sign-in action's read filter, and the attacker only needs control of a provider identity whose email_verified claim is true. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Bearer token leak in the OAuth2 Ruby gem (ruby-oauth/oauth2) versions 0.4.0 through 2.0.
Expired OAuth2 JWT access tokens are accepted indefinitely by RabbitMQ 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 when the rabbitmq_auth_backend_oauth2 backend is enabled and the identity provider emits the JWT 'exp' claim as a fractional (float) JSON number rather than an integer. Because the Erlang code guards expiry parsing with is_integer(Exp), both the login-time expiry check and the mid-connection disconnect timer silently fall through for float exp values, so an attacker holding a previously issued, correctly signed token can authenticate with it long after it has expired and keep connections open without being disconnected. The CVSS 4.0 base score is 6.3, but exploitability is sharply conditional - a non-default IdP behavior plus possession of a valid signed token - and no public exploit code has been identified at time of analysis; the issue is fixed in RabbitMQ 4.2.9 and 4.3.3.
Denial of service via atom exhaustion in RabbitMQ Server when the rabbitmq_auth_backend_oauth2 plugin is enabled and configured with an identity provider that allows user-influenced scope values in signed JWTs. Affected versions include 3.13.0 through 3.13.14, 4.0.x before 4.0.22, 4.1.x before 4.1.11, 4.2.x before 4.2.6, and 4.3.x before 4.3.1. Exploitation requires valid signed tokens bearing novel 'tag:' scope values across many repeated logins, and no public exploit code has been identified at time of analysis; independent assessment rates real-world risk as low due to the non-default plugin, permissive IdP dependency, and high volume of authentications needed.
An issue was discovered in ownCloud owncloud/oauth2 before 0.6.1, when Allow Subdomains is enabled. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
All versions of @fastify/oauth2 used a statically generated state parameter at startup time and were used across all requests for all users. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Unauthenticated remote attackers can steal OAuth2 authorization codes from smart-sso deployments running version 2.1.1 or earlier by abusing an unvalidated redirectUri parameter in the /login handler (CWE-601). A victim who already holds an active SSO session must be induced into opening a crafted /login link, after which the attacker - who must additionally hold any valid OAuth2 client credentials - redeems the leaked code at /oauth2/access_token to obtain the victim's access token, giving both high confidentiality and integrity impact (CVSS 7.6 v4.0: AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N; independent assessment CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N). Exploitation is conditional rather than trivial: it fails if the victim has no active session, does not click the link, or if the attacker lacks valid client credentials, though no authentication to the SSO server itself is required (PR:N). No public exploit identified at time of analysis, although a public technical writeup describing the authorization-code leak path has been published; this is a genuine but conditional risk rather than a drop-everything emergency.
OAuth2 client secret disclosure in the RabbitMQ Management UI affects versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2, where the configured management.oauth_client_secret is embedded in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js. Any party with network reachability to the management HTTP port can retrieve the secret with a simple GET request - authentication requirements confirmed unauthenticated (CVSS:3.1 AV:N/AC:L/PR:N/UI:N) and the assessed impact is high confidentiality loss (VC:H) with no integrity or availability impact. The flaw only manifests when OAuth2 authentication is enabled for the Management UI and the IdP flow uses a confidential client secret, so default or non-OAuth2 deployments are unaffected; no public exploit code has been identified at time of analysis, and the issue is fixed in 4.3.3 and 4.2.9.
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauthenticated remote attackers obtain a session for another user's account by linking their own OAuth2 provider identity to an account that was matched on an attribute other than email, and the same upsert rewrites the victim's email to the attacker's address so subsequent account recovery flows reach the attacker. Exploitation is conditional: the application must configure the OAuth2/Auth0/Apple strategy with a register-action upsert_identity that matches existing accounts on a non-email attribute, or use the registration_enabled? false sign-in path where accounts are matched by the sign-in action's read filter, and the attacker only needs control of a provider identity whose email_verified claim is true. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Bearer token leak in the OAuth2 Ruby gem (ruby-oauth/oauth2) versions 0.4.0 through 2.0.
Expired OAuth2 JWT access tokens are accepted indefinitely by RabbitMQ 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 when the rabbitmq_auth_backend_oauth2 backend is enabled and the identity provider emits the JWT 'exp' claim as a fractional (float) JSON number rather than an integer. Because the Erlang code guards expiry parsing with is_integer(Exp), both the login-time expiry check and the mid-connection disconnect timer silently fall through for float exp values, so an attacker holding a previously issued, correctly signed token can authenticate with it long after it has expired and keep connections open without being disconnected. The CVSS 4.0 base score is 6.3, but exploitability is sharply conditional - a non-default IdP behavior plus possession of a valid signed token - and no public exploit code has been identified at time of analysis; the issue is fixed in RabbitMQ 4.2.9 and 4.3.3.
Denial of service via atom exhaustion in RabbitMQ Server when the rabbitmq_auth_backend_oauth2 plugin is enabled and configured with an identity provider that allows user-influenced scope values in signed JWTs. Affected versions include 3.13.0 through 3.13.14, 4.0.x before 4.0.22, 4.1.x before 4.1.11, 4.2.x before 4.2.6, and 4.3.x before 4.3.1. Exploitation requires valid signed tokens bearing novel 'tag:' scope values across many repeated logins, and no public exploit code has been identified at time of analysis; independent assessment rates real-world risk as low due to the non-default plugin, permissive IdP dependency, and high volume of authentications needed.
An issue was discovered in ownCloud owncloud/oauth2 before 0.6.1, when Allow Subdomains is enabled. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
All versions of @fastify/oauth2 used a statically generated state parameter at startup time and were used across all requests for all users. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.