Security
Headlines
HeadlinesLatestCVEs

Tag

#oauth

GHSA-gprj-3p75-f996: Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0

### Impact JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. The configuration for this would look like: ```python # Require users to be using the "foo.horse" identity provider, often an institution or university c.GlobusAuthenticator.identity_provider = "foo.horse" # Allow everyone who has that identity provider to log in c.GlobusAuthenticator.allow_all = True ``` 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](https://jupyterhub.readthedocs.io/en/stable/howto/upgrading-v5.html#authenticator-allow-all-and-allow-existing-users) in JupyterHub 5.0, but is likely to catch m...

ghsa
#oauth#auth
GHSA-69fp-7c8p-crjr: Keycloak exposes sensitive information in Pushed Authorization Requests (PAR)

A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a request_uri authorization request. This could lead to an information disclosure vulnerability.

GHSA-rcm4-jv5g-wccm: zfr authentication adapter did not verify validity of tokens

Previous to @2ca5bb1c2f11537be8f94ca6867d8d69789e744a (release [0.1.2](https://github.com/zf-fr/zfr-oauth2-server-module/tree/0.1.2)), tokens weren't checked for validity/expiration. This potentially caused a security issue if expired tokens were not deleted after the expiration time was past, allowing anyone to still use invalidated authentication credentials.

GHSA-6wqp-7g94-f69j: sensiolabs/connect has a Cross-Site Request Forgery Vulnerability

Versions of sensiolabs/connect prior to 4.2.3 are affected by a Cross-Site Request Forgery (CSRF) vulnerability due to the absence of the state parameter in OAuth requests. The lack of proper state parameter handling exposes applications to CSRF attacks during the OAuth authentication flow.

GHSA-h97c-qp24-439v: Insecure State Generation in laravel/socialite

laravel/socialite versions prior to 2.0.9 are found to have an insecure state generation mechanism, potentially exposing the OAuth authentication process to security risks. The issue has been addressed in version 2.0.9 by ensuring that the state is generated using a truly random approach, enhancing the security of the OAuth flow.

GHSA-7fjv-25q9-2w88: State Guessing Vulnerability in laravel/socialite

laravel/socialite versions prior to 2.0.10 are susceptible to a security vulnerability related to state guessing during OAuth authentication. This vulnerability could potentially lead to session hijacking, allowing attackers to compromise user sessions. The issue has been addressed and fixed in version 2.0.10.

GHSA-xm3x-4ph3-3x9c: friendsofsymfony/oauth2-php open redirection in oauth

An open redirection vulnerability has been identified in the friendsofsymfony/oauth2-php library, which could potentially expose users to unauthorized redirects during the OAuth authentication process. This vulnerability has been addressed by implementing an exact check for the domain and port, ensuring more secure redirection.

GHSA-mx47-6497-3fv2: Grafana account takeover via OAuth vulnerability

Today we are releasing Grafana 8.3.10, 8.4.10, 8.5.9 and 9.0.3. This patch release includes a HIGH severity security fix for an Oauth takeover vulnerability in Grafana. Release v.9.0.3, containing this security fix and other patches: - [Download Grafana 9.0.3](https://grafana.com/grafana/download/9.0.3) - [Release notes](https://grafana.com/docs/grafana/next/release-notes/release-notes-9-0-3/) Release v.8.5.9, containing this security fix and other fixes: - [Download Grafana 8.5.9](https://grafana.com/grafana/download/8.5.9) - [Release notes](https://grafana.com/docs/grafana/next/release-notes/release-notes-8-5-9/) Release v.8.4.10, containing this security fix and other fixes: - [Download Grafana 8.4.10](https://grafana.com/grafana/download/8.4.10) - [Release notes](https://grafana.com/docs/grafana/next/release-notes/release-notes-8-4-10/) Release v.8.3.10, containing this security fix and other fixes: - [Download Grafana 8.3.10](https://grafana.com/grafana/download/8.3.10) #...

GHSA-8wjh-59cw-9xh4: Grafana Forward OAuth Identity Token can allow users to access some data sources

When a data source has the Forward OAuth Identity feature enabled, sending a query to that datasource with an API token (and no other user credentials) will forward the OAuth Identity of the most recently logged-in user. This can allow API token holders to retrieve data for which they may not have intended access. ### Impact All of the following must be true: * The Grafana instance has data sources that support the Forward OAuth Identity feature. Graphite users, for example. * Some data sources are not susceptible, like Prometheus, as they do not have support for this feature. * The option being available is not sufficient enough to determine if the data source is susceptible. * The Grafana instance has a data source with the Forward OAuth Identity feature toggled on. * The Grafana instance has OAuth enabled. * The Grafana instance has usable API keys. ### Patches The following Grafana versions have been patched: * `v8.3.4` * `v7.5.13` ### Workarounds Administrators of G...

GHSA-2x52-8f29-7cjr: Eclipse Dataspace Components vulnerable to OAuth2 client secret disclosure

In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, in the [EDC Connector component](https://github.com/eclipse-edc/Connector), an attacker might obtain OAuth2 client secrets from the vault. In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, we have identified a security vulnerability in the EDC Connector component ( https://github.com/eclipse-edc/Connector ) regarding the OAuth2-protected data sink feature. When using a custom, OAuth2-protected data sink, the OAuth2-specific data address properties are resolved by the provider data plane. Problematically, the consumer-provided clientSecretKey, which indicates the OAuth2 client secret to retrieve from a secrets vault, is resolved in the context of the provider's vault, not the consumer. This secret's value is then sent to the tokenUrl, also consumer-controlled, as part of an OAuth2 client credentials grant. The returned access token is then sent as a bearer token to the data sink URL. This feature is now disabled e...