A flaw was found in Keycloak's OIDC component in the "checkLoginIframe," which allows unvalidated cross-origin messages. This flaw allows attackers to coordinate and send millions of requests in seconds using simple code, significantly impacting the application's availability without proper origin validation for incoming messages.

A flaw was found in JBoss EAP. When an OIDC app that serves multiple tenants attempts to access the second tenant, it should prompt the user to log in again since the second tenant is secured with a different OIDC configuration. The underlying issue is in OidcSessionTokenStore when determining if a cached token should be used or not. This logic needs to be updated to take into account the new "provider-url" option in addition to the "realm" option.

oidcc is the OpenID Connect client library for Erlang. Denial of Service (DoS) by Atom exhaustion is possible by calling `oidcc_provider_configuration_worker:get_provider_configuration/1` or `oidcc_provider_configuration_worker:get_jwks/1`. This issue has been patched in version(s)`3.1.2` & `3.2.0-beta.3`.

Coder allows oragnizations to provision remote development environments via Terraform. Prior to versions 2.6.1, 2.7.3, and 2.8.4, a vulnerability in Coder's OIDC authentication could allow an attacker to bypass the `CODER_OIDC_EMAIL_DOMAIN` verification and create an account with an email not in the allowlist. Deployments are only affected if the OIDC provider allows users to create accounts on the provider. During OIDC registration, the user's email was improperly validated against the allowed `CODER_OIDC_EMAIL_DOMAIN`s. This could allow a user with a domain that only partially matched an allowed domain to successfully login or register. An attacker could register a domain name that exploited this vulnerability and register on a Coder instance with a public OIDC provider. Coder instances with OIDC enabled and protected by the `CODER_OIDC_EMAIL_DOMAIN` configuration are affected. Coder instances using a private OIDC provider are not affected, as arbitrary users cannot register through a private OIDC provider without first having an account on the provider. Public OIDC providers are impacted. GitHub authentication and external authentication are not impacted. This vulnerability is remedied in versions 2.8.4, 2.7.3, and 2.6.1 All versions prior to these patches are affected by the vulnerability.*It is recommended that customers upgrade their deployments as soon as possible if they are utilizing OIDC authentication with the `CODER_OIDC_EMAIL_DOMAIN` setting.

Mastodon is a free, open-source social network server based on ActivityPub. Mastodon allows new identities from configured authentication providers (CAS, SAML, OIDC) to attach to existing local users with the same e-mail address. This results in a possible account takeover if the authentication provider allows changing the e-mail address or multiple authentication providers are configured. When a user logs in through an external authentication provider for the first time, Mastodon checks the e-mail address passed by the provider to find an existing account. However, using the e-mail address alone means that if the authentication provider allows changing the e-mail address of an account, the Mastodon account can immediately be hijacked. All users logging in through external authentication providers are affected. The severity is medium, as it also requires the external authentication provider to misbehave. However, some well-known OIDC providers (like Microsoft Azure) make it very easy to accidentally allow unverified e-mail changes. Moreover, OpenID Connect also allows dynamic client registration. This issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.

The Kantega SAML SSO OIDC Kerberos Single Sign-on apps before 6.20.0 for Atlassian products allow XSS if SAML POST Binding is enabled. This affects 4.4.2 through 4.14.8 before 4.14.9, 5.0.0 through 5.11.4 before 5.11.5, and 6.0.0 through 6.19.0 before 6.20.0. The full product names are Kantega SAML SSO OIDC Kerberos Single Sign-on for Jira Data Center & Server (Kantega SSO Enterprise), Kantega SAML SSO OIDC Kerberos Single Sign-on for Confluence Data Center & Server (Kantega SSO Enterprise), Kantega SAML SSO OIDC Kerberos Single Sign-on for Bitbucket Data Center & Server (Kantega SSO Enterprise), Kantega SAML SSO OIDC Kerberos Single Sign-on for Bamboo Data Center & Server (Kantega SSO Enterprise), and Kantega SAML SSO OIDC Kerberos Single Sign-on for FeCru Server (Kantega SSO Enterprise). (Here, FeCru refers to the Atlassian Fisheye and Crucible products running together.)

Apache Software Foundation Apache Submarine has an SQL injection vulnerability when a user logs in. This issue can result in unauthorized login. Now we have fixed this issue and now user must have the correct login to access workbench. This issue affects Apache Submarine: from 0.7.0 before 0.8.0. We recommend that all submarine users with 0.7.0 upgrade to 0.8.0, which not only fixes the issue, supports the oidc authentication mode, but also removes the case of unauthenticated logins. If using the version lower than 0.8.0 and not want to upgrade, you can try cherry-pick PR https://github.com/apache/submarine/pull/1037 https://github.com/apache/submarine/pull/1054 and rebuild the submarine-server image to fix this.

IBM Security Verify Access OIDC Provider could disclose directory information that could aid attackers in further attacks against the system. IBM X-Force ID: 239445.

IBM Security Verify Access OIDC Provider could allow a remote user to cause a denial of service due to uncontrolled resource consumption. IBM X-Force ID: 238921.

Micronaut Security is a security solution for applications. Prior to versions 3.1.2, 3.2.4, 3.3.2, 3.4.3, 3.5.3, 3.6.6, 3.7.4, 3.8.4, 3.9.6, 3.10.2, and 3.11.1, IdTokenClaimsValidator skips `aud` claim validation if token is issued by same identity issuer/provider. Any OIDC setup using Micronaut where multiple OIDC applications exists for the same issuer but token auth are not meant to be shared. This issue has been patched in versions 3.1.2, 3.2.4, 3.3.2, 3.4.3, 3.5.3, 3.6.6, 3.7.4, 3.8.4, 3.9.6, 3.10.2, and 3.11.1.

A flaw was found in Quarkus. Quarkus OIDC can leak both ID and access tokens in the authorization code flow when an insecure HTTP protocol is used, which can allow attackers to access sensitive user data directly from the ID token or by using the access token to access user data from OIDC provider services. Please note that passwords are not stored in access tokens.

A flaw was found in APICast, when 3Scale's OIDC module does not properly evaluate the response to a mismatched token from a separate realm. This could allow a separate realm to be accessible to an attacker, permitting access to unauthorized information.

user_oidc provides the OIDC connect user backend for Nextcloud, an open-source cloud platform. Starting in version 1.0.0 and prior to version 1.3.3, an attacker that obtained at least read access to a snapshot of the database can impersonate the Nextcloud server towards linked servers. user_oidc 1.3.3 contains a patch. No known workarounds are available.

user_oidc provides the OIDC connect user backend for Nextcloud, an open-source cloud platform. Starting in version 1.0.0 and prior to version 1.3.3, missing verification of the issuer would have allowed an attacker to perform a man-in-the-middle attack returning corrupted or known token they also have access to. user_oidc 1.3.3 contains a patch. No known workarounds are available.

Keycloak, an open-source identity and access management solution, has a cross-site scripting (XSS) vulnerability in the SAML or OIDC providers. The vulnerability can allow an attacker to execute malicious scripts by setting the AssertionConsumerServiceURL value or the redirect_uri.

user_oidc is the OIDC connect user backend for Nextcloud, an open source collaboration platform. A vulnerability in versions 1.0.0 until 1.3.0 effectively allowed an attacker to bypass the state protection as they could just copy the expected state token from the first request to their second request. Users should upgrade user_oidc to 1.3.0 to receive a patch for the issue. No known workarounds are available.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions of Argo CD starting with v1.8.2 and prior to 2.3.13, 2.4.19, 2.5.6, and 2.6.0-rc-3 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens. OIDC providers include an `aud` (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD _does_ validate that the token was signed by Argo CD's configured OIDC provider. But Argo CD _does not_ validate the audience claim, so it will accept tokens that are not intended for Argo CD. If Argo CD's configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token's `groups` claim, even though those groups were not intended to be used by Argo CD. This bug also increases the impact of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD. A patch for this vulnerability has been released in versions 2.6.0-rc3, 2.5.6, 2.4.19, and 2.3.13. There are no workarounds.

An open redirect vulnerability exists in Okta OIDC Middleware prior to version 5.0.0 allowing an attacker to redirect a user to an arbitrary URL.

ZITADEL is a combination of Auth0 and Keycloak. RefreshTokens is an OAuth 2.0 feature that allows applications to retrieve new access tokens and refresh the user's session without the need for interacting with a UI. RefreshTokens were not invalidated when a user was locked or deactivated. The deactivated or locked user was able to obtain a valid access token only through a refresh token grant. When the locked or deactivated user’s session was already terminated (“logged out”) then it was not possible to create a new session. Renewal of access token through a refresh token grant is limited to the configured amount of time (RefreshTokenExpiration). As a workaround, ensure the RefreshTokenExpiration in the OIDC settings of your instance is set according to your security requirements. This issue has been patched in versions 2.17.3 and 2.16.4.

mod_auth_openidc is an OpenID Certified™ authentication and authorization module for the Apache 2.x HTTP server. Versions prior to 2.4.12.2 are vulnerable to Open Redirect. When providing a logout parameter to the redirect URI, the existing code in oidc_validate_redirect_url() does not properly check for URLs that start with /\t, leading to an open redirect. This issue has been patched in version 2.4.12.2. Users unable to upgrade can mitigate the issue by configuring mod_auth_openidc to only allow redirection when the destination matches a given regular expression with OIDCRedirectURLsAllowed.