NextAuth.js provides authentication for Next.js. `next-auth` applications prior to version 4.24.5 that rely on the default Middleware authorization are affected by a vulnerability. A bad actor could create an empty/mock user, by getting hold of a NextAuth.js-issued JWT from an interrupted OAuth sign-in flow (state, PKCE or nonce). Manually overriding the `next-auth.session-token` cookie value with this non-related JWT would let the user simulate a logged in user, albeit having no user information associated with it. (The only property on this user is an opaque randomly generated string). This vulnerability does not give access to other users' data, neither to resources that require proper authorization via scopes or other means. The created mock user has no information associated with it (ie. no name, email, access_token, etc.) This vulnerability can be exploited by bad actors to peek at logged in user states (e.g. dashboard layout). `next-auth` `v4.24.5` contains a patch for the vulnerability. As a workaround, using a custom authorization callback for Middleware, developers can manually do a basic authentication.

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to version 3.3.2, the fast-jwt library does not properly prevent JWT algorithm confusion for all public key types. The 'publicKeyPemMatcher' in 'fast-jwt/src/crypto.js' does not properly match all common PEM formats for public keys. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work if the victim application utilizes a public key containing the `BEGIN RSA PUBLIC KEY` header. Applications using the RS256 algorithm, a public key with a `BEGIN RSA PUBLIC KEY` header, and calling the verify function without explicitly providing an algorithm, are vulnerable to this algorithm confusion attack which allows attackers to sign arbitrary payloads which will be accepted by the verifier. Version 3.3.2 contains a patch for this issue. As a workaround, change line 29 of `blob/master/src/crypto.js` to include a regular expression.

joaquimserafim/json-web-token is a javascript library use to interact with JSON Web Tokens (JWT) which are a compact URL-safe means of representing claims to be transferred between two parties. Affected versions of the json-web-token library are vulnerable to a JWT algorithm confusion attack. On line 86 of the 'index.js' file, the algorithm to use for verifying the signature of the JWT token is taken from the JWT token, which at that point is still unverified and thus shouldn't be trusted. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work against this library is the RS256 algorithm is in use, however it is a best practice to use that algorithm.

Dromara Lamp-Cloud before v3.8.1 was discovered to use a hardcoded cryptographic key when creating and verifying a Json Web Token. This vulnerability allows attackers to authenticate to the application via a crafted JWT token.

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.

Use of a static key to protect a JWT token used in user authentication can allow an for an authentication bypass in D-Link D-View 8 v2.0.1.28

Dispatch is an open source security incident management tool. The server response includes the JWT Secret Key used for signing JWT tokens in error message when the `Dispatch Plugin - Basic Authentication Provider` plugin encounters an error when attempting to decode a JWT token. Any Dispatch users who own their instance and rely on the `Dispatch Plugin - Basic Authentication Provider` plugin for authentication may be impacted, allowing for any account to be taken over within their own instance. This could be done by using the secret to sign attacker crafted JWTs. If you think that you may be impacted, we strongly suggest you to rotate the secret stored in the `DISPATCH_JWT_SECRET` envvar in the `.env` file. This issue has been addressed in commit `b1942a4319` which has been included in the `20230817` release. users are advised to upgrade. There are no known workarounds for this vulnerability.

An issue in Konga v0.14.9 allows attackers to bypass authentication via a crafted JWT token.

HashiCorp Consul and Consul Enterprise 1.16.0 when using JWT Auth for service mesh incorrectly allows/denies access regardless of service identities. Fixed in 1.16.1.

Connected IO v2.1.0 and prior uses a hard-coded username/password pair embedded in their device's firmware used for device communication using MQTT. An attacker who gained access to these credentials is able to connect to the MQTT broker and send messages on behalf of devices, impersonating them. in order to sign and verify JWT session tokens, allowing attackers to sign arbitrary session tokens and bypass authentication.

Control ID IDSecure 4.7.26.0 and prior uses a hardcoded cryptographic key in order to sign and verify JWT session tokens, allowing attackers to sign arbitrary session tokens and bypass authentication.

Weintek Weincloud v0.13.6 could allow an attacker to reset a password with the corresponding account’s JWT token only.

Weintek Weincloud v0.13.6 could allow an attacker to cause a denial-of-service condition for Weincloud by sending a forged JWT token.

CasaOS is an open-source Personal Cloud system. Unauthenticated attackers can craft arbitrary JWTs and access features that usually require authentication and execute arbitrary commands as `root` on CasaOS instances. This problem was addressed by improving the validation of JWTs in commit `705bf1f`. This patch is part of CasaOS 0.4.4. Users should upgrade to CasaOS 0.4.4. If they can't, they should temporarily restrict access to CasaOS to untrusted users, for instance by not exposing it publicly.

Use of Insufficiently Random Values in Honeywell OneWireless. This vulnerability may allow attacker to manipulate claims in client's JWT token. This issue affects OneWireless version 322.1

MXsecurity version 1.0 is vulnearble to hardcoded credential vulnerability. This vulnerability has been reported that can be exploited to craft arbitrary JWT tokens and subsequently bypass authentication for web-based APIs.

European Chemicals Agency IUCLID 6.x before 6.27.6 allows authentication bypass because a weak hard-coded secret is used for JWT signing. The affected versions are 5.15.0 through 6.27.5.

ESPv2 is a service proxy that provides API management capabilities using Google Service Infrastructure. ESPv2 2.20.0 through 2.42.0 contains an authentication bypass vulnerability. API clients can craft a malicious `X-HTTP-Method-Override` header value to bypass JWT authentication in specific cases. ESPv2 allows malicious requests to bypass authentication if both the conditions are true: The requested HTTP method is **not** in the API service definition (OpenAPI spec or gRPC `google.api.http` proto annotations, and the specified `X-HTTP-Method-Override` is a valid HTTP method in the API service definition. ESPv2 will forward the request to your backend without checking the JWT. Attackers can craft requests with a malicious `X-HTTP-Method-Override` value that allows them to bypass specifying JWTs. Restricting API access with API keys works as intended and is not affected by this vulnerability. Upgrade deployments to release v2.43.0 or higher to receive a patch. This release ensures that JWT authentication occurs, even when the caller specifies `x-http-method-override`. `x-http-method-override` is still supported by v2.43.0+. API clients can continue sending this header to ESPv2.

Grafana is an open-source platform for monitoring and observability. Starting with the 9.1 branch, Grafana introduced the ability to search for a JWT in the URL query parameter auth_token and use it as the authentication token. By enabling the "url_login" configuration option (disabled by default), a JWT might be sent to data sources. If an attacker has access to the data source, the leaked token could be used to authenticate to Grafana.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ivanti Avalanche 6.3.2.3490. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed. The specific flaw exists within the JwtTokenUtility class. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-15301.