A exposure of sensitive information to an unauthorized actor in Fortinet FortiAuthenticator version 6.4.0, version 6.3.2 and below, version 6.2.1 and below, version 6.1.2 and below, version 6.0.7 to 6.0.1 allows attacker to duplicate a target LDAP user 2 factors authentication token via crafted HTTP requests.

FirstUseAuthenticator is a JupyterHub authenticator that helps new users set their password on their first login to JupyterHub. When JupyterHub is used with FirstUseAuthenticator, a vulnerability in versions prior to 1.0.0 allows unauthorized access to any user's account if `create_users=True` and the username is known or guessed. One may upgrade to version 1.0.0 or apply a patch manually to mitigate the vulnerability. For those who cannot upgrade, there is no complete workaround, but a partial mitigation exists. One can disable user creation with `c.FirstUseAuthenticator.create_users = False`, which will only allow login with fully normalized usernames for already existing users prior to jupyterhub-firstuserauthenticator 1.0.0. If any users have never logged in with their normalized username (i.e. lowercase), they will still be vulnerable until a patch or upgrade occurs.

An uncontrolled resource consumption (denial of service) vulnerability in the login modules of FortiSandbox 3.2.0 through 3.2.2, 3.1.0 through 3.1.4, and 3.0.0 through 3.0.6; and FortiAuthenticator before 6.0.6 may allow an unauthenticated attacker to bring the device into an unresponsive state via specifically-crafted long request parameters.

Usage of hard-coded cryptographic keys to encrypt configuration files and debug logs in FortiAuthenticator versions before 6.3.0 may allow an attacker with access to the files or the CLI configuration to decrypt the sensitive data, via knowledge of the hard-coded key.

OAuthenticator is an OAuth login mechanism for JupyterHub. In oauthenticator from version 0.12.0 and before 0.12.2, the deprecated (in jupyterhub 1.2) configuration `Authenticator.whitelist`, which should be transparently mapped to `Authenticator.allowed_users` with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as `GitHubOAuthenticator.org_whitelist` are **not** affected. All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the `admin.whitelist.users` configuration in the jupyterhub helm chart or the `c.Authenticator.whitelist` configuration directly. Users of other deprecated configuration, e.g. `c.GitHubOAuthenticator.team_w…

An improper neutralization of input during web page generation in FortiAuthenticator WEB UI 6.0.0 may allow an unauthenticated user to perform a cross-site scripting attack (XSS) via a parameter of the logon page.

A cross-site scripting (XSS) vulnerability in Fortinet FortiAuthenticator in versions 4.0.0 to before 5.3.0 "CSRF validation failure" page allows attacker to execute unauthorized script code via inject malicious scripts in HTTP referer header.

An issue was discovered in Project Jupyter JupyterHub OAuthenticator 0.6.x before 0.6.2 and 0.7.x before 0.7.3. When using JupyterHub with GitLab group whitelisting for access control, group membership was not checked correctly, allowing members not in the whitelisted groups to create accounts on the Hub. (Users were not allowed to access other users' accounts, but could create their own accounts on the Hub linked to their GitLab account. GitLab authentication not using gitlab_group_whitelist is unaffected. No other Authenticators are affected.)

The management screen in Falcon WisePoint 4.3.1 and earlier and WisePoint Authenticator 4.1.19.22 and earlier allows remote attackers to conduct clickjacking attacks via unspecified vectors.

Fortinet FortiAuthenticator 3.0.0 allows local users to read arbitrary files via the -f flag to the dig command.