A session fixation vulnerability exists in the zenml-io/zenml application, where JWT tokens used for user authentication are not invalidated upon logout. This flaw allows an attacker to bypass authentication mechanisms by reusing a victim's JWT token.

A flaw was found in` JwtValidator.resolvePublicKey` in JBoss EAP, where the validator checks jku and sends a HTTP request. During this process, no whitelisting or other filtering behavior is performed on the destination URL address, which may result in a server-side request forgery (SSRF) vulnerability.

JJWT (aka Java JWT) through 0.12.5 ignores certain characters and thus a user might falsely conclude that they have a strong key. The impacted code is the setSigningKey() method within the DefaultJwtParser class and the signWith() method within the DefaultJwtBuilder class. NOTE: the vendor disputes this because the "ignores" behavior cannot occur (in any version) unless there is a user error in how JJWT is used, and because the version that was actually tested must have been more than six years out of date.

OpenMetadata is a unified platform for discovery, observability, and governance powered by a central metadata repository, in-depth lineage, and seamless team collaboration. The `JwtFilter` handles the API authentication by requiring and verifying JWT tokens. When a new request comes in, the request's path is checked against this list. When the request's path contains any of the excluded endpoints the filter returns without validating the JWT. Unfortunately, an attacker may use Path Parameters to make any path contain any arbitrary strings. For example, a request to `GET /api/v1;v1%2fusers%2flogin/events/subscriptions/validation/condition/111` will match the excluded endpoint condition and therefore will be processed with no JWT validation allowing an attacker to bypass the authentication mechanism and reach any arbitrary endpoint, including the ones listed above that lead to arbitrary SpEL expression injection. This bypass will not work when the endpoint uses the `SecurityContext.getUserPrincipal()` since it will return `null` and will throw an NPE. This issue may lead to authentication bypass and has been addressed in version 1.2.4. Users are advised to upgrade. There are no known workarounds for this vulnerability. This issue is also tracked as `GHSL-2023-237`.

Directus is a real-time API and App dashboard for managing SQL database content. When reaching the /files page, a JWT is passed via GET request. Inclusion of session tokens in URLs poses a security risk as URLs are often logged in various places (e.g., web server logs, browser history). Attackers gaining access to these logs may hijack active user sessions, leading to unauthorized access to sensitive information or actions on behalf of the user. This issue has been addressed in version 10.10.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

An issue discovered in Egerie Risk Manager v4.0.5 allows attackers to bypass the signature mechanism and tamper with the values inside the JWT payload resulting in privilege escalation.

A vulnerability was found in Juanpao JPShop up to 1.5.02. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file api/config/params.php of the component API. The manipulation of the argument JWT_KEY_ADMIN leads to use of hard-coded cryptographic key . The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier VDB-252997 was assigned to this vulnerability.

Open edX Platform is a service-oriented platform for authoring and delivering online learning. A user with a JWT and more limited scopes could call endpoints exceeding their access. This vulnerability has been patched in commit 019888f.

Navidrome is an open source web-based music collection server and streamer. A security vulnerability has been identified in navidrome's subsonic endpoint, allowing for authentication bypass. This exploit enables unauthorized access to any known account by utilizing a JSON Web Token (JWT) signed with the key "not so secret". The vulnerability can only be exploited on instances that have never been restarted. Navidrome supports an extension to the subsonic authentication scheme, where a JWT can be provided using a `jwt` query parameter instead of the traditional password or token and salt (corresponding to resp. the `p` or `t` and `s` query parameters). This authentication bypass vulnerability potentially affects all instances that don't protect the subsonic endpoint `/rest/`, which is expected to be most instances in a standard deployment, and most instances in the reverse proxy setup too (as the documentation mentions to leave that endpoint unprotected). This issue has been patched in version 0.50.2.

Xpand IT Write-back Manager v2.3.1 uses weak secret keys to sign JWT tokens. This allows attackers to easily obtain the secret key used to sign JWT tokens via a bruteforce attack.

** UNSUPPORTED WHEN ASSIGNED **An improper authentication vulnerability [CWE-287] in Fortinet FortiWAN version 5.2.0 through 5.2.1 and version 5.1.1 through 5.1.2 may allow an authenticated attacker to escalate his privileges via HTTP or HTTPs requests with crafted JWT token values.

Insertion of sensitive information in the centralized (Grafana) logging system in ProLion CryptoSpike 3.0.15P2 allows remote attackers to impersonate other users in web management and the REST API by reading JWT tokens from logs (as a Granafa authenticated user) or from the Loki REST API without authentication.

A hard-coded cryptographic private key used to sign JWT authentication tokens in ProLion CryptoSpike 3.0.15P2 allows remote attackers to impersonate arbitrary users and roles in web management and REST API endpoints via crafted JWT tokens.

Headwind MDM Web panel 5.22.1 is vulnerable to Incorrect Access Control due to a hard-coded JWT Secret. The secret is hardcoded into the source code available to anyone on Git Hub. This secret is used to sign the application’s JWT token and verify the incoming user-supplied tokens.

An Insecure Permissions issue in WebsiteGuide v.0.2 allows a remote attacker to gain escalated privileges via crafted jwt (JSON web token).

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.